OpenSSF Security Baseline (OSPS Baseline): what it actually requires

Before OSPS Baseline, a device maker or downstream consumer asking "is this open-source dependency secure enough to ship inside our product" had no single, implementable checklist to point a maintainer at — only a scattering of separate OpenSSF guides, badge criteria and ad-hoc vendor questionnaires. OpenSSF's Chief Security Architect, Christopher Robinson, called the release "a significant milestone in advancing security initiatives within the open source ecosystem," and project lead Eddie Knight (Sonatype) framed it as "an important step toward efficiently addressing the security and resilience of open source projects." The baseline compiles existing OpenSSF and industry guidance into one tiered document a maintainer can actually implement a control at a time, and a downstream consumer — including a device maker under CRA Annex I obligations for the open-source components it ships — can point to as evidence that a given dependency meets a defined bar.

The three OpenSSF projects answer different questions. OpenSSF Scorecard runs automated checks against a repository from the outside and produces a numeric score — useful for triaging thousands of dependencies quickly, but not a checklist a maintainer implements control-by-control. The Best Practices Badge (see our dedicated guide) is a self-certification questionnaire a project fills in once to earn a badge. OSPS Baseline is explicitly written for maintainers to build toward as an ongoing practice, is organized by project maturity rather than a single score, and ships with its own mappings to the Best Practices Badge, NIST CSF, OCRE and OpenChain — so a project that already holds a Best Practices Badge does not have to start its OSPS Baseline work from an empty page.

Level 1 applies to any code or non-code project, regardless of how many maintainers or users it has — the minimum bar. Level 2 applies to a code project with at least two maintainers and a small but consistent user base. Level 3 applies to a code project with a large number of consistent users, where the blast radius of a compromise is largest. A project self-assesses which level actually describes it today — a two-person library used by a handful of other projects is Level 2, not Level 3 — and Level 2/3 controls add to, rather than replace, the level below.

The controls are grouped into eight categories: Access Control, Build and Release, Documentation, Governance, Legal, Quality, Security Assessment, and Vulnerability Management. Each control uses an OSPS-[Family]-[Number] identifier — for example, a Vulnerability Management control in that numbering scheme governs how a project runs its own vulnerability-reporting workflow — and is written with explicit MUST/MUST NOT requirement language, separated from non-mandatory implementation recommendations, specifically so a control can be checked rather than interpreted. Early adopters named in OpenSSF's own materials include GUAC and bomctl (vulnerability-reporting workflow controls), OpenTelemetry (build-pipeline hardening) and OpenVEX (automated SBOM generation controls) — real projects implementing specific, numbered controls rather than a vague "yes, we take security seriously."

Indirectly, and usefully so. OpenSSF's own release describes the baseline as aligning "with global cybersecurity frameworks, including the EU Cyber Resilience Act (CRA) and NIST Secure Software Development Framework (SSDF)." That alignment matters because the CRA places real obligations on manufacturers for the open-source components they integrate (see our CRA open-source software steward obligations guide) — a device maker can point to a dependency's OSPS Baseline level as part of its own component-selection evidence. OSPS Baseline is not, however, one of the CEN/CENELEC/ETSI harmonised standards being drafted under the CRA's own standardisation request, and does not itself confer presumption of conformity under CRA Article 27 — it is useful supporting evidence, not a legal substitute for the Regulation's own conformity route.

SoftWSP's firmware security assessments inventory the open-source components actually shipping inside a device's firmware image and the known vulnerabilities affecting them — the same component-level detail an OSPS Baseline-aware CRA open-source risk assessment needs, generated from the binary rather than assumed from a build manifest. See device & firmware security services for how that fits into a broader firmware assessment.

This guide is based on OpenSSF's own 25 February 2025 press release announcing OSPS Baseline, the official specification site at baseline.openssf.org, the github.com/ossf/security-baseline source repository (version 2026.08.28), and OpenSSF's February 2025 newsletter, all read directly for this guide. Control counts and category names reflect version 2026.08.28 specifically and may change in later releases; check baseline.openssf.org for the current version before citing a specific control ID.