By Omkhar Arasaratnam (OpenSSF) and David A. Wheeler (OpenSSF)

We’re excited about the announcement of the US Cybersecurity and Infrastructure Security Agency (CISA)’s Open Source Software Security Roadmap. The Roadmap, released today, clearly articulates a risk assessment and implementation plan to help secure open source software (OSS) usage in the US Federal Government and private sector. The traceability back to other US Federal initiatives, such as the National Cybersecurity Strategy and the Open-Source Software Security Initiative (OS3I) RFI, further enforces a “one government” approach. We believe this focused and collaborative approach is the most effective way for the US government to work with the open source community and private sector.

Where can OpenSSF Help?

The Open Source Security Foundation (OpenSSF) is uniquely positioned to assist with several areas within the Roadmap. For example:

Goal 1: Establish CISA’s Role in Supporting the Security of OSS

The OpenSSF has been the community’s primary foundation for securing open source software for over three years. As CISA increases its focus on partnering with OSS communities and international partners, the OpenSSF looks forward to helping by fostering relationships in support of this goal.

Some statements within the Roadmap suggest a practical approach to improving security. One is, “CISA will show up as an OSS community member, working hand-in-hand with OSS communities.” Collaboration is key to improvement, and we expect this kind of open collaboration to produce many benefits. We’re also pleased to see the statement, “OSS is a public good, providing benefits for governments and private sector organizations worldwide.” Acknowledging the need to partner worldwide will significantly amplify the positive results. OpenSSF supports and fosters these connections between the open source and international communities, including CISA.

Goal 1 acknowledges that “centralized OSS entities such as package managers and code hosting services can help drive systemic security improvements.” The OpenSSF is already working with these groups, such as through our Securing Software Repositories Working Group (WG) and Alpha-Omega. We first conducted a Package Manager Security Landscape Survey to contrast their security capabilities. We then developed Build Provenance for All Package Registries guidance to encourage improvements across all repositories. Some repositories have already implemented new best practices with support from other repositories. For example, the Python Package Index (PyPI) implemented a new 2FA mandate based on the experience of JavaScript’s npm. Some projects are adopting OpenSSF capabilities to improve security, like npm, which has added an easy mechanism to generate signed provenance attestations (building on Sigstore and SLSA) and publish these results in npm to counter tampering with a package’s build process.

Another kind of centralized service the OpenSSF operates is Sigstore that provides digital signing and verification for artifacts. Digital signatures enable receivers to verify that the software package they received was intended by the sender and who the sender was. Digital signatures counter many attacks that involve tricking users into installing malicious packages provided by an adversary. Unfortunately, past digital signature services have either been impractical for OSS or too hard to use. . Sigstore General Availability (GA) began in October 2022. Sigstore is used for signing releases of CPython, Kubernetes Artifacts, and as part of npm package provenance. We also have a free course on how to use Sigstore. Over 32 million entries have been recorded for signatures within Sigstore’s public signature transparency log, spanning over 17,000 unique OSS projects, including Kubernetes, CPython, LLVM, KNative, Istio, and ArgoCD.

Goal 2: Drive Visibility into OSS Usage and Risks

OpenSSF, in partnership with Linux Foundation Research, has conducted research initiatives to broaden community understanding of open source usage. One example is the publication of Census II of OSS: Application Libraries, a report in collaboration with the Laboratory of Innovation Science at Harvard (LISH) that analyzed data from SCA vendors to identify the most widely used OSS.  We are planning an upcoming Census III report with LISH that aims to expand this understanding even further. The Linux Foundation’s research experience uniquely positions us to help CISA understand the landscape of OSS used in the public sector and critical infrastructure.

In addition, the OpenSSF also has experience through the Securing Critical Projects WG in prioritizing the most significant OSS projects by risk and actively using this method to prioritize our focus on Alpha-Omega.

Goal 3: Reduce Risks to the Federal Government

The OpenSSF has developed many resources to help all OSS users select and use OSS wisely. This includes the Concise Guide for Evaluating Open Source Software as well as evaluation frameworks such as OpenSSF Scorecard, OpenSSF Best Practices Badge, SLSA, and S2C2F. We are working on ways to more easily combine available data for risk analysis through a Security dashboard.

The OpenSSF is also developing a response to the White House Office of the National Cyber Director (ONCD) and its partners in the OS3I, who announced a Request For Information (RFI) on open source software (OSS) security and memory safe programming languages, as is available via the Federal Register. The OpenSSF is very supportive of “one government” approaches such as this RFI as a unifying vehicle across the US Federal government to get the open source software community’s input.

The Linux Foundation has long recommended and supported the creation of an Open Source Program Office (OSPO) within each public or private sector organization. The Linux Foundation (LF) Open Source Guide on Creating an Open Source Program provides a helpful overview. This guide was created in partnership with the TODO (Talk Openly, Develop Openly) Group, a professional open source networking group at The Linux Foundation. The TODO Group also has many other resources that could be helpful.

Goal 4: Harden the OSS Ecosystem

The OpenSSF is actively working to harden the OSS ecosystem, including efforts to:

1. Advance SBOMs within OSS Supply Chains.
   • The Linux Foundation supports and develops the SPDX (Software Package Data eXchange) SBOM format, which is nearing its SPDX 3.0 release. We believe in SPDX as a great SBOM format for consistency, simplicity and expandability across the open source software ecosystem
   • OpenSSF funded spdx/tools-python to improve SBOM handling as part of our tooling WG. Our OpenSSF “security toolbelt” group is developing a plan for a secure workbench of capabilities, including automatically generating software bill of materials (SBOMs) for OSS.
2. Foster Security Education for Open Source Developers.
   • We developed and maintain courses for software developers on the fundamentals of developing secure software; as of August 2023, 20,019 developers have enrolled. We are developing more materials for hands-on and in-depth learning, building on the materials listed above and the security knowledge framework. We also intend to release a course for managers on developing secure software. Our education work is part of the OpenSSF Best Practices WG.
3. Publish Guidance on OSS Security Usage Best Practices.
   • We’ve developed many guides for developers and consumers, e.g., the Concise Guide for Developing More Secure Software, Concise Guide for Evaluating Open Source Software, and the npm Best Practices Guide. We’re developing more guides, e.g., Compiler Options Hardening Guide for C and C++ and Source Code Management (SCM) Platform Configuration Best Practices. Broader guidance can be found in our OpenSSF Scorecard, OpenSSF Best Practices GitHub Badge, SLSA, and S2C2F frameworks, which we plan to evolve.
4. Foster OSS Vulnerability Disclosure and Response.
   • Guides. We’ve developed guides to help OSS maintainers handle vulnerability disclosure, specifically the Guide to implementing a coordinated vulnerability disclosure process for open source projects and Guidance for Security Researchers to Coordinate Vulnerability Disclosures with Open Source Software Projects.
   • Alpha-Omega. Our “Alpha-Omega” program, with $12.5M in corporate sponsorship, partners with OSS maintainers to systematically find and fix undiscovered vulnerabilities and improve their overall processes. Current partners include the Python Software Foundation (including funding a Python security developer-in-residence), the OpenJS Foundation and jQuery, the Eclipse Foundation, Node.js, and the Rust Foundation. All of these partners manage important, widely-used OSS, so the security improvements we implement together will substantially improve security for all. The 2022 Alpha-Omega report summarizes 2022 accomplishments.
   • Security audits. We’ve performed security audits of some widely-used OSS, often via Alpha-Omega, including Eclipse Equinox P2 (a widely used provisioning platform), Sigstore, Jackson-Core and Jackson-Databind, and slf4j (a logging framework).
   • OSV. The Open Source Vulnerability (OSV) Schema is a machine-readable format that precisely maps vulnerabilities to open source package versions or commit hashes. OSV enables rapid automatic identification of vulnerable components so projects and organizations can update them; 18 ecosystems use OSV today.

Conclusion

Much of the work proposed by the Roadmap is already under active development at the OpenSSF. The OpenSSF has proven experience supporting government agencies by collaborating with the Open Source community, such as our recent support of Defense Advanced Research Projects Agency (DARPA)’s AI Cyber Challenge, which is a two-year competition asking the best and brightest in AI and cybersecurity to defend the software on which all Americans rely. We look forward to partnering with CISA on fulfilling the objectives in the Open Source Software Security Roadmap and helping secure open source software for the public good.