Open Source Vulnerabilities and Security with Microsoft’s Jeff McAffer

As 2019 draws to an end, we are going to be looking back on some great episodes of our podcast The Secure Developer. See the first post here.

The Secure Developer_podcast is part of our vendor-neutral, security education focused community, MyDevSecOps. The community, previously also known as The Secure Developer, meets virtually via our Slack group and virtual events, and in person at DevSecCon events around the world.

About our guest

Jeff McAffer is director of Microsoft’s Open Source Programs Office. In his role there, he runs the open source programs office helping drive policy, process, tools, and culture change across the company at a time when Microsoft is changing its views on open source.  He joined us on the Secure Developer podcast recently to discuss:

• How to streamline security processes

• Vulnerability management

• Open source stewardship, and more

Today, we want to share the highlights of our conversation with Jeff.

Streamlining the Process

The dozen members of Jeff’s team have worked to streamline the open source process at Microsoft by employing the mantra "eliminate, automate, delegate." Here’s what that means:

• Eliminate:If possible, the team eliminates any policies, questions, or friction that can be found and addressed.

• Automate: The team writes policies that are highly automated and can take in data and context and spit out an answer.

• Delegate: If the team identifies a risk that needs outside input, they delegate to a third party with relevant expertise, such as a lawyer or more business-oriented team member.

According to Jeff, by applying this workflow, moving away from a request and approve model, and moving toward a register and review model, “We've gotten to the point now where with integrations into our build systems, and these automated policies, and good data, about 99% of our open source usages are automatically detected and automatically flow through our policy engines with no humans whatsoever.”

Despite the effort to make systems as automated as possible, the tooling is not perfect, because, as he puts it, humans are humans and tools are tools. That’s why it’s important to have a security plan at the ready to address vulnerabilities that may arise.

Accounting for Vulnerabilities

When it comes to Microsoft’s approach to security, there are two different levels:

• Active Development:The first set of security components are focused on active development. When a component is added that has some security or license problem, it would get flagged, the team gets notified, and can then engage.

• Incident Response:If a high severity vulnerability is disclosed, it goes to the Security Incident Response Team and they make a determination based on whatever information available to them. Whether they sound the alarm comes down to that SLA definition.

These levels cover most use cases. However, according to Jeff, it’s still interesting to look and say, “What better assessment information can we have? How can I tell as a user if I am vulnerable?” At Snyk, we agree with this line of questioning (and our tools provide the ability to identify vulnerabilities in your dependencies at all times). This approach enables companies to be fully transparent about managing their vulnerabilities and declaring success in doing so.

By proactively reporting your vulnerabilities, whether it's through the standard CDEs or elsewhere, is responsible and respectful to the broader open source community. This is part of taking ownership as an open source maintainer. If you choose to use some open source components, Jeff recommends taking ownership for those components by tracking and reporting related vulnerabilities as you distribute that code.

Better Open Source Stewardship

In the same vein, just as companies are working on ways to help identify vulnerabilities, Microsoft debuted ClearlyDefined.io to assist in crowdsourcing license data. In this community, people can annotate hard to track licenses and copyright holders, ensuring the information is as up to date as possible.

ClearlyDefined gets reviewed like any open source contribution and subsequently merged into the definitions of open source components. Ideally, it is upstreamed to the original components so that future versions are more “clearly defined.”

As Jeff explained, “A lot of people still think, ‘It's open source. I'll just take it, I'll use it, and that's it.’ But you really have to treat it like it's your code. Even if you're not going to write any, even if you don't know the language, you have to treat it like it's part of your system and you do need to care about the security of it and you do need to engage with the producing teams, the project teams, and say ‘How can we make this together? How can we make this a secure project so that we can all consume it in a secure way?’” We’re all-in on this view of open source stewardship.

MyDevSecOps is committed to bringing excellent speakers like Jeff McAffer to both our virtual sessions and our podcast, The Secure Developer. If you are interested in learning more about all aspects of security, please consider joining the community.