To prove every dependency came through the approved path, audit consumption against your approved sources, then enforce the rule so builds fail on anything else. S2C2F treats these as two practices: Audit It shows where bypasses happen, and Enforce It stops them.
Audit and enforce are different jobs
The S2C2F specification defines the goal of Audit It as proving that every open source artifact in production has a full chain of custody from the original source and is consumed through the official supply chain. Its example threats are a well-meaning developer who bypasses the pipeline to update a package directly in a release, and an attacker with network access who bypasses the pipeline to deploy malware.
Enforce It goes further. The specification says all open source artifacts must be consumed from organization-defined approved sources and through the official consumption channels. Its example of enforcement is rerouting DNS traffic, or configuring builds to break if they try to consume open source from untrusted sources.
In short: audit tells you what happened, enforcement changes what can happen.
A staged approach
| Stage | What you do | What you learn |
|---|---|---|
| 1. Define | Name the approved sources and channels | What "approved" means |
| 2. Observe | Log where builds fetch packages from | How often builds go elsewhere |
| 3. Report | Share the list of bypasses with owners | Who needs help |
| 4. Warn | Show a build warning on unapproved sources | Which cases are legitimate |
| 5. Enforce | Fail the build on unapproved sources | A closed path |
Moving straight to stage five breaks builds and loses trust. The observation stages tell you which exceptions are real, such as a package that exists only in a particular registry, before you block anything.
What counts as evidence
An auditor or a customer asking for proof usually wants something they can inspect. Useful artifacts include:
- The list of approved sources and who approved it.
- Build logs or registry logs showing where packages were fetched from.
- A record of exceptions with an owner and an expiry date.
- Evidence that enforcement is active, such as a failing test build that tries an unapproved source.
See what evidence dependency intake should keep for auditors for a longer list.
Common bypasses to look for
The specification's list of ways developers consume open source is a good audit checklist: cloning a repository, wget or curl downloads, pasted source, binaries checked into a repository, direct pulls from a public package manager, repackaged archives, apt-get and git submodules. A central registry only works if nothing lets a developer pull straight from the public one. Check each route.
Who owns it
This is a good OSPO and platform team task. The OSPO defines the policy and reports on bypasses. The platform or build team configures enforcement. See stop developers bypassing the package mirror for the mechanics.
Try it yourself
Click through it at your own pace, or open it full screen. Note how a rule turns a policy into a pass or fail result.
How Safeguard fits
Safeguard offers policies, gates and guardrails, compliance and evidence automation, and SBOM and dependency scanning. It does not replace your registry or network controls. Try gold.safeguard.sh/scan.
Quick check
Can we enforce without auditing first?
You can, but you risk breaking legitimate builds. Observing first shows which exceptions are real.
What is the quickest audit signal?
Registry or proxy logs showing which hosts builds fetched from. Any host outside your approved list is a bypass to investigate.
Sources
Last reviewed: 19 October 2026.
