Your organization is debating whether to require SLSA build-provenance attestations, cryptographically verified via sigstore/cosign, for every third-party dependency before it's allowed into any CI pipeline. What does verifying provenance actually protect against that an SBOM alone doesn't, and what's a legitimate reason to not make it mandatory everywhere immediately?

## Provenance against inventory Provenance, in the supply-chain security sense, is a verifiable record of exactly how a specific software artifact came to exist: which source repository and commit it was built from, which build system executed the build, what build steps ran, and ideally that the build environment itself was isolated and reproducible. This is a categorically different guarantee from an SBOM — they answer different questions. | Guarantee | The question it answers | |---|---| | **SBOM** | 'What components does this artifact claim to contain' — it's a static inventory, generated either from the artifact itself or from build metadata, and it's only as trustworthy as the process that generated it. | | **Provenance** | A harder one: 'is the artifact I'm about to install actually what it claims to be, built the way it claims to have been built, by a process I can verify wasn't tampered with.' | An SBOM can be entirely accurate and still describe an artifact that was swapped after the fact, built from unauthorized source, or produced by a compromised build pipeline that injected something the SBOM generator never saw. ## Grading and signing the claim The dominant framework for grading provenance maturity is **SLSA** (Supply-chain Levels for Software Artifacts, originally a Google-incubated framework now under the OpenSSF), which defines a set of increasingly strict levels: - simply documenting the build process - up through provenance being generated automatically by a trusted build platform - up to the highest levels requiring hermetic (no unexpected network access or inputs during build) and reproducible builds where independent parties can rebuild the artifact and confirm the result The mechanism that makes a provenance claim actually trustworthy rather than just another unverifiable metadata file is **cryptographic signing**: sigstore (an OpenSSF project, with `cosign` as its primary CLI tool) lets a build system sign a provenance statement (following the in-toto attestation format) using short-lived certificates bound to a verified identity — typically the CI system's OIDC identity (e.g., 'this was signed by GitHub Actions running workflow X in repo Y') — rather than requiring every publisher to generate and safeguard a long-lived private key, which was historically a major adoption barrier for artifact signing. A consumer can then verify, before installing a dependency, that its provenance statement is signed by an identity they trust and that the statement matches the artifact's hash exactly. ## What it actually defends against The value of this defends specifically against attacks that operate after or around the legitimate build process rather than within the source code itself: - **a compromised CI pipeline** that injects malicious steps without touching the source repository — the class of attack behind the 2020 SolarWinds compromise, where the build system itself, not the public source, was the injection point - **an artifact published to a registry that doesn't actually correspond to the source it claims to** — registry-side tampering, or a compromised publish credential pushing a different binary than what was reviewed - **a build that silently pulled in unexpected, unpinned inputs** during compilation None of these show up in code review of the source repository or in a plain SBOM, because both examine claimed contents or claimed source — provenance is what lets a consumer verify the chain of custody between source and published artifact. ## The coverage trade-off The realistic trade-off, and the reason a principal engineer might reasonably resist making this mandatory everywhere immediately, is **coverage**. As of the mid-2020s, only a minority of the open-source ecosystem publishes SLSA-level provenance or sigstore-verifiable attestations — major ecosystems and high-profile projects have adopted it (npm has integrated sigstore-based provenance for package publishing since 2023, and PyPI has piloted similar work), but the long tail of smaller, still widely-used packages generally hasn't. A hard organization-wide gate requiring verified provenance for every dependency, enforced immediately, would in practice block a large fraction of legitimate, low-risk dependencies that simply haven't adopted the tooling yet — not because they're unsafe, but because the ecosystem's adoption curve hasn't caught up to the standard. That creates real velocity cost and generates constant exception requests, which tends to erode the policy's credibility (teams route around a control that blocks their work too often) faster than it improves security. ## The phased, risk-weighted rollout The pragmatic response a principal engineer typically pushes toward is a phased, risk-weighted rollout rather than a blanket mandate: 1. **Require verified provenance first for the highest-privilege, highest-blast-radius dependencies** — build tools, CI actions themselves, packages with install-time script execution, anything touching credentials or the deploy pipeline. 2. **Allowing an exception path with compensating controls** (manual review, pinning by hash, SCA monitoring) for the long tail of lower-risk dependencies that don't yet support it. This also requires investing in verification infrastructure and defining what 'trusted identity' means for the org's own CI, which itself needs to publish trustworthy provenance for internally-built artifacts, not just consume it for third-party ones — a nontrivial, ongoing program rather than a one-time policy change, which is itself part of why immediate, universal enforcement is rarely the right first move.