The Secure Supply Chain Consumption Framework, or S2C2F, is a framework from the OpenSSF community on how developers consume open source dependencies. It has eight practices: ingest, scan, inventory, update, audit, enforce, rebuild, and fix plus upstream. It is a useful backbone for an OSPO's dependency governance.
What it is and who it is for
According to the project's README, S2C2F is developed within the OpenSSF Supply Chain Integrity Working Group. It has two parts: a solution-agnostic set of practices and a maturity-based implementation guide. It targets organizations that build software and depend on open source. The specification text says the practices are meant for CISOs and security, engineering and risk managers, while the implementation guide is for developers and security practitioners.
The framework's three goals, as stated in the specification, are a strong open source governance program, a shorter mean time to remediate known vulnerabilities, and preventing the use of compromised or malicious packages.
The eight practices
Each practice answers one sentence of confidence. The wording below is condensed from the specification.
| Practice | The confidence it gives |
|---|---|
| Ingest it | You can still ship if outside sources are compromised or unavailable |
| Scan it | You know whether any artifact in your pipeline has vulnerabilities or malware |
| Inventory it | You know where artifacts are deployed in production |
| Update it | You can deploy updated artifacts soon after a public update |
| Audit it | Every artifact in production has a chain of custody and came through the official path |
| Enforce it | Consumption only happens through approved sources and channels |
| Rebuild it | You can rebuild every deployed artifact from source |
| Fix it and upstream | You can privately patch and deploy quickly, and contribute the fix upstream |
The order is deliberate. Each practice builds on the last. You cannot inventory what you never ingested, and you cannot enforce what you cannot audit.
Control every way open source enters
The specification lists the many ways developers pull in open source: cloning a repository, using wget, pasting source, checking in a binary, going straight to a public package manager, using curl or apt-get, and git submodules. It argues that securing the supply chain is nearly impossible if teams do not follow one uniform process. A central internal registry only helps if nothing lets a developer bypass it.
That point is the heart of OSPO dependency governance. A policy that names an approved path, plus a way to detect use of any other path, is worth more than a long list of approved packages. For related reading on mirrors, see what is a package registry mirror.
How an OSPO can use it
Treat the eight practices as a checklist to assess where you stand. The specification describes a maturity assessment done at organization level, because different teams may be at different levels. Interview a sample of teams about their real workflows, not the documented ones.
Try it yourself
Click through it at your own pace, or open it full screen. This maps to practices two and three: scanning what you use and knowing where it lives.
How Safeguard fits
Safeguard covers parts of this list: SBOM and dependency scanning, policies and gates, and autonomous remediation with fix PRs, which is off by default. It does not replace a package registry. Try the free scan at gold.safeguard.sh/scan.
Quick check
Is S2C2F a certification?
No. It is a framework and implementation guide you can assess yourself against. There is no certificate attached to it in the sources we reviewed.
Do we need all eight practices?
No. The framework organizes them into four maturity levels so you can make incremental progress.
Sources
Last reviewed: 19 October 2026.
