What does the S2C2F govern that a producer-side framework like SLSA does not?
answer
- which direction of the chain?
- the intake side, not the output
- governs open source you pull in
- eight practice areas, four levels
- the producer half is SLSA's job
basics
~20 sThe S2C2F (Secure Supply Chain Consumption Framework) governs how open source enters your organisation: ingesting, inventorying, updating and auditing what you consume. SLSA governs the integrity of artifacts you produce. One is intake, the other output.
solid answer
~50 sThe S2C2F, the Secure Supply Chain Consumption Framework published through the OpenSSF, is a framework for consuming open source safely. Its scope is everything that happens before a third-party component reaches your build: how a package gets into the organisation, what record you keep of it, how it is updated, what gets blocked, and what you can show afterwards. It is organised as eight practice areas - Ingest, Scan, Inventory, Update, Enforce, Audit, Rebuild, and Fix + Upstream - with four maturity levels layered over them, so an organisation can say where it stands rather than pass or fail. SLSA answers a different question: the integrity of the build that produced an artifact you ship. You can be mature on S2C2F and still publish artifacts nobody can verify, or run a hardened build that faithfully compiles a compromised dependency. They are complementary halves.
go deeper
Be ready to say in one sentence that this framework is about consuming open source, and to name a few practice areas. Knowing that it is the intake half and SLSA is the output half is most of the answer.
Expect to explain what each practice area asks for and how the maturity levels escalate, and to say which practices your own team actually performs today versus which ones exist only as a document.
An interviewer expects you to place it against your real estate: which practices are already covered by existing controls, where the gaps are, and what adopting the next level would cost in engineering time rather than in licences.
Own the question of whether a consumption framework is the right instrument at all for your organisation, how it maps onto commitments you have already made elsewhere, and how you avoid running two overlapping programmes that produce the same evidence twice.
## What the framework is The **Secure Supply Chain Consumption Framework (S2C2F)** is a consumer-side framework for open source, published through the OpenSSF's supply chain integrity work. Its subject is the software you did not write and did not build: the packages, libraries and other third-party artifacts that enter your organisation and end up inside things you ship or run. It does not describe how to build your own software. It describes how to take someone else's in, and how to still be able to answer questions about it a year later. ## The eight practice areas - **Ingest** - every open-source artifact you consume comes in through, and is retained in, something you control, rather than being resolved fresh from a public index at build time. - **Scan** - look at what you have taken in: known vulnerabilities, licences, and malicious content. - **Inventory** - know what you consume and where it ended up, at a level of detail you can actually query. - **Update** - be able to move to a newer version quickly when you need to. - **Enforce** - have a policy about what may enter, applied by a control rather than by a wiki page. - **Audit** - be able to demonstrate afterwards that what was consumed is what policy allowed. - **Rebuild** - build the open source you depend on yourself, from source, on infrastructure you trust. - **Fix + Upstream** - when you find a defect, get it fixed in the upstream project rather than carrying a private patch forever. The first six are things most organisations attempt in some form. The last two are standing engineering commitments, and that is reflected in where the framework puts them. ## The four maturity levels Four levels are layered over the practices, and they escalate roughly like this: - **Level 1** - a minimum governance programme: use package managers rather than ad-hoc copies, know what you consume, scan it. - **Level 2** - reduce time to remediate: retain your own copy of what you ingest, verify the integrity of what arrives, and be able to push an update through quickly. - **Level 3** - defend against malicious packages and zero-days: enforce an ingestion policy with a control, look for malicious content rather than only for published advisories, review proactively. - **Level 4** - reduce future risk: rebuild dependencies from source on trusted infrastructure, and fix problems upstream. Two things about the levels matter more than their contents. They describe **capability**, not a tool purchase; and there is no external certification - an organisation scores itself, which is both what makes the framework cheap to adopt and what makes an unexamined score worth very little. ## Consumption versus production The sentence to have ready in an interview: **S2C2F is about what you take in; SLSA's build track is about what you put out.** A vulnerable or malicious dependency is a consumption problem. A tampered build is a production problem. The two frameworks address different threat models and neither substitutes for the other. It is entirely ordinary to have a disciplined ingestion pipeline and still publish artifacts with no provenance, and equally ordinary to run a hardened build that faithfully compiles a compromised dependency into a perfectly attested artifact. That second case is exactly why they are complementary: provenance tells a consumer **how** your artifact was built, not whether what went into it was sound. An SBOM tells them **what is inside**. Neither says the contents are safe. ## Where SSDF sits NIST's Secure Software Development Framework (SSDF, SP 800-218) is broader than both, and organised into four practice groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. The S2C2F is often used as the detailed, testable answer to the third-party-component parts of that broader framework - the places where SSDF says you should manage what you reuse without saying how. ## What it is not It is not a tool, and no product implements it. It is not a certification you can be awarded. It does not rate individual packages: a maturity level describes your organisation's capability, not a package's trustworthiness. And it makes no claim at all about the artifacts you publish - if a customer asks for evidence about your build, a consumption maturity level does not answer them.
- Can an organisation be mature on the S2C2F and still ship an artifact nobody can verify?Yes, easily. Consumption maturity says how carefully third-party code enters the organisation. It makes no statement about whether your own release build is hardened, whether it emits provenance, or whether anything is signed. Those are producer-side claims and need producer-side evidence.
- Which practice areas do most organisations already do without calling them that?Scan and Inventory, usually. Almost everyone runs a dependency scanner and keeps some list of components. The practices that are typically absent are Ingest as a controlled boundary, and Audit as something ever exercised - which is why maturity scores cluster low once you ask for evidence.
- Does the S2C2F protect against a compromised build system?No. A compromised build inserts something into an artifact you produced, which is outside this framework's scope entirely. That is what build-integrity work addresses. S2C2F would only help indirectly, by making it possible to say which third-party inputs the build consumed.
SLSA is the food-safety certificate for your own kitchen. S2C2F is the goods-inwards process at the loading dock: who may deliver, what gets logged, and what you can trace when a supplier issues a recall.
saying these in an interview costs you the question
- Says the S2C2F replaces or supersedes SLSA
- Thinks it certifies the packages you publish
- Describes it as a scanning product or tool
- Claims a maturity level is awarded by an external auditor
- Treats it as a rating of individual open-source packages