By the middle of 2022, any team that went to a security conference came home with three framework acronyms dropped into their planning docs: SLSA, SSDF, and S2C2F. Each promised a defensible answer to the question "how do you know your software build pipeline is trustworthy?" Each answered it differently, with different assumed audiences, different maturity scales, and different opinions about what "trustworthy" means. Program leaders kept asking the same question: do we need all three, and if we can only do one, which one? The real answer depends on whether your primary driver is federal procurement, open source posture, or a large enterprise supplier network. This post walks through the three side by side and gives a decision framework for picking.
What is SLSA and who is it for?
SLSA (Supply-chain Levels for Software Artifacts) is a build-integrity framework maintained by the Open Source Security Foundation, aimed at teams producing software artifacts. It defines four maturity levels focused on build provenance: Level 1 is scripted builds with some provenance, Level 2 adds a hosted build service and signed provenance, Level 3 requires a hardened build platform that prevents tampering, and Level 4 demands two-party review and hermetic reproducible builds. SLSA's strength is that it is specific and testable — "provenance is signed by the build platform" is a checkable property. Its weakness is scope: it addresses build integrity only, not secure development, not runtime posture, not vendor management.
What is NIST SSDF and who is it for?
The Secure Software Development Framework (SP 800-218) is NIST's consolidated practice set for producing secure software, aimed primarily at software vendors selling into the US federal market. It is organized as four practice groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. SSDF is deliberately prescriptive about outcomes and deliberately loose about implementation — it tells you to "archive and protect each software release" without dictating the signing or storage mechanism. This is both its strength and its irritation. Strength: it maps cleanly to existing development practices. Irritation: adopting it gives you a long checklist without much implementation guidance.
SSDF became suddenly important in 2022 because OMB Memo M-22-18 tied federal software procurement to SSDF attestation. Any vendor selling software to a federal agency is going to attest to SSDF conformance. If your company sells into government, SSDF is not optional.
What is S2C2F and who is it for?
The Secure Supply Chain Consumption Framework, published by Microsoft and contributed to OpenSSF in 2022, is the only one of the three focused on the consumer of open source rather than the producer. It addresses the question: "you are pulling OSS dependencies into your product — how do you do that safely?" The framework is organized around a threat model of specific open source risks (upstream compromise, typosquatting, malicious maintainer change, dependency confusion) and maps each to practices that mitigate them. Maturity levels run 1–4, from ad-hoc consumption to continuously verified ingest.
S2C2F's value is that it maps one-to-one with real, named attack classes. SLSA and SSDF both talk about generic outcomes; S2C2F names the threats and the specific controls that address them. For a team trying to decide which OSS governance practices to invest in next, S2C2F reads like a tactical roadmap in a way neither of the others quite does.
Which framework addresses which threats?
The three frameworks are complementary more than competitive. Laid side by side:
- Producer-side build integrity (someone tampers with your build system): SLSA covers this directly. SSDF covers it loosely. S2C2F does not.
- Producer-side development practice (your team writes insecure code or ships secrets): SSDF covers this. SLSA does not. S2C2F does not.
- Consumer-side OSS ingest risk (a malicious package enters your build): S2C2F covers this directly. SLSA helps at the edges. SSDF does not.
- Cross-cutting incident response (a vulnerability is disclosed in your software): SSDF covers this. SLSA does not. S2C2F addresses the upstream variant.
A mature program uses elements of all three, because the attack surface they cover does not significantly overlap.
If we only have bandwidth for one in 2022, which one?
Pick based on what is making the most noise on your calendar:
- Federal procurement on the roadmap? SSDF. Non-negotiable. The M-22-18 attestation requirement is coming.
- Large enterprise customers demanding supply chain posture disclosures? Start with SSDF for the checklist coverage, then add SLSA once the build pipeline is modernized.
- OSS ingest is the primary risk and we're an OSS-heavy consumer? S2C2F. Its threat-first organization means you get measurable risk reduction fast.
- We ship our software as artifacts that customers verify? SLSA. The attestation model lines up with what customers will ask for.
The common trap is trying to do all three at once with a small team. In practice that produces superficial coverage of all three and mastery of none. Sequence them.
How do auditors treat each framework?
As of late 2022, only SSDF has anything approaching formal audit recognition — specifically, self-attestation under OMB M-22-18 is how it first reached operational status. SLSA has no formal audit regime; claims are self-declared and verifiable by inspecting the provenance artifacts. S2C2F has no audit regime at all; it is a maturity model used internally.
This matters for compliance planning because a customer who asks "are you SSDF-conformant?" is asking a question with a defined answer. A customer who asks "are you SLSA L3?" is asking a question whose answer is "we say we are and here is the provenance you can check." A customer who asks about S2C2F is usually a customer who has read one specific paper and is using it as shorthand for OSS governance depth — treat as a conversation starter, not an audit gate.
What changes in 2023 and beyond?
Expect three things. First, SSDF conformance will become table stakes across the federal supplier base and will leak into large enterprise RFPs by default. Second, SLSA's attestation format (in-toto) will become the standard substrate for build provenance across ecosystems, so even teams not pursuing SLSA levels will produce SLSA-compatible provenance. Third, S2C2F will converge with emerging consumer-side frameworks (the EU's Cyber Resilience Act consumer obligations, upcoming OpenSSF work on ingest policies) into a clearer consumer-side standard.
Teams that pick now will be better positioned than teams that wait for the consolidated version. The incremental work done against the current frameworks ports forward; the work of introducing any process at all has to happen at some point regardless of which framework carries the name.
How Safeguard Helps
Safeguard maps its controls to SLSA, SSDF, and S2C2F as first-class output. SBOM generation and provenance attestations are emitted in SLSA-compatible form; the policy engine can evaluate SSDF practice requirements against build events; the ingest module implements S2C2F consumption controls across npm, PyPI, Maven, and container registries. Griffin AI summarizes posture across all three frameworks into a single executive view, so a security leader can answer the same "are we conformant?" question for any of the three without running three separate assessments. For teams trying to satisfy overlapping framework demands without tripling their tooling footprint, Safeguard provides the unified control plane that makes conformance a byproduct of normal platform operation.