Open source security is the topic of the year.
Open source security is the topic of the year. From local meetup talks to US Executive Orders, you can’t get far into “open source” without addressing security in 2021. Many of the problems being discussed around open source security are not new. There is growing awareness of these issues, but also a newfound emphasis on solving them; both of these have the potential to be beneficial for both open source users and maintainers.
At the Day 2 Keynote, Anne Bertucio, a Program Manager for security in Google’s Open Source Programs Office, will talk about steps project maintainers and contributors can take to proactively protect their projects against supply chain attacks. Also on Day 2, Anne will dive into the topic of vulnerability disclosure—what it is, how to set it up for your OSS project, and what it means for users. In anticipation of those talks, let’s bust three myths about open source security:
1) You have to be a “security person” to increase your OSS project’s security
While employing the advice of a security professional or company—like for a security audit or penetration test—are no doubt beneficial, there are plenty of ways you can increase your project’s security without ever stepping foot in an infosec class (though if you’re interested, you definitely should!). Groups like the Open Source Security Foundation (OpenSSF) are releasing tools, like Allstar and Scorecards, to help harden any project—no matter your level of familiarity with security.
2) Many vulnerabilities in a project means it has bad security
The number of disclosed vulnerabilities* a project has had—eg receiving a report, patching, and sharing the vulnerability information—is not an indicator of a project’s security posture. Receiving a vulnerability report simply means someone is looking–that’s a good thing– and having a working and effective disclosure process is a sign of a more “security mature” project.
*Disclosed vulnerabilities are separate from unpatched vulnerabilities in a project’s dependencies. If a project hasn’t bumped dependency versions to apply a security patch, that’s a problem! Speaking of dependencies…
3) The biggest security risk is the project itself
From analysis of the dataset at deps.dev, the Open Source Insights team estimates that less than 1% of vulnerabilities in a project come directly from the project source itself—99% of vulnerabilities come from a project’s dependencies. While each user and project will have its own risk assessment, dependencies shouldn’t be left out of the picture! You can hear more from the Open Source Insights team on Day 1, and visit deps.dev and search by package to visualize the dependency graph.
You can learn more about open source at Google by visiting opensource.google, or stopping by the virtual booth during All Things Open!
The Featured Blog Posts series will highlight posts from partners and members of the All Things Open community leading up to the conference in October.