The OpenSSF recently released its Open Source Project Security Baseline (OSPS Baseline), and it is a valuable resource for anyone working with open source software. Released in February, this initiative provides a structured framework of security requirements to help strengthen the security posture of open source projects.
What is OSPS Baseline?
The OSPS Baseline is a security checklist for projects at all stages, supporting progressive improvements as your project matures. It organizes security best practices into three maturity levels, helping projects implement appropriate security measures based on their size and user base. The elegance of this approach is that it compiles existing guidance and resources from OpenSSF and other security groups into actionable tasks that enhance software security.
As Stacey Potter, who helped lead the OSPS Baseline pilot efforts, puts it: "We know it can be tough to navigate all the security standards out there, so we built a framework that grows with your project. Our goal is to take the guesswork out of it and help maintainers feel confident about where they stand, without adding extra stress."
The Three-Tiered Approach
OSPS Baseline is organized into three maturity levels that evolve with your project:
Level 1: The Security Foundation
This level is designed for any code or non-code project with any number of maintainers or users. Think of it as your security starter kit. Some of these controls include:
- Multi-factor authentication for sensitive resources
- Default low-privilege permissions for collaborators
- Branch protection to prevent accidental changes
- Secure communication channels (HTTPS/SSH)
- Clear documentation for reporting defects
- Public discussion mechanisms for proposed changes
The controls at this first level ensure that basic security needs are met, and many are straightforward and easy to implement, such as OSPS-AC-03.02, which requires branch protection to guard against the deletion of the project’s primary branch.
Level 2: Growing Projects
For code projects with at least two maintainers and a small number of consistent users, Level 2 builds on Level 1 with additional controls like:
- Unique version identifiers for releases
- Signed releases with cryptographic hashes
- Documentation of project roles and responsibilities
- Automated testing requirements
- Security assessment processes
- Private vulnerability reporting channels
This next level of controls reflects the needs of a growing project with multiple maintainers and a growing user base. It involves implementing some additional measures that elevate the project’s security and make project users’ experience easier by following established versioning best practices, signed releases, and some automated testing, all of which elevate trust in the project.
Level 3: Mature Projects
For code projects with a large user base, Level 3 introduces more advanced controls:
- Comprehensive threat modeling and attack surface analysis
- Software Bills of Materials (SBOMs) for all releases
- Non-exploitability documentation (VEX)
- Static Analysis Security Testing (SAST) policies
- Detailed support lifecycle documentation
- Rigorous code review requirements
Level 3 projects implement even higher standards like control OSPS-SA-03.02, which states that for each release, a project must perform a threat modeling and attack surface analysis to “understand and protect against attacks on critical code paths, functions, and interactions within the system." Following these requirements enables project maintainers to identify potential vulnerabilities before attackers can exploit them and indicates a level of care appropriate to mature projects with a large number of users.
Why Should Developers Care?
Security can feel like a chore at times, but there is real value in implementing these practices. The OSPS Baseline takes much of the mystery out of "doing security the right way" with clear, actionable steps. When your project follows these guidelines, users notice—it builds trust and can boost adoption. Additionally, you'll be on your way to aligning with regulations like the EU Cyber Resilience Act and NIST's Secure Software Development Framework. I appreciate that this approach allows maintainers to gradually elevate their security practices concurrently with the growth of their projects. Start small with Level 1 and level up as your project matures. It's also a great help when onboarding new contributors—they can quickly get up to speed on your security practices and hit the ground running.
How Does This Differ From Other OpenSSF Tools?
You've probably heard of the OpenSSF Scorecard and the Best Practices Badge, possibly even from me. Here's how OSPS Baseline fits in:
- OpenSSF Scorecard is an automated grading tool. OSPS Baseline fills in the gaps where projects struggle to achieve good results using Scorecard.
- Best Practices Badge covers the whole project health spectrum. OSPS Baseline zeroes in specifically on security aspects that the Badge program doesn't fully address.
The FAQ puts it perfectly: "The OSPS Baseline is a minimal security checklist – you can think of it like the minimum set of things you do to make sure your identity isn't compromised or that you get your kid to school on time every day with no issues."
Getting Started
Ready to improve your project's security posture? Here's how:
- Start with Level 1 controls, which establish a "universal security floor" for all open source projects.
- Projects can self-attest their OSPS Baseline compliance (tooling for verification is being developed).
- Check out the detailed documentation to understand each control's rationale and implementation recommendations.
The OSPS Baseline is an open source approach to solving security challenges. The Baseline was developed with input from open source contributors, maintainers, and technical leaders who understand the unique challenges of open source development.
Once you are ready to dive in, visit the OSPS Baseline website to learn more and join the conversation in the #sig-security-baseline channel in the OpenSSF Slack.
Remember, every security improvement strengthens not just your project, but the entire software ecosystem.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.