Home / Knowledge hub / Build provenance
Knowledge hub
Build provenance
A signed record of where, when and how a piece of software was built.
What it means
Build provenance is a record, attached to a software artifact, that says how it was made. It names the source repository and commit, the build system, the build steps and inputs, and the output it produced, usually by a cryptographic hash.
To be trusted, the record is signed by the build system. A consumer can then check two things: that the artifact matches the record, and that the record came from a builder they trust.
Why it matters
If someone slips changes into a build, or swaps the output after it, the artifact no longer matches what the source should have produced. Without provenance there is nothing to compare against, and a tampered file looks like any other.
It also answers questions fast during an incident. If a source repository or a builder is found to be compromised, provenance tells you which artifacts came from it. That is much quicker than guessing, and it supports SLSA claims.
How it shows up
Build systems can generate it as part of the pipeline. The in-toto project defines an attestation format, and SLSA defines a provenance schema on top of it. It is stored beside the artifact, for example next to a container image in a registry.
The usual gaps are generating provenance but never checking it, letting the build job itself write the claims, and signing with a key anyone in the project can reach. Verify it at deploy time with an admission policy or a pipeline gate.
Questions people ask
Build provenance, answered
Is provenance the same as an SBOM?
No. An SBOM lists what is inside software. Provenance says how and where it was built. They complement each other.
Who signs provenance?
The build service, so that the developer who triggers a build cannot change the record afterwards.
Does provenance prove the code is safe?
No. It proves origin and process. A trusted builder can still build flawed code.
What is in-toto?
An open framework for attestations about steps in a software supply chain, whose format SLSA provenance uses.
Do customers ask for it?
Increasingly, large buyers and regulated sectors ask how you know your artifacts are what you built. Provenance gives a precise answer.
Sources
Where this comes from
Related
Terms that sit next to this one
SLSA
A framework of levels for how trustworthy a software build and its output are.
Image signing
Signing container images so a cluster only runs ones your pipeline produced.
Reproducible builds
Builds that produce identical output every time, so tampering shows up.
SBOM
A list of every component your application includes, with versions.
Software supply chain security
Protecting the code, tools and people that go into building your software.
What built the thing you ship?
Provenance covers the pipeline. We test what it produced, and report what we exploited. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.