Most small teams should aim for S2C2F Level 1 first, then Level 2. Level 1 is a package cache, an inventory, scanning and updating. Level 2 adds safer ingestion configuration and faster patching. The framework calls Level 4 aspirational and says to apply it to critical dependencies only.
The four levels in plain words
The S2C2F specification organizes its requirements into four levels because all eight practices cannot reasonably be adopted at once. Here is how it describes each.
| Level | Theme | What it asks for |
|---|---|---|
| 1 | Common baseline | A package caching solution, an open source inventory, scanning and updating |
| 2 | Shift left and respond faster | Safer ingestion configuration, faster patching of vulnerabilities, incident response |
| 3 | Proactive analysis | Malware scanning before download, security analysis of the most used components, source in an internal location |
| 4 | Defend against the most sophisticated attackers | Rebuild open source on trusted build infrastructure |
The specification says Level 1 reflects the most common set of capabilities across the industry. Level 4, by contrast, has a high estimated cost relative to risk and reward, and should be a north star. It adds that implementing Level 4 on your most critical dependencies for your most critical projects is feasible even when doing it everywhere is not.
A sensible order for a small team
Step 1: Get Level 1 working. Put a cache or proxy between developers and public registries. Produce an inventory of what you use. Scan it. Set a routine for updating. If you cannot yet answer which services use a given package, stop here until you can.
Step 2: Move to Level 2. Review how your package sources are configured, since the specification highlights dependency confusion as a risk when mixing internal and external sources. Automate update pull requests so patching is routine. The specification points to a vulnerability that was exploited within three days of announcement as the reason to aim for patching in under 72 hours.
Step 3: Pick a few critical dependencies for Level 3. You do not need proactive source analysis of every package. Choose the handful your product cannot live without.
Step 4: Treat Level 4 as a later project. The framework describes rebuilding as having subtle technical challenges, such as naming a package so it does not collide with the upstream one and making sure everyone uses the internal copy.
How to assess yourself
The specification recommends assessing at organization level by interviewing a diverse sample of development teams about the tools and workflows they actually use. Expect a mix of levels. Teams that look mature on paper often have a side door that bypasses the cache.
What an OSPO should do with the result
Write the current level for each team, pick one target for the next quarter, and report progress. For a wider view of program maturity, see software supply chain maturity assessment.
Try it yourself
Click through it at your own pace, or open it full screen. It shows what a ready fix looks like, which is the habit Level 2 builds.
How Safeguard fits
Safeguard offers SBOM and dependency scanning, plus autonomous remediation with fix PRs. The fix PRs are off by default, with every category set to Manual until you change it. Try gold.safeguard.sh/scan for a first inventory.
Quick check
Can a small team skip Level 1?
Not sensibly. Levels 2 to 4 assume you know what you consume and where it is deployed.
Is Level 4 required?
The framework itself calls it aspirational. Apply it to a short list of critical dependencies if the risk justifies the cost.
Sources
Last reviewed: 19 October 2026.
