To help open-source maintainers keep their projects secure, the Open Source Security Foundation (OpenSSF) has published a set of guidelines based on international cybersecurity frameworks, standards, and regulations, the Open Source Project Security Baseline.
The OSPS Baseline offers a tiered framework of security practices that evolve with project maturity. It compiles existing guidance from OpenSSF and other expert groups, outlining tasks, processes, artifacts, and configurations that enhance software development and consumption security.
The main goal behind the OpenSSF Baseline is to provide a solution to the security requirements of projects and teams of different sizes. In contrast, say the baseline maintainers, most commercial or industry-accepted frameworks and standards have been created with larger organizations in mind. They recognize the possibility of the OpenSSF baseline overlapping with other open-source security initiatives, including CISA’s and NIST’s. Still, they stress the importance of being defined by “open source contributors, maintainers, and technical leaders who have been working in and alongside open source projects for decades”.
According to OpenSSF, adhering to the baseline signals that a project has taken essential measures to reduce the risk of common vulnerabilities and improve its trustworthiness to adopters and contributors. However, the tool is not intended to be used to compare projects or as a scoring or grading mechanism.
The baseline was created by a team of maintainers from different organizations. One of them, Eddie Knight, currently with security firm Sonatype, explains how they leveraged insights from the widely adopted Best Practices Badge, Scorecard, and CLOMonitor.
Additionally, the baseline has been defined keeping in mind the requirements set in the EU Cyber Resilience Act (CRA) and the U.S. National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF) so that maintainers and open-source manufacturers may use it to improve compliance with regulatory requirements.
The OpenSSF Baseline is structured along three “project maturity” levels, so its users can choose the one that best fit their context and available resources, based on the idea that there is no “fits-all” security solution. So, at level 1, we find any project with any number of maintainers; at level 2, projects with at least two maintainers and a small number of users; at level 3, projects with a large numbers of users.
The baseline covers distinct security areas, such as access control, build and release, documentation, quality, vulnerability management, and more. For example, the access control section focuses on mechanisms to ensure access control for the project’s version systems and its CI/CD pipelines, such as following the principle of least privilege to assign CI/CD permissions, requiring multi-factor authentication for collaborators, and others.
Jamie Scott, Endor Labs product manager and former open-source contributor to Redis and StackRox, highlighted the risk the baseline might be misused, for example expecting that each open-source project should opt in. Furthermore, he stresses the importance of understanding that open-source security should be a shared responsibility between maintainers and companies using their projects, so “if you want to see a project mature, it’s your responsibility to help it”.
No automated tools to attest a project complies with the baseline exist yet. Waiting for them to become available in the future, project maintainers are suggested to use a self-attestation such as “As of April 31, 2025, this project complies with OSPS Baseline version 2025-02-30 level 2.”
The OpenSSF will regularly update the baseline over time to reflect new and improved best practices.
