The Open Source Software Security Mobilization Plan: Takeaways for security leaders

The Linux Foundation and the Open Source Security Foundation (OpenSSF) have introduced the Open Source Software Security Mobilization Plan. This is in response to attacks on the software supply chain and an uptick in interest in securing them. Supply chains are appealing targets to malicious actors because they can compromise a single point and have a cascading impact across the ecosystem of customers, as the SolarWinds and Log4j attacks have shown.

Software supply chain security became a focus with U.S. President Joe Biden’s Cybersecurity Executive Order (EO) in 2021. Its “Enhancing Software Supply Chain Security” section called for input from government, academia, and industry on best practices and guidelines. The U.S. National Institute of Standards and Technology (NIST) has now published that information.

Participants at the White House-hosted Software Security Summit in early 2022 discussed securing open source software (OSS), improving the ecosystem, and accelerating the adoption of software bill of materials (SBOM). The federal government has also been using its massive purchasing power to enforce secure development practices and pushing for companies selling software to the government to attest compliance with the newly published version of the NIST Secure Software Development Framework (SSDF).

The Open Source Software Security Mobilization Plan helps ensure that the momentum from these previous efforts doesn’t fizzle out. Here are the key takeaways for security leaders.

Open Source Software Security Mobilization Plan goals

The plan has three high-level goals:

• Securing OSS production
• Improving vulnerability discovery and remediation
• Shortening ecosystem patching response time

Each goal has associated streams that describe tactical actions to help achieve it. The plan also emphasizes just how pervasive OSS use is, with roughly 70% to 90% of software stacks consisting of OSS components. The plan emphasizes the need for strategic investments to achieve a resilient software supply chain ecosystem.

Securing OSS production 

This goal focuses on slowing the problems of insecure code at the source. Security knowledge needs to be democratized and developers need to be empowered with the knowledge to write secure code from the onset of the software development lifecycle (SDLC). To achieve this goal the plan emphasizes three key actions:

• Secure development education and certification, either free or affordably. One option emphasized is the OpenSSF Secure Software Fundamentals Providing these options and driving adoption through academia and industry can create more security-aware development.

• Creating an objective, metrics-based risk assessment dashboard for the top 10,000 OSS components. This would facilitate industry-wide visibility into the security of some of the most-used OSS components, leaning into options like Secure Scorecard. This could lead to better industry awareness around the security of commonly used OSS components. It would also inform vendors who use the components in their products as well as downstream consumers who have begun creating software asset inventories by asking software vendors about their SBOMs/SaaSBOMs and internal development efforts.

• Speeding the adoption of digital signatures of software releases. By doing so, those building and consuming software have a level of validation around the OSS components they’re using. Digging into the plan’s appendix, you’ll see efforts such as Sigstore There’s an emphasis on the Supply Chain Levels for Software Artifacts (SLSA) and workload identities and attestations, where organizations like Chainguard and TestifySec are making waves.

Lastly, much like educating developers, there are other methods that can be taken to eliminate vulnerabilities entirely. One point is to replace non-memory safe languages. The most notable examples here are moving from C and C++ to alternatives such as Go and Rust.

Improving vulnerability discovery and remediation

While efforts such as bug bounties and the like have helped drive the discovery and remediation of vulnerabilities in commercial and government off-the-shelf software (COTS/GOTS) environments, the same can’t be said for the OSS ecosystem. OSS maintainers are largely volunteers and uncompensated. The plan emphasizes an investment to improve both the discovery and remediation of vulnerabilities in critical OSS components and projects.

The initial stream here involves creating an OpenSSF Open Source Security Incident Response Team. This team would be funded and positioned to alleviate the gaps identified above and assist OSS projects with resolving vulnerabilities that are discovered, especially in cases where the OSS project may be understaffed or not equipped to rapidly resolve them. While this doesn’t stop vulnerabilities, it does ensure that they are quickly resolved and patches/updates are made available more quickly to downstream consumers.

Many OSS maintainers lack security tooling and guidance to drive down vulnerabilities associated with their projects. Stream 6 of the plan addresses this by ensuring that security tool vendors, cloud service providers (CSPs), and others assist the maintainers with getting access to the infrastructure and tools needed to drive down vulnerabilities while also giving them access to security expertise.

Another stream in this goal involves conducting third-party code reviews on up to 200 critical OSS components once a year. This provides secure code expertise not directly involved in the project to review components to identify vulnerabilities for remediation.

Closing out this goal is a stream focused on improving the industry’s ability to determine what OSS components are the most critical. This will involve better data sharing among organizations and collaboration related to research.

Shorten ecosystem patching response time

This goal is not just about finding and remediating vulnerabilities at the source of the components, but getting the associated downstream updates distributed and implemented across the software supply chain. You can’t prevent a vulnerable component from wreaking havoc if the downstream consumers haven’t updated appropriately. This is a problem we still struggle with as an industry when it comes to traditional patch management.

The streams associated with this goal involve improving the adoption, training, and tools associated with SBOMs. This is critical because without the widespread adoption and operationalization of SBOMs, organizations won’t be positioned to understand the components they’re using in their environments and respond accordingly. This includes baking it into leading software build tools, improving training and awareness, and normalizing SBOM production and consumption.

The last stream associated with this goal revolves around bolstering the most critical OSS build systems, package managers, and distribution systems. Making security enhancements at the software artifact distribution layer can drive down risk across the ecosystem. It will also improve trust in the composition and provenance of software components, a key feature in the previously mentioned NIST SSDF.

Next steps

The Open Source Software Security Mobilization Plan highlights key aspects associated with securing the software supply chain, spanning people, process and technology, with the first being inarguably the most important of the three. For more details associated with the plan, dig into the associated appendices and project costs associated with each of the streams discussed above.

While some may critique the plan, it is a major step in the right direction. As the saying goes, a good plan today is better than a perfect plan tomorrow, and we can’t wait until tomorrow because malicious actors are increasingly exploiting the fragmented and fragile software supply chain today and we must take action.