Build provenance is verifiable metadata that records how a software artifact was produced: which source commit it came from, which build system built it, what commands ran, what dependencies were pulled in, and who or what triggered the process. Put simply, when security teams ask "what is build provenance," the answer is that it's a signed, tamper-evident paper trail attached to a binary, container image, or package that lets anyone — a downstream consumer, an auditor, or an automated policy engine — verify the artifact was built the way it claims to have been, from the source it claims to have come from, rather than trusting the claim on faith. Without it, a compromised build server or a malicious insider can swap in tampered code between "git commit" and "published artifact," and nothing in the artifact itself would reveal the difference. Provenance closes that gap by making the build process itself auditable.
What is build provenance, and why does it matter for software supply chains?
Build provenance is the record of an artifact's origin — source, build environment, dependencies, and process — captured at build time and cryptographically signed so it can't be altered afterward without detection. It matters because most supply chain attacks don't touch source code at all; they touch the build. The SolarWinds Orion incident is the canonical example: attackers inserted malicious code during the build step, after code review had already passed, so the compromised binary was signed and shipped as if nothing had happened. Source code review, static analysis, and even reproducible builds don't catch this class of attack on their own, because they inspect inputs or outputs, not the process connecting them. Build provenance gives you a verifiable link between the two, so a consumer can check that the binary they're about to deploy actually came from the build pipeline it claims to have come from, using the source it claims to have used, and wasn't quietly substituted somewhere in between.
How does SLSA provenance attestation formalize build provenance?
SLSA (Supply-chain Levels for Software Artifacts) formalizes build provenance through a standardized attestation format, so that provenance isn't just a homegrown log file that only your own team knows how to parse. An SLSA provenance attestation is a signed statement, typically encoded using the in-toto attestation framework, that bundles together the artifact's cryptographic hash, the source repository and commit it was built from, the identity of the build system that produced it, and the parameters and dependencies used during the build. SLSA also defines maturity levels (from SLSA 1 through SLSA 3, with a common industry read of "L1-L3") describing how trustworthy that attestation is — for example, whether it was generated by a scriptable, tamperable process or by an isolated, non-forgeable build service. A team publishing container images at SLSA Level 3, for instance, generates provenance in an ephemeral, hardened build environment where even the pipeline's own maintainers can't rewrite the attestation after the fact, which is a materially different trust guarantee than a provenance file a developer's laptop script produced.
What's inside a build provenance predicate?
A build provenance predicate is the structured, machine-readable body of the attestation that actually states the facts being claimed — everything else in the attestation (the statement wrapper, the signature) exists to protect and authenticate this payload. In the in-toto/SLSA schema, the predicate typically includes a builder.id identifying exactly which build service or workflow produced the artifact, an invocation section capturing the entry point and parameters used to trigger the build, a buildConfig or equivalent describing the steps executed, and materials listing every input — source repo, commit hash, base images, pulled dependencies — with their own content hashes. This is where software provenance metadata gets concrete: instead of a vague claim like "built from main branch," the predicate states the exact commit SHA, the exact builder identity, and the exact dependency versions, all hashed and tied together so that changing any single input invalidates the whole attestation. A verifier doesn't have to trust a README's description of the release process; it can machine-check the predicate against policy.
How does a provenance verification pipeline actually check attestations?
A provenance verification pipeline checks attestations by validating the signature, matching the artifact hash, and evaluating the predicate's contents against a policy before allowing deployment to proceed. Concretely, this usually happens as an admission-control step: when a container image or package is about to be pulled into a registry, deployed to a cluster, or promoted to production, the pipeline retrieves the attached SLSA provenance attestation, verifies it was signed by a trusted key or an identity backed by a transparency log such as Sigstore's Rekor, confirms the artifact's own hash matches what's recorded in the attestation, and then checks the predicate against rules like "must have been built by our approved CI system," "must not include dependencies from unapproved registries," or "must meet SLSA Level 2 or higher." Kubernetes admission controllers, artifact registries, and CI/CD gating tools increasingly implement exactly this pattern, rejecting any image that lacks a valid, policy-compliant provenance attestation rather than relying on a human to remember to check.
What's a real-world example of build provenance stopping an attack?
A real-world example is the difference between how the SolarWinds and the later Codecov bash uploader incidents were detected — both involved build-time tampering, but organizations with build provenance in place could have caught unauthorized build steps automatically instead of relying on after-the-fact forensic investigation. In the Codecov case, attackers modified a bash upload script hosted outside the normal build pipeline, and it was executed silently inside thousands of CI environments, exfiltrating secrets for months before anyone noticed. Had consuming pipelines required provenance attestation on that script — validating which repository, commit, and build process actually produced it — the swapped script would have failed verification the moment its hash and origin no longer matched a trusted attestation, rather than surfacing only after a customer noticed anomalous network traffic. This is the practical value of provenance: it converts "we trust this artifact because nothing looks wrong" into "we trust this artifact because we cryptographically verified where it came from."
How Safeguard Helps
Safeguard treats build provenance as a first-class control rather than an optional compliance checkbox. Our platform generates and signs SLSA provenance attestations directly inside your CI/CD pipelines, capturing the build provenance predicate — builder identity, source commit, dependency materials, and build parameters — automatically at build time, so engineering teams don't have to hand-roll attestation logic themselves. Safeguard then operates a provenance verification pipeline that sits at your deployment gates: every artifact is checked for a valid, unforged attestation and evaluated against policies you define, such as minimum SLSA level, approved builder identities, and disallowed dependency sources, before it's ever allowed to ship. Because Safeguard also maintains an inventory of software provenance metadata across every artifact in your environment, security teams get a single place to answer "where did this binary actually come from" during an incident, an audit, or a routine SOC 2 review — turning what used to be a manual archaeology exercise into a query that returns an answer in seconds. The result is a supply chain where trust in an artifact is something you can verify, not something you have to assume.