Goal 2: Improving Vulnerability Discovery & Remediation
Currently quite a bit of vulnerability discovery takes place in highly compensated arenas — from a response to a bug bounty to zero-days traded on darknets. OSS maintainers often do not have the resources to compete with well resourced adversaries in finding deep bugs in their own code. With sufficient funding, automation, and economies of scale, we can address this imbalance.
Furthermore, as Google VP of Infrastructure & Google Fellow Eric Brewer says, “We’re not too bad at finding defects, but we usually struggle to get them fixed.” We can’t assume existing maintainers on even well-resourced OSS efforts will be able to keep up with a moderate volume of new potential defects. Finding is not enough — that must be paired with resources to remediate. But remediation of an as-yet-undisclosed vulnerability is sensitive work, requiring a thoughtful approach.
Stream 5: Establish the OpenSSF Open Source Security Incident Response Team, security experts who can step in to assist open source projects during critical times when responding to a vulnerability.
At times, an OSS maintainer community can be overwhelmed by the enormity and complexity of dealing with a serious security notification they’ve been served, and may struggle to get the bug fixed in the right way quickly. In these moments, a small team of professional software developers, vetted for security and trained on the specifics of the language and frameworks being used by that OSS project, would be extremely helpful. They would need to be accessible on very short notice for what could be full time work for a number of days or weeks, and given clearance by their employers or other commitments to work confidentiality to protect against disclosure. To cover an array of popular languages and frameworks, and to be able to put 2 or 3 such experts on any given crisis, a stable of 30-40 such experts should be identified, trained, and managed.
Cost: $2.75M for the first year, $3.05M per year beyond.
Stream 6: Accelerate discovery of new vulnerabilities by maintainers and experts through advanced security tools and expert guidance.
Most open source maintainers do not have access to the kinds of security scanning tools (software composition, static analysis, fuzzing, and so on) that can catch vulnerabilities early. Not only are the tools often proprietary, just the server costs alone to run them on a recurring basis could be more than most can bear. This stream would pull together the major source code repository hosts, security tool vendors, cloud platform providers and OSS maintainers to provision scanning and monitoring tools in a vendor-neutral uniform platform. It would also pair those maintainers with selected, vetted, paid security experts who can work with them to validate any potential vulnerability and any proposed fix. This would help those maintainers more quickly discover new vulnerabilities in their code and guide them through a remediation and coordinated disclosure process. It would aim to eventually cover the top 10,000 OSS components.
Cost: $15M for the first year, $11M per year beyond.
Stream 7: Conduct third-party code reviews (and any necessary remediation work) of up to 200 of the most-critical OSS components once per year.
Writing secure software is hard — indeed, it is so hard that all of even the most highly-regarded technology companies and open source projects in the world produce code which is later found to have security flaws which require a software update to remediate. While the number of these flaws can be dramatically reduced prior to the code making it into real-world (“production”) environments, a lot of the technical tools used to find those vulnerabilities are unable to find some of the most critical and complex bugs — that remains the domain of human experts.
We propose an industry-wide coordinated effort to manage and facilitate third-party code reviews and associated remediation work of the most critical OSS software. By having reputable third-party security firms perform code review/security auditing of the most critical open source projects and working with OSS maintainers to publish a Public Report of the findings from each audit, we will: find and remediate yet-undiscovered high-impact vulnerabilities; improve developer, industry, and public sector confidence in critical software projects; set high standards for audit quality; remediate the vulnerabilities found, and report to the public all of the associated findings, to benefit the entire ecosystem. This is hard, human-intensive work, but the returns grow with every successful audit.
We aim to cover 50 of the most critical projects in the first year, and cover the top 200 in years 2 and beyond.
Cost: $11M for the first year, $42M per year beyond.
Stream 8: Coordinate industry-wide data sharing to improve the research that helps determine the most critical OSS components.
A major challenge to objectively determining which OSS is actually “critical” is that usage, download, and dependency data is often considered a proprietary advantage by the software distribution channels who are able to collect that data. The Harvard Census II has made great strides here in encouraging more data sharing in some areas, but much more could be done here to drive a more metrics-driven approach to understanding global OSS usage and risk. Provisioning resources to securely and safely manage that data from a greater number of sources, and then funding further interpretation and related research, would substantially improve our understanding of the on-the-ground reality and lower the risk of “surprises”.
Cost: $1.85M for the first year, $2.05M per year beyond.