Software Supply Chain Levels Comparison: SLSA vs SSDF vs S2C2F vs OSPS

SLSA, the NIST SSDF, the OpenSSF S2C2F and the OSPS Baseline all claim the software supply chain, so teams often adopt one, assume it covers everything, and leave the gaps between them open. In practice they answer different questions: how an artifact was built and from what source (SLSA), whether a producer runs a secure development programme (SSDF), how an organisation safely consumes open source (S2C2F), and whether an open source project meets a security baseline (OSPS). This guide compares scope, structure, levels, evidence and current status as checked on 27 October 2026, then shows how to combine them without duplicate work. It is for AppSec and platform leads, supplier assurance teams and open source programme offices. For the overall discipline see the Software Supply Chain Security Guide.

Key takeaways

• They are complements, not competitors. SSDF is the programme, SLSA is artifact and source integrity evidence, S2C2F is the consumer's intake discipline, and OSPS Baseline is the upstream project's hygiene.
• Only two have graded levels you can attest per artifact. SLSA Build L0 to L3 and Source L1 to L4 apply to each artifact or revision; S2C2F and OSPS levels describe an organisation or a project.
• Check status before you cite. SLSA v1.2 is approved; SSDF v1.1 (SP 800-218) is final with Rev. 1 (SSDF v1.2) in draft; OSPS Baseline is versioned by date; S2C2F is a Supply Chain Integrity Working Group activity whose specification last changed in 2022.
• The consumption gap is real. Producer frameworks do not tell you how to stop a typosquatted package entering your build. S2C2F does, and the SLSA working draft now adds a Dependency Track built on it.
• Map once, evidence many times. S2C2F and OSPS Baseline publish their own mappings to SSDF and SLSA; reuse those rather than building a private crosswalk.

The four frameworks at a glance

SLSA: artifact and source integrity

SLSA v1.2 is the approved version on slsa.dev and is organised into tracks. Its levels are about trust in how something was produced, not about whether the code is free of vulnerabilities.

• Working draft direction: the SLSA working draft on GitHub (checked 27 October 2026) adds a Build Environment track and a Dependency Track. The Dependency Track defines a Dependency Ingestion Provenance attestation with three levels (Inventoried, Controlled, Screened) and imports the attestable subset of S2C2F, referring organisational S2C2F requirements to the OSPS Baseline. Treat this as draft: details can change before release.
• Where SLSA stops: SLSA does not cover vulnerability management, secure design or licence compliance. See the SLSA and Build Provenance Guide for implementation.

NIST SSDF: the producer's programme

SP 800-218 is a practice framework, not a level scheme. Its four practice groups are Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). Each practice contains tasks and implementation examples and references other standards. NIST published SP 800-218 Rev. 1, titled SSDF Version 1.2, as an Initial Public Draft on 17 December 2025, with comments closed on 30 January 2026; v1.1 remains the final version until NIST finalises the revision. SP 800-218A adds practices for generative AI and dual-use foundation models.

• Strength: broad. It covers people, process, tooling, protection of code and release integrity, and vulnerability response, and US federal software attestations are built on it. See the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide and the CISA Secure Software Attestation Form Guide.
• Limitation: it says what outcomes to achieve, not what evidence an individual artifact carries, and it is light on the consumer side of open source intake.

S2C2F: the consumer's intake discipline

The S2C2F specification organises 25 requirements under eight practices: Ingest it, Scan it, Inventory it, Update it, Audit it, Enforce it, Rebuild it, and Fix it and Upstream. Requirements are assigned to four maturity levels; the specification calls Level 4 (rebuilding OSS in a trusted environment, signing rebuilt packages and SBOMs, and private fixes) an aspirational north star best applied to the most critical dependencies. See the S2C2F Secure Supply Chain Consumption Framework Guide for the full requirement set.

• Threat-led: the specification maps real incident types to requirements, for example dependency confusion to ENF-1 and ENF-2, compromised package manager accounts to AUD-1, ENF-2 and SCA-4, and build-time compilers or tooling compromise to REB-1.
• Status caution: the specification's change record ends at v1.1 (19 October 2022) and the repository's latest commit was May 2025. It remains listed among the Supply Chain Integrity WG's activities. Use it as a stable practice model, and watch the SLSA Dependency Track for where per-artifact consumption evidence is heading.

OSPS Baseline: the upstream project's hygiene

The OSPS Baseline is a control catalogue for open source projects. The current release on baseline.openssf.org is v2026.08.28, and the site says only the version labelled current should be used for new compliance efforts. Controls sit in eight families (Access Control, Build and Release, Documentation, Governance, Legal, Quality, Security Assessment, Vulnerability Management) and three maturity levels: Level 1 for any project, Level 2 for code projects with at least two maintainers and a small number of consistent users, and Level 3 for code projects with a large number of consistent users.

• Typical controls: OSPS-AC-01.01 requires multi-factor authentication for users reading or modifying sensitive resources in the authoritative repository; OSPS-BR-01.01 requires CI/CD pipelines to sanitise and validate untrusted metadata before use.
• Mappings: the baseline repository publishes mappings to SSDF, SLSA, NIST CSF, NIST SP 800-161, the EU Cyber Resilience Act and others, which makes it a practical bridge between upstream projects and consumer requirements.
• Use as a consumer: ask critical upstream projects for their baseline assessment, or assess them yourself alongside automated signals. See the OpenSSF OSPS Baseline Guide and the OpenSSF Scorecard Guide.

Where they overlap and where they leave gaps

