What provenance is — the attestation of where an artifact came from

Provenance is the verifiable, signed claim that an artifact was built from a specific source, by a specific builder, in a specific step. The artifact is identified by its digest; the source by its commit; the builder by its identity; the step by its entry point. The claim is signed by the builder, recorded against the artifact digest, and verifiable by any consumer that holds the builder’s trust anchor. Without provenance, a digest is opaque: the consumer can prove the artifact is unchanged but cannot prove where it came from.

What provenance is not

A provenance attestation is not a build log. A build log is a human-readable narrative of what the build script did; a provenance attestation is a structured, signed claim about the build’s inputs and outputs, written by the build platform for the verifier downstream. The build log is read at the keyboard; the provenance is read by the admission controller.

A provenance attestation is not a signature. A signature proves the artifact has not been modified since it was signed; it does not prove the artifact was built from the source the team expects. An attacker who can run a build can sign the artifact that build produced. Provenance binds the signature to the source the build read, so the consumer can reject artifacts built from a fork, a personal branch, or an uncommitted tarball.

A provenance attestation is not an SBOM. An SBOM inventories the artifact’s contents; provenance inventories the artifact’s creation. The same envelope carries both claims; both ride as OCI referrers; both are verified by the consumer.

The shape of a provenance claim

The SLSA build provenance is a JSON payload with three sections: buildDefinition (the build type and parameters), runDetails (the builder identity and invocation metadata), and metadata (the completeness and reproducibility flags). The buildType names the builder platform; the builder.id names the platform itself; the materials block enumerates the source commits the build read; the reproducible flag declares whether the build can be defended by the rerun-and-compare audit pattern.

flowchart LR
    A["Source (commit)"] --> B["Build platform"]
    B --> C["Artifact (digest)"]
    B --> D["Provenance"]
    D --> E["Signed envelope"]
    E --> F["Registry"]
    C --> F
    F --> G["Verifier"]
    G --> H["Admit"]
    G --> I["Deny"]

The verifier reads the digest, fetches the provenance referrer, verifies the signature, checks the source against the policy, and admits or denies.

Why provenance is load-bearing

Three properties make provenance load-bearing:

• Source integrity. The provenance names the source commit. The verifier rejects artifacts built from an unapproved branch or a fork.
• Builder integrity. The provenance names the builder. The verifier rejects artifacts built on a runner that is not the team’s hardened runner.
• Reproducibility claim. The provenance declares whether the build is reproducible. A non-reproducible build cannot be defended by the rerun-and-compare audit pattern.

How provenance travels

The provenance is attached to the artifact digest as an OCI referrer, the same shape as the SBOM in Part LXVIII-04. The attestation is stored in the registry next to the image; the signature on the attestation is verified by the consumer. The provenance is durable because the registry is durable; the provenance is verified because the signature is verifiable.

Production discipline

1. Generate provenance for every artifact at build time. A build without provenance cannot be defended in audit.
2. Attach the provenance as a signed OCI referrer. The attestation lives with the artifact; the signature proves the producer.
3. Verify the provenance at deploy time. The provenance is the policy input; the verifier is the policy enforcer.
4. Reject artifacts whose provenance does not match the expected source. An unexpected commit is an attestation that must not be admitted.

Cross-course references

• Git, CI/CD & GitOps — Part LXIX-03 (Keyless Signing with Fulcio) is the signing layer; LXX-01 is the layer above.
• Git, CI/CD & GitOps — Part LXVIII-04 (SBOM Distribution and Attestation) is the referrer shape LXX-01 reuses.
• Container Security for Production Sysadmins — Part VII (Admission Control) is the verifier side.

Quiz