The Open Source Software Security Mobilization Plan: Takeaways for Security Managers

1 credit

The Linux Foundation and the Open Source Security Foundation (OpenSSF) introduced the Open source software security mobilization plan. This is in response to software supply chain attacks And one renewed interest in securing them.

Supply chains are attractive targets for malicious actors as they can compromise a single point and have a cascading impact on the customer ecosystem as the solar winds and Log4j the attacks showed.

The Open Source Software Security Mobilization Plan helps ensure that the momentum of earlier market efforts to strengthen supply chains does not wane. Here are the key takeaways for security managers.

Objectives of the mobilization plan for the security of open source software

The plan has three high-level objectives:

  • Securing OSS production
  • Improve vulnerability discovery and remediation
  • Shortened ecosystem patch response time

Each objective is associated with flows that describe tactical actions to help achieve it. The plan also highlights how ubiquitous OSS usage is, with approximately 70-90% of software stacks made up of OSS components. The plan emphasizes the need for strategic investments to achieve a resilient software supply chain ecosystem.

Securing OSS production

This objective focuses on slowing down insecure code issues at the source. Security literacy needs to be democratized and developers need to be equipped with the knowledge to write secure code early in the software development life cycle (SDLC). To achieve this goal, the plan focuses on three key actions:

Secure development training and certification, free or affordable: One option highlighted is the OpenSSF Secure Software Basics Providing these options and driving their adoption by academia and industry can create more security-aware development.

Created an objective, metric-based risk assessment dashboard for the top 10,000 OSS components: This would facilitate security industry-wide visibility into some of the most widely used OSS components, leveraging options such as Secure Scorecard.

This could lead to better industry awareness of 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 started creating inventories of software assets by asking software vendors about their SBOMs/SaaSBOM and internal development efforts.

Accelerating the adoption of software release digital signatures: By doing so, those who create and consume software have a level of validation around the OSS components they use. If you dig into the appendix of the plan, you will see efforts such as Signstore Emphasis is placed on Supply Chain Tiers for Software Artifacts (SLSA) and workload identities and attestations, where organizations like Chainguard and TestifySec are making waves.

Finally, just like developer training, there are other methods that can be used to completely eliminate vulnerabilities. One point is to replace in-memory insecure languages. The most notable examples here are the move from C and C++ to alternatives such as Go and Rust.

Improve vulnerability discovery and remediation

While efforts such as bug bounties and the like have contributed to the discovery and patching of vulnerabilities in commercial and government off-the-shelf (COTS/GOTS) software environments, the same cannot be said for the OSS ecosystem. OSS maintainers are largely voluntary and unpaid. The plan emphasizes investment to improve both discovery and remediation of vulnerabilities in critical OSS components and projects.

The initial flow here is to create an Open Source OpenSSF Security Incident Response Team. This team would be funded and positioned to fill the gaps identified above and assist OSS projects in resolving discovered vulnerabilities, particularly in cases where the OSS project may be understaffed or not equipped to address them quickly.

While this does not stop vulnerabilities, it does ensure that they are quickly resolved and patches/updates are made available to downstream consumers faster.

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

Another part of this goal is to perform 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 examine components to identify vulnerabilities to fix.

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

Shorten ecosystem patch response time

This goal is not just to find and fix vulnerabilities at the source of components, but to ensure that associated updates downstream are distributed and implemented throughout the software supply chain. You can’t prevent a vulnerable component from wreaking havoc if downstream consumers haven’t updated properly. This is a problem that we always face as an industry when it comes to patch management.

Flows associated with this objective involve improving adoption, training, and tools associated with SBOMs. This is essential because without the widespread adoption and operationalization of SBOMs, organizations will not be able to understand the components they use in their environments and respond accordingly. This includes integrating it into leading software authoring tools, improving training and awareness, and standardizing SBOM production and consumption.

The final component associated with this goal is to harden the most critical OSS build systems, package managers, and distribution systems.

Improving security at the software artifact distribution layer can reduce risk across the ecosystem. It will also improve confidence in the composition and provenance of software components, a key feature of the previously mentioned NIST SSDF.

Next steps

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

Although some may criticize the plan, it is an important 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 as malicious actors increasingly exploit the fragmented and fragile software supply chain and we need to act.

Join the newsletter!

Error: Please verify your email address.

open-source tags

Comments are closed.