The S2C2F specification's own appendix maps its requirements to SSDF tasks, for example SCA-1 to RV.1.1, SCA-3 to PW.4.1, ENF-1 and ENF-2 to PO.5.2, REB-2 to PS.2.1 and REB-3 to PS.3.2, and AUD-1 to SLSA provenance distribution. Use those published mappings as the backbone of a crosswalk.

Choosing and combining frameworks

• You sell software to regulated or government buyers: start with SSDF as the programme and attestation basis, then use SLSA Build L2 or L3 provenance as concrete evidence for the release integrity tasks.
• You run a platform engineering team: target SLSA Build L3 on the shared CI platform and Source L3 on protected branches, so every product team inherits the level.
• You are mainly a consumer of open source (most enterprises): adopt S2C2F Levels 1 and 2 first, then Level 3 controls (malware scanning, deny lists, curated feeds) for your build systems. See the Malicious Package and Dependency Confusion Guide.
• You maintain or fund open source: work to OSPS Baseline Level 1 or 2 and publish the assessment; see the Open Source Project Maintainer Security Guide.
• Small organisations: pick one producer framework (SSDF) and one consumer framework (S2C2F Level 1 to 2). Use hosted CI that already emits SLSA provenance rather than building your own.
• Large organisations: run all four, owned by different teams, with a single control library mapped to each so one piece of evidence satisfies several frameworks.

Implementation roadmap

1. Baseline (month 1): record which of the four frameworks customers, regulators and internal policy actually require. Note the version each requirement names (SSDF v1.1 versus the v1.2 draft, SLSA v1.0 versus v1.2).
2. Consumer basics (months 1 to 3): route all package downloads through a repository manager (S2C2F ING-2), turn on vulnerability and licence scanning (SCA-1, SCA-2), and generate an automated inventory (INV-1).
3. Build provenance (months 2 to 6): enable SLSA Build L2 provenance on hosted CI, sign it, and verify it at deployment. Move to L3 for builders that produce customer-facing releases.
4. Programme alignment (months 3 to 9): map existing secure development controls to SSDF tasks, close gaps in PO and RV, and prepare attestation evidence.
5. Harden intake (months 6 to 12): lock package source configuration (ENF-1), add malware scanning and deny lists (SCA-4, ING-3), then enforce a curated feed (ENF-2).
6. Upstream assurance (ongoing): for the top dependencies by criticality, review OSPS Baseline status and Scorecard results, and fund or contribute where gaps matter.
7. Test and roll back: introduce each enforcement (for example provenance verification or feed blocking) in audit mode, measure what would fail, then enforce with a documented break-glass path.

Measuring progress

Framework mapping

Common failure patterns

• "We are SLSA L3, so we are secure": provenance proves how an artifact was built, not that its dependencies were safe or its code free of flaws.
• SSDF as paperwork: an attestation signed against SSDF with no artifact-level evidence behind it. Pair the practices with measurable outputs such as provenance and scan records.
• No consumer controls: producer frameworks adopted while developers still install packages directly from public registries, leaving dependency confusion and typosquatting open.
• Citing stale or draft versions: contracts that name "SSDF 1.2" or a SLSA draft track as if final. Name the exact version and status.
• Trusting git, not the release: reviewing source while consuming release tarballs or binaries built elsewhere. The XZ Utils backdoor was hidden in release tarballs and build macros rather than in the public git source, which is exactly the gap that verified provenance and rebuild-from-source controls (S2C2F REB-1) target.

Lessons from incidents

The SolarWinds supply chain compromise inserted SUNBURST into Orion builds without changing the source repository, and the tampered builds were signed and shipped as normal updates. Signing alone did not help, because the signer was the compromised build. SLSA Build L3 targets tampering during the build with hardened, isolated builders, while SSDF PS practices cover protecting code and release integrity. The XZ Utils case shows the consumer side: a contributor earned maintainer trust over about two years, so S2C2F proactive analysis (SCA-5) and OSPS governance and access controls matter alongside producer evidence. See the Top 10 Supply Chain Attacks for more cases.

Practitioner checklist

• List which framework and exact version each customer, regulator and policy requires.
• Assign an owner per framework: platform (SLSA), AppSec or engineering governance (SSDF), developer tooling (S2C2F), OSPO (OSPS Baseline).
• Build one control library mapped to all four, reusing the S2C2F and OSPS Baseline published mappings.
• Emit and verify SLSA Build L2 or higher provenance for every release artifact.
• Route all package consumption through a repository manager and lock package source configuration.
• Add malware scanning and a deny list for packages before they reach build systems.
• Track SSDF Rev. 1 and the SLSA Dependency Track drafts and plan updates when they finalise.
• Review OSPS Baseline or Scorecard results for your most critical dependencies each year.

Standards and references

• OpenSSF: SLSA Specification v1.2
• NIST: SP 800-218 Secure Software Development Framework Version 1.1
• NIST: SP 800-218 Rev. 1 (SSDF Version 1.2) Initial Public Draft
• OpenSSF: Secure Supply Chain Consumption Framework (S2C2F) Specification
• OpenSSF: Open Source Project Security (OSPS) Baseline
• OpenSSF: SLSA Working Draft Dependency Track
• OpenSSF TAC: Projects and Working Groups lifecycle status

Related NHI Mgmt Group resources: Software Supply Chain Security Guide · S2C2F Secure Supply Chain Consumption Framework Guide · SLSA and Build Provenance Guide · NIST Secure Software Development Framework (SSDF, SP 800-218) Guide · OWASP CI/CD Top 10 CICD-SEC-3 Dependency Chain Abuse Guide