OpenSSF OSPS Baseline Guide: Controls and Maturity Levels

Open source projects are asked to prove they are secure, yet most have no agreed minimum to measure themselves against. The OpenSSF Open Source Project Security Baseline (OSPS Baseline) fills that gap with a catalogue of MUST-level assessment requirements grouped into eight control families and three maturity levels. The current release is v2026.08.28, published by the OpenSSF Security Baseline SIG. This guide explains how the Baseline is structured, what each maturity level requires in practice, how to implement it on a typical forge such as GitHub or GitLab, how it relates to Scorecard, SLSA, the NIST SSDF and the EU Cyber Resilience Act, and how consumers of open source can use it. It is written for maintainers, open source programme office (OSPO) staff, foundation staff and the security teams who depend on upstream projects.

Key takeaways

It is a floor, not a score. The Baseline defines minimum requirements relative to a project's maturity and its FAQ says it is not intended as a scoring or comparison tool between projects.
Three maturity levels drive scope. Level 1 applies to any project, Level 2 to code projects with at least two maintainers and a small number of consistent users, Level 3 to code projects with a large number of consistent users.
Level 1 is mostly identity and hygiene. MFA on the authoritative repository, least-privilege collaborators, protected primary branch, no secrets or executables in version control, encrypted channels and a security contact.
Compliance is self-attested and point in time. The project recommends statements such as "as of a date, this project complies with OSPS Baseline version X level 2", so pin the version you assess against.
Mappings help, but do not certify. The release ships machine-readable mappings to frameworks including the NIST SSDF, SLSA, Scorecard, PCI DSS and the CRA, and the FAQ states mappings provide no claim of compliance and are not a substitute for audits.

What the OSPS Baseline is and how it is built

The Baseline is maintained in the ossf/security-baseline repository as YAML control catalogues using the Gemara schema, which makes it readable by people and by tooling. The release notes for v2026.08.28 record that the control mappings are now maintained as machine-readable Gemara mapping documents and that the content migrated to the Gemara v1 schema. Each release is tagged (for example v2026.02.19 and v2026.08.28), and the website marks one version as current while a development version continues on the main branch.

Control families: eight families, each with an abbreviation used in IDs: Access Control (AC), Build and Release (BR), Documentation (DO), Governance (GV), Legal (LE), Quality (QA), Security Assessment (SA) and Vulnerability Management (VM).
Controls: identified as OSPS-AC-01, each with a title and an objective.
Assessment requirements: the testable statements, identified as OSPS-AC-01.01, each with requirement text using MUST or MUST NOT, a recommendation on how to meet it, and the maturity levels it applies to.
Applicability: a requirement listed for Level 1 also applies at Levels 2 and 3, so the levels are cumulative.
Retired IDs: some requirements are retired rather than renumbered (OSPS-BR-01.02 is marked retired in the current release), so tooling and evidence should key on the ID and the release version together.

In the v2026.08.28 release, by our count of the catalogue, about 24 active assessment requirements start at Level 1, about 19 more are added at Level 2 and about 21 more at Level 3. Treat these as orientation: the definitive list is the release page for the version you assess against.

The control families and maturity levels at a glance

Family	Level 1 examples	Added at Level 2	Added at Level 3
Access Control (AC)	MFA for sensitive resources in the authoritative repository (AC-01.01); lowest privileges for new collaborators (AC-02.01); block direct commits and require confirmation to delete the primary branch (AC-03.01, AC-03.02)	CI/CD tasks default to the lowest permissions in the pipeline (AC-04.01)	Every CI/CD job assigned only the minimum privileges it needs (AC-04.02)
Build and Release (BR)	Sanitise untrusted metadata in pipelines (BR-01.01); no privileged credentials exposed to untrusted code snapshots (BR-01.03); encrypted project and distribution channels (BR-03.01, BR-03.02); prevent unencrypted secrets in version control (BR-07.01)	Unique release version identifiers (BR-02.01); change log with each release (BR-04.01); standardised dependency tooling (BR-05.01); signed releases or a signed manifest of hashes (BR-06.01)	Sanitise trusted collaborator input too (BR-01.04); every release asset tied to an identifier (BR-02.02); a documented secrets policy covering storage, access and rotation (BR-07.02)
Documentation (DO)	User guides for basic functionality (DO-01.01); how to report defects (DO-02.01)	How dependencies are selected, obtained and tracked (DO-06.01); build-from-source instructions (DO-07.01)	How to verify integrity, authenticity and author identity of releases (DO-03.01, DO-03.02); support scope and end of security updates (DO-04.01, DO-05.01)
Governance (GV)	Public discussion mechanism (GV-02.01); contribution process explained (GV-03.01)	List of members with access to sensitive resources and their roles (GV-01.01, GV-01.02); contributor requirements (GV-03.02)	Review of collaborators before granting escalated permissions (GV-04.01)
Legal (LE)	OSI or FSF approved licence for source and released assets (LE-02.01, LE-02.02); licence in a well-known location such as LICENSE, COPYING or LICENSES/ (LE-03.01, LE-03.02)	Contributors assert the right to commit on every commit, for example a DCO sign-off (LE-01.01)	No additions
Quality (QA)	Public source and change history (QA-01.01, QA-01.02); dependency list for direct dependencies (QA-02.01); list of codebases (QA-04.01); no generated executables or unreviewable binaries in version control (QA-05.01, QA-05.02)	Status checks pass or are manually bypassed (QA-03.01); at least one automated test suite before acceptance (QA-06.01)	SBOM with compiled released assets (QA-02.02); subprojects at least as strict (QA-04.02); documented test environments and test policy (QA-06.02, QA-06.03); one non-author human approval before merge (QA-07.01)
Security Assessment (SA)	No Level 1 requirements	Design documentation of actors and actions (SA-01.01); external interface descriptions (SA-02.01); a security assessment (SA-03.01)	Threat modelling and attack surface analysis (SA-03.02)
Vulnerability Management (VM)	Security contacts published (VM-02.01)	CVD policy (VM-01.01); private vulnerability reporting (VM-03.01); public data on discovered vulnerabilities (VM-04.01)	VEX for non-affecting vulnerabilities (VM-04.02); SCA remediation thresholds and blocking (VM-05.01 to VM-05.03); SAST threshold and automated enforcement (VM-06.01, VM-06.02)

Where identity fits

Many of the Level 1 requirements are identity controls in disguise, which is why the Baseline matters to anyone managing developer and machine credentials. The recommendation for OSPS-AC-01.01 notes that passkeys are acceptable for MFA on the version control system. The non-human side is just as prominent:

Pipeline tokens: AC-04.01 and AC-04.02 require CI/CD jobs to default to, and be assigned, the minimum permissions. On GitHub Actions this means setting the default GITHUB_TOKEN permissions to read-only at organisation or repository level and declaring a permissions: block per job. See the GitHub and GitHub Actions Security Guide.
Untrusted code and secrets: BR-01.03 forbids exposing privileged credentials to untrusted code snapshots, the classic risk of running fork pull requests with repository secrets. See the OWASP CI/CD Top 10 CICD-SEC-4 Poisoned Pipeline Execution Guide.
Publishing credentials: long-lived registry tokens are the asset most often stolen in package compromises. Prefer OIDC-based trusted publishing where the registry supports it. See the npm Trusted Publishing and Provenance Guide and the PyPI API Tokens and Trusted Publishing Security Guide.
Secrets policy: BR-07.01 (Level 1) requires preventing unencrypted secrets in version control; BR-07.02 (Level 3) requires a written policy for storing, accessing and rotating them.
Privilege reviews: GV-01.01 asks projects to list members with access to sensitive resources and GV-04.01 asks for review before escalation. The XZ Utils backdoor showed what happens when a persona earns release rights over two years with no structured review, and that the payload sat in release tarballs rather than the reviewed git source.

How to implement the Baseline on a project

Pick the level honestly. Use the Baseline's own definitions: a single-maintainer library is Level 1, even if it is popular; once you have two or more maintainers and regular users aim for Level 2; a widely depended-on project should target Level 3. Record the release version (for example v2026.08.28) you are assessing against.
Use the checklist for that release. Each release publishes a checklist page in the repository's docs. Copy it into an issue or a SECURITY-BASELINE.md file and record evidence per requirement ID.
Close Level 1 forge settings first. Require MFA for the organisation, set default repository role to read, enable a branch ruleset or protection on the primary branch that blocks direct pushes and deletion, enable secret scanning with push protection, and publish a security contact (a SECURITY.md file is the usual place).
Harden the pipeline. Set default token permissions to read-only, add per-job permissions:, stop running privileged workflows on fork code, and treat branch names, pull request titles and commit messages as untrusted input (BR-01.01 recommends quoting, escaping or exiting on unexpected values). Pin third-party actions to full commit SHAs.
Add release integrity for Level 2. Unique versions, a change log, signed releases or a signed checksum manifest, and dependency management through the ecosystem's standard tool with a lockfile. Sigstore keyless signing or registry provenance are common routes. See the Code Signing Security Guide.
Add governance and disclosure for Level 2. A MAINTAINERS or governance file listing who holds sensitive access, a CVD policy, private vulnerability reporting enabled on the forge, and published advisories for fixed issues. See the Bug Bounty and Vulnerability Disclosure Guide.
Add assurance for Level 3. SBOMs with compiled releases, VEX for non-affecting findings, written SCA and SAST remediation thresholds enforced in CI, mandatory non-author review, threat model documentation, and published support windows.
Verify and publish. Run OpenSSF Scorecard as a partial automated check (the release maps controls such as AC-03 to Scorecard's Branch-Protection check and BR-01 to Dangerous-Workflow), then publish a dated self-attestation naming the Baseline version and level.
Re-assess on each Baseline release. Read the release notes: v2026.02.19 added three requirements (BR-01.03 at Level 1, DO-07.01 at Level 2, BR-01.04 at Level 3), so a project that complied with an earlier version may not comply with the new one.

Rollback and exceptions: settings such as strict branch rules or required checks can block urgent fixes. QA-03.01 explicitly allows status checks to be "manually bypassed", so document who may bypass and log each use rather than disabling the rule.

Choosing a level and a verification approach

Situation	Sensible target	Verification	Trade-off
Solo maintainer, small user base	Level 1	Self-attestation plus Scorecard	Level 2 governance items assume at least two maintainers
Team-maintained library with regular users	Level 2	Self-attestation with linked evidence (settings screenshots, policy files)	Signing and change logs add release effort
Critical dependency or foundation flagship	Level 3	Self-attestation reviewed by the foundation or an OSPO	Threat models, SBOM, VEX and SAST thresholds need sustained effort
Corporate project released as open source	Level 2 or 3 by policy	Internal audit against the release checklist	Commercial obligations (for example CRA manufacturer duties) go beyond the Baseline

The Baseline FAQ says no project is required to meet any level unless a sponsoring organisation such as a foundation imposes it, but encourages every project to meet Level 1 as a universal floor. For consumers, the FAQ notes many controls are publicly observable while others concern privileged settings, so you either accept the project's self-attestation or agree another arrangement with the project.

How the Baseline relates to other frameworks

Framework	Relationship	How to use them together
OpenSSF Scorecard	Automated heuristics scored 0 to 10; the Baseline FAQ describes Baseline as accounting for gaps projects experience with Scorecard	Use Scorecard for continuous signals, the Baseline for the requirement set. See the OpenSSF Scorecard Guide.
OpenSSF Best Practices Badge	Broader self-assessment covering more than security	Badge for overall project practice, Baseline for security minimums
NIST SSDF (SP 800-218)	Release mappings link Baseline controls to SSDF practices such as PO.3.2, PS.1, PS.2 and PS.3	A producer following the SSDF can use Baseline evidence for its open source components. See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide.
SLSA	Mappings link build and release controls to SLSA build platform requirements such as provenance generation	Use SLSA for build provenance depth beyond BR-06
EU Cyber Resilience Act	A draft mapping relates Baseline controls to CRA Annex I essential requirements (for example AC-01 to points 1.2d to 1.2f)	Supporting evidence for open source stewards and manufacturers integrating open source; not a conformity assessment. See the EU Cyber Resilience Act Guide.
Others mapped in the repository	NIST SP 800-161, BSI TR-03185-2, ISO/IEC 18974, OpenCRE, PCI DSS, OWASP SAMM, UK Software Security Code of Practice	Crosswalk pages per release list external requirement to OSPS control

The CRA (Regulation (EU) 2024/2847) recognises open-source software stewards as a distinct role with lighter obligations than manufacturers, including a documented cybersecurity policy and cooperation with market surveillance authorities. The Baseline gives stewards and foundations a concrete, public control set to point to, but the mapping file is marked draft and its relationships are "relates-to" without strength or confidence ratings, so treat it as a starting crosswalk.

Using the Baseline as a consumer of open source

Intake policy: ask for a dated Baseline attestation for critical dependencies, alongside Scorecard results. Level 1 is a reasonable minimum ask; Level 3 is a reasonable expectation for dependencies on your critical path.
Evidence you can check yourself: public repository and history, licence location, SECURITY.md and contacts, signed releases, change logs, SBOMs and published advisories are all observable without privileged access.
Evidence you cannot see: MFA enforcement, collaborator defaults and pipeline token permissions are private settings; rely on attestation and on outcomes such as Scorecard token-permission findings.
Help projects level up: the FAQ encourages adopters to participate in supporting projects rather than using the Baseline to rank them. Funding, pull requests that add SECURITY.md or signing, and engineer time are more effective than questionnaires.
Feed results into supplier risk: see the Open Source Security Guide and the NIST SP 800-161 Cyber Supply Chain Risk Management Guide.

Detection and measurement

For a project, and for an OSPO tracking many projects, monitor:

Forge audit logs: changes to branch rules, collaborator roles, MFA requirement, default token permissions and secret scanning settings; bypasses of required checks.
Pipeline signals: workflows triggered by forks that reference secrets, actions not pinned to a SHA, and jobs without explicit permissions.
Release signals: releases published without signatures, checksums or a change log, and releases built outside the CI system.

Metrics that show the programme is working:

Percentage of in-scope projects with a current attestation at their target level, against a named Baseline version.
Number of Level 1 requirements failing across the portfolio, trended monthly (target zero).
Percentage of releases signed or covered by a signed hash manifest.
Percentage of CI jobs with explicit least-privilege permissions.
Median time from private vulnerability report to published advisory.

Common failure patterns

Attesting without a version: the requirement set changes between releases, so "we meet Level 2" without a version and date is unverifiable.
Branch protection with an admin bypass: AC-03.01 is meant to prevent direct commits; exempting administrators or a bot quietly reopens the path.
Over-privileged bot tokens: the tj-actions/changed-files compromise used a stolen bot account token to repoint release tags, and affected workflows printed CI/CD secrets into build logs. Least-privilege pipeline permissions (AC-04) and SHA pinning by consumers limit the blast radius.
Reviewing git but shipping something else: QA-05 bans unreviewable binaries in version control, but release tarballs built off-pipeline can still diverge from source, as the XZ Utils case showed. Build releases in CI and sign what CI produced.
Policy files that nobody enforces: Level 3 asks for SCA and SAST thresholds and automated enforcement (VM-05.03, VM-06.02). A written threshold without a blocking check does not meet the intent.
Treating mappings as compliance: the FAQ is explicit that mappings are not a substitute for audits, and the CRA mapping is draft.

Framework mapping

Baseline area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	MITRE ATT&CK risk addressed
Access Control (AC-01 to AC-04)	PR.PS-06	IA-2, AC-6	T1195.002 Compromise Software Supply Chain
Build and Release (BR-02, BR-06)	PR.PS-06	SR-4, SR-11, CM-14, SI-7	T1195.002 Compromise Software Supply Chain
Dependencies (BR-05, QA-02, VM-05)	GV.SC-05	SR-3, RA-5	T1195.001 Compromise Software Dependencies and Development Tools
Quality and assessment (QA-06, QA-07, SA-03, VM-06)	PR.PS-06	SA-11, SA-15, SA-8	Not technique specific
Vulnerability management (VM-01 to VM-04)	ID.RA-08	RA-5	Not technique specific

This table is our own alignment for orientation. The official crosswalks are the mapping documents published with each Baseline release.

Practitioner checklist

Record the Baseline version (currently v2026.08.28) and target level for each project.
Enforce MFA, read-only default collaborator roles and primary branch protection with no silent bypasses.
Enable secret scanning with push protection and remove executables and unreviewable binaries from repositories.
Set default CI token permissions to read-only and declare per-job permissions; keep secrets away from fork-triggered runs.
Publish SECURITY.md with contacts, enable private vulnerability reporting and adopt a CVD policy.
Sign releases or a checksum manifest, publish change logs and document how users verify both.
At Level 3, ship SBOMs and VEX, enforce SCA and SAST thresholds in CI and require non-author review.
Run Scorecard continuously and publish a dated self-attestation with links to evidence.
Re-assess when a new Baseline release appears and log changes against the release notes.

OpenSSF OSPS Baseline Guide: Security Levels for Open Source Projects