Provenance Attestation
Provenance attestation cryptographically records how a build artefact was produced, enabling verification of supply-chain integrity.
Definition
Provenance attestation binds signed statements to a build artefact describing its origin: the source repository and commit, the build system and command, the inputs and dependency digests, and the timestamp. The statement is signed by the builder and stored alongside the artefact, so a consumer can verify that the binary came from the claimed source and process, not from a tampered pipeline. It is the evidence layer of supply-chain security, complementary to signing the artefact itself.
Context and scope
Required by software supply-chain frameworks such as SLSA for high assurance levels, and increasingly demanded by enterprises before consuming third-party builds.
Common misconceptions
- Attestation equals signing the artefact — an attestation is a signed statement about how it was built; signing only proves authenticity, not origin process
- Attestation guarantees the code is safe — it proves provenance, not correctness; a backdoored source built faithfully still passes
- It is a one-time setup — build steps and dependencies change, so attestations must be regenerated and verified continuously
Anti-patterns
- Publishing attestations that consumers never verify, making them decorative
- Generating provenance on a mutable build host whose state is not captured in the statement
- Trusting an attestation signed by an unverified identity, voiding the guarantee
Related concepts
Authoritative source
What it is
A provenance attestation is a machine-readable, signed document asserting facts about a build: which repository and revision were used, which builder ran it, what command and environment produced the output, and what inputs went in, expressed as cryptographic digests. The signature anchors those claims to a builder identity. A consumer that verifies the attestation learns the artefact real origin instead of trusting a filename or a badge.
Why it matters
Supply-chain attacks compromise the build rather than the source: a poisoned dependency, an injected step, or a stolen pipeline credential can produce a malicious binary that looks legitimate. Provenance makes the gap visible — a consumer can reject an artefact whose claimed source and inputs do not match its own policy. It is the foundation on which higher-assurance levels of frameworks such as SLSA are defined.
How to use it well
Generate provenance in the isolated build system that actually produces the artefact, sign it with a key or identity tied to that builder, and publish it next to the artefact. Record dependency and tool digests precisely enough to be verifiable, and enforce verification at the consuming side — an unverified attestation is worthless. Regenerate on every build and treat provenance generation and verification as continuously tested paths, not one-off configuration.