The Open Source Project Security (OSPS) Baseline is a set of security controls that open source projects should meet, organized by maturity level and category. It gives maintainers a checklist and gives consumers a shared way to read a project's security posture. Always cite the specific version you assess against.
Definition
The baseline is maintained by the OpenSSF Security Baseline SIG under its project governance documentation. It is described as a minimum definition of requirements for a project relative to its maturity level. As of this review the current version on the project site is v2026.08.28, with earlier versions kept for historical reference and an in-development version alongside.
Design principles
The site lists four principles for its work:
- Focused. Controls contain MUST entries, not SHOULD.
- Realistic. Controls are practical for maintainers at the appropriate level.
- Actionable. Controls give specific recommendations.
- Meaningful. Controls affect security posture, because ineffective controls add to maintainer burden.
That last point is worth noting for consumers. A baseline that respects maintainer time is more likely to be adopted by small projects.
How versions work
Versions are managed under a maintenance process. The site tells downstream consumers to specify compliance against a specific version, and says only the version labeled current should be used for new compliance efforts. So write "assessed against v2026.08.28", not "meets the baseline". Check the site for the current version when you read this, since it will move.
How consumers can use it
- Ask for it. Add a question to your review: does the project assess itself against the baseline, and which version and level?
- Read the level, not a pass mark. The controls are organized by maturity, so a younger project can sensibly sit at a lower level.
- Pair it with evidence. Self-assessment is a claim. Check branch protection, release signing and the security policy yourself.
- Compare with automated checks. See OpenSSF Scorecard v6 and the baseline and badge versus Scorecard.
- Record it. Keep the version, level and date in the dependency record.
What it does not tell you
It does not show whether a specific release is free of malicious code or known vulnerabilities. A project can meet controls and still ship a flawed release. Use it as one input beside advisory data and your own testing.
A realistic use
Do not demand the baseline from every small dependency. Start with the ten components that carry the most risk to you, ask maintainers where they stand, and note gaps as risks with owners. If you maintain a project, treat the checklist as a to-do list.
For a compliance team, a version-cited assessment is also easier to put in evidence than a general statement about good practice. Safeguard can help with the inventory part. Its SBOM and dependency scanning lists what your projects actually pull in, so you can see which components you depend on and decide where to look closer. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is the OSPS Baseline a certification?
No. It is a set of controls by maturity level that projects and consumers use to assess posture.
Which version should I cite?
The site says to specify a specific version and use the one labeled current for new efforts.
Sources
Last reviewed: 19 October 2026.
