If software powers the world, open source is its beating heart. Today 99% of all software projects consume open source :D. That is simply incredible. It is a testament to the work that so many have given freely. Everyone that contributes to open source should be proud about how they have helped us all move forward.
With that success comes responsibility. Open source must be something that the world can trust. As open source creation and consumption continues to rise, this problem is becoming increasingly important—and increasingly challenging.
A new approach
Today the security lifecycle is broken.
Identifying vulnerabilities is a manual, ad hoc process.
Disclosures are often not made responsibly—if they’re made at all.
Security vulnerabilities are fixed outside of normal open source workflows, without the support of critical tooling just to avoid premature disclosure.
Developers don’t get security alerts for their projects that consume vulnerable software, or if they do, they may be overwhelmed by the number and complexity of issues to investigate; which can consist of both real and false-positives.
Updating vulnerable dependencies takes too long or simply doesn’t happen at all.
Nothing prevents the mistake that introduced a vulnerability from happening again.
Software security is a collective problem, a responsibility that involves producers and consumers of code, open source maintainers, security researchers, and security teams.
The security advisory
A typical security vulnerability workflow involves researchers, maintainers, and developers.
- Researchers identify vulnerabilities and disclose them to the maintainers.
- Maintainers fix the issue and send an alert to the community.
- Developers update to the fixed version and look to prevent a recurrence.
- Security advisories cover every step of security, from identification to disclosure and remediation.
A security advisory is the entity that tracks a vulnerability from the beginning to the end of this lifecycle. It connects the researcher that found the issue to the maintainer that fixed it and the developers that depend on it.
Security researchers
Security researchers play a critical role in keeping the world’s codebase safe by identifying and disclosing vulnerabilities. As software development has grown, however, the community of security researchers has not, and the ratio of security researchers to developers continues to drop.
It’s critical that these researchers can be as productive as possible.
Traditionally, vulnerabilities are discovered by penetration testing, or inspecting code by hand.
Many vulnerabilities have the same type of coding mistake as their root cause. We must find all variations of a mistake, eradicating a whole class of vulnerabilities. Furthermore, this approach makes more effective, finding dramatically more issues and with far fewer false positives.
Security researchers identify vulnerabilities and their variants. Customers frequently find vulnerabilities they couldn’t find with other tools and accomplish tasks that used to take weeks or more in hours.
An important measure of success is the number of vulnerabilities that have been identified and disclosed through their technology.
After a researcher or developer finds a vulnerability, the next step is to coordinate disclosure with the project maintainer. Simply identifying the person, much less contacting them in a private manner, can be a challenge. Reporting a security vulnerability safely is something that anybody should be able to do for any project.
Once a vulnerability is reported for a project, the project’s maintainers can create a security advisory so the researcher, maintainer, and development team can privately coordinate on how best to address the vulnerability.
Maintainers
Maintainers are under incredible pressure. Not only do they have to try to make sure that every release they publish is secure, they also have the responsibility to fix vulnerabilities quickly when they are found. Making their challenge even harder, they often can’t even work on the fix using their normal tools for fear of accidentally disclosing the issue.
Within a security advisory, maintainers can create a private fork as a safe place to collaborate on a fix.
Once the maintainers have completed their fix, they will publish patched versions that address the vulnerability, and, critically, a security advisory. So often exploits happen using vulnerabilities that have fixes available but just haven’t been picked up by the larger community.
Developers
Developers have the all-important job of keeping their projects secure. A huge part of this means keeping their dependencies updated.
We know that alerts aren’t enough. A significant percentage of critical vulnerabilities go unpatched for months—and the risk to an organization from unpatched vulnerabilities grows as the unpatched code is proliferated.
Updating dependencies needs to be as easy as possible.
Security teams
Developers are busy folk, and we know sometimes things like security vulnerabilities can slip through the cracks. In enterprises, this can expose customers to vulnerabilities, so we must provide security, compliance, and open source offices a turn key way to audit your organization’s open source dependencies for security vulnerabilities with dependency insights.