The first era of software supply chain security was about knowing what you shipped. After Log4shell, the industry converged on the software bill of materials — a machine-readable inventory of every component in a product — and US executive orders made SBOMs a condition of selling software to the federal government.
The second era, now underway, is about proving how it was built. An SBOM tells you what's in the box; it says nothing about whether the box was tampered with on the way to you.
Why it matters
The most damaging recent supply chain attacks didn't smuggle in a bad dependency — they compromised the build itself: a poisoned CI pipeline, a backdoored release artifact, a maintainer account quietly taken over. Inventory doesn't catch those. Provenance does, because it binds the shipped binary to a specific source commit and a specific, auditable build process.
For vendors, this is becoming commercial reality: procurement questionnaires increasingly ask not just for an SBOM but for SLSA levels and signed attestations, and answering 'no' costs deals.
How it works
The stack has three layers. At the bottom, build systems generate provenance: a signed statement of what source, dependencies and steps produced an artifact, using the in-toto attestation format. Above that, SLSA — Supply-chain Levels for Software Artifacts — grades how trustworthy that provenance is, from Level 1 (documented process) to Level 3 (hardened, isolated build platforms that prevent tampering). At the top, signature systems like Sigstore let publishers sign artifacts and consumers verify them against a public transparency log, without managing keys by hand.
The practical effect: a consumer can verify that a release binary corresponds to a public source commit, was built by the project's official pipeline, and was not modified in transit — automatically, in CI, before deployment.
Evidence
GitHub, GitLab and the major cloud build services now generate SLSA provenance natively for hosted builds, which moved attestation from a specialist project to a configuration option. The OpenSSF publishes the SLSA specification and tracks adoption, and CISA's secure-by-design guidance explicitly pushes build provenance as a manufacturer responsibility. Major open-source ecosystems — npm, PyPI, Maven Central — have all added or piloted signing and provenance for published packages.
The competing read
Security teams that lived through SBOM adoption warn that attestation can become the same kind of checkbox: documents generated to satisfy procurement, never verified in practice. The counterargument is structural — attestations are machine-verifiable, so unlike a PDF inventory, they can be enforced by deployment pipelines rather than read by auditors. The honest position is that the tooling is ready and the verification habits are not, yet.
What happens next
Expect verification to move into the default path: Kubernetes admission controllers and artifact registries already support policy-as-code checks that reject unattested images, and the next procurement cycle will ask for enforcement, not just generation. The projects and vendors that treat provenance as a shipping artifact — versioned, signed, verifiable — will clear a bar their competitors can't fake.