
Open source software (OSS) forms the foundation of many steps in the software supply chain, so securing it is essential to safeguard vast and diverse networks and data. The Open Source Security Foundation (OpenSSF) is dedicated to collaboration and cooperation among developers, security professionals, and other experts in an attempt to improve the security of open source software. Its services and resources include publishing security guides, offering free training courses, and fostering community discussions.
OpenSSF recently published a significant initiative, the Open Source Project Security (OSPS) Baseline, to detail a set of minimum security requirements for OSS projects. It outlines three maturity levels of OSS projects, each held to a different standard of security requirements. The OSPS Baseline initiative aims to establish a common understanding of what a strong OSS security posture looks like.
Understanding the OSPS Baseline
The baseline has been developed to establish a common standard of security measures that open source developers should follow to secure their software. The documentation includes mapping controls to other security frameworks and international standards. Each control is mapped to closely aligned external standards where possible, such as the EU’s Cyber Resilience Act (CRA), the NIST Secure Software Development Framework (SSDF) and Cyber Security Framework (CSF), and OWASP’s OpenCRE.
The size and maturity of the OSS project determine how stringent the controls must be to ensure minimum security requirements are met. The security practices are outlined in a tiered structure.
- Level 1 refers to all open source software projects with anyone maintaining or using them. These projects are subject to a number of requirements, including multi-factor authentication for access to sensitive resources, user guides for basic functionality, and publicly readable source code repository at a static URL.
- Level 2 refers to code projects with two or more maintainers and “a small number of consistent users.” All of the controls that apply to Level 1 also cover Level 2, along with additional requirements like documenting project members who have access to sensitive resources and performing security assessments.
- Level 3 refers to code projects with large numbers of consistent users. These projects are subject to the requirements for Levels 1 and 2 as well as a number of stricter controls, such as documenting statements regarding the scope and duration of support for each release and automatically evaluating all codebase changes for security weaknesses.
The Impact on Open Source Development
Because OSS can form the foundation of vast supply chains in various sectors, it is crucial for these projects to be developed as securely as possible. Open source developers are often willing to embrace initiatives to ensure better security, and providing a common standard to be met can help to guide them in developing secure open source projects. The baseline “sets a clear, necessary floor for open source security,” says Jason Soroko, Senior Fellow at Sectigo, a Scottsdale, Arizona-based provider of comprehensive certificate lifecycle management (CLM).
The baseline could play a significant role in improving software supply chain security, if it is used appropriately. Developers must approach the baseline controls as the bare minimum of security required for the type of project, not an ultimate goal that will cover all security needs. OSS consumers also have to do their due diligence in vetting the software that they use to ensure security. In this way, the baseline has potential, “but its success hinges on an industry culture that prizes proactive, adaptive security over checkbox compliance,” according to Soroko.
OSS projects can benefit from following the standards set forth in the OSPS Baseline and proactively exceeding the requirements to secure their code. Consumers looking into the security posture of the software they use will see value in software projects that meet the minimum requirements and more. These projects are also likely to gain a reputation for adhering to robust security measures and fortifying the security of the supply chain.
Compliance and Regulatory Alignment
The controls outlined in the OSPS Baseline support compliance with evolving cybersecurity regulations. A wide range of cybersecurity regulations require security measures that are part of the baseline, and the documentation equips readers to align the baseline requirements with those laid out in international regulations and industry standards. More OSS developers adopting the OSPS Baseline in their work can enable organizations to use secure software and reduce the risks associated with OSS.
Open source projects often form the foundation of many links in the supply chain, vast and interconnected networks relying on the same software and expecting a certain level of security from it. This can open organizations and individual users up to infiltration and attack via these third-party connections. Enterprise and government institutions using OSS in various projects can protect against attacks and mitigate risk by ensuring that the software they use adheres to a standard of security from development onward.
Future of the OSPS Baseline
The OSPS Baseline is in its first version at this time, released on February 25th, 2025. The ongoing progress of the initiative will utilize community collaboration and feedback to improve on the current version. The framework may evolve to more effectively reflect cross-industry security standards, meet new and changing regulations, or offer additional guidance in achieving the baseline.
Long-term, open source security can only be achieved as a collaborative effort, not just among developers and security professionals, but between consumers and organizations as well. The baseline can provide a framework for developers to build secure code, but individual and business OSS consumers must do their part to ensure that they find secure software to use and prioritize security and reliability in supply chain partners. With this kind of broad cooperation, the security landscape of OSS can improve for all.
Conclusion
The OSPS Baseline initiative is designed to offer OSS developers a resource for establishing a bare minimum of security in their projects. Depending on the size and maturity of the project, they are held to different criteria for the baseline, but all are encouraged to proactively invest in security beyond the minimum requirements. Open source maintainers and developers should look to adopt the OSPS Baseline to ensure that their projects meet a common standard of security across the board and provide supply chain partners with assurance in the security of their software.