Build provenance in practice

What it asserts and why the build must be hardened.

Provenance is the heart of supply-chain assurance: a verifiable statement of what source, builder, and process produced an exact artifact. If you can trust the provenance, you can answer the question that matters after an incident — "where did this running thing actually come from?".

What provenance asserts

A provenance attestation binds an artifact (by digest) to the facts of its creation: the exact source commit, the builder identity, the build parameters, and the pinned materials (dependencies, base images) that went in. Crucially, the subject is a cryptographic digest, not a name or tag — so the claim applies to precisely those bytes and cannot be transplanted onto a lookalike. Generated by the build platform and signed, provenance becomes the artifact’s tamper-evident birth certificate.

# Many hosted builders emit SLSA provenance automatically. With cosign you can
# attest it and attach it to the image so it travels with the artifact:
cosign attest --predicate provenance.json --type slsaprovenance \
  registry.acme.internal/api@sha256:9f2c...
 
# The attestation's subject is the image DIGEST — it applies to exactly these
# bytes. A verifier later checks it before allowing deploy.

Provenance is only as strong as the build

Provenance produced by an unhardened build is a claim the build could have forged; provenance produced by an isolated, SLSA-L3 platform is a fact. That is why provenance and build hardening are inseparable — the value of the record depends entirely on whether the thing generating it could lie. And provenance without verification changes nothing: it must be checked at a gate (release or admission) against a policy that says "the builder must be our release workflow, the source must be our repo". Producing evidence and enforcing it are two different steps, and you need both.