Provenance and the build identity — SLSA, attestations, and the chain from source to bytes

Provenance is the signed attestation that records who built an artifact, from what source, with what tools, and under what identity. Without provenance, an artifact is a blob whose bytes happen to be reachable by a digest; with provenance, the artifact is a node in a verifiable chain from source to deployment. The build identity is the part of provenance that names the build pipeline, the commit, and the builder identity. Verifying provenance before deploying is the production discipline.

SLSA provenance basics

SLSA — Supply-chain Levels for Software Artifacts — defines four levels of provenance assurance. Level 1 requires the build to produce provenance as a side effect. Level 2 requires the build to be hosted, with provenance signed by the build platform. Level 3 requires the build to be hardened against runtime tampering. Level 4 requires two-party review and a reproducible build.

flowchart LR
    A["Source commit"] --> B["Build pipeline"]
    B --> C["Artifact digest"]
    B --> D["Provenance attestation"]
    D --> E["Signed by build platform"]
    C --> F["Deployment"]
    D --> F
    F --> G["Verifier checks signature"]

The provenance attestation is a document that names the artifact (by digest), the source (by commit), the builder (by identity), and the steps (by reference). The attestation is signed by the build platform’s identity; the signature is what makes the attestation verifiable.

The build identity and the chain

The build identity is the part of provenance that answers: who built this, from what source, under what credentials. The chain from source to bytes is the chain the auditor walks:

flowchart LR
    A["Commit sha"] --> B["Source repository"]
    B --> C["Build pipeline"]
    C --> D["Artifact digest"]
    D --> E["Provenance attestation"]
    E --> F["Builder identity"]
    F --> G["Verifier"]
    G --> H["Trusted or not"]

The chain is verifiable end-to-end only if every link is signed. The commit is signed (or signed-off) by the author. The build is signed by the pipeline identity. The attestation is signed by the build platform. The verifier checks each signature and confirms the chain is unbroken. A break at any link — an unsigned commit, an unsigned build, a missing attestation — is a break in provenance, not a break in the artifact.

Verifying provenance

A deployment that consumes an artifact should verify the artifact’s provenance before deploying. The verification is two checks: that the attestation exists for the artifact’s digest, and that the attestation’s signature is from a trusted builder identity.

cosign verify-attestation \
  --key https://builder.example.com/key.pub \
  --type slsaprovenance \
  registry.example.com/app@sha256:$DIGEST

The command reads the attestation from the registry, verifies the signature against the builder’s public key, and prints the attestation payload if verification succeeds. A deployment script chains this check before the deploy step: the artifact is not deployed unless the provenance verifies.

Provenance as the audit answer

Provenance answers the question the audit demands: what bytes ran in production, who built them, from what commit, under what identity, with what tools. The artifact’s digest names the bytes. The provenance attestation names the builder, the commit, and the source. The signature ties the attestation to a verifiable identity. The chain from bytes to source is auditable end-to-end.

Production discipline

1. Produce provenance for every artifact the build pipeline produces. The provenance is a side effect of the build, not an optional annotation.
2. Sign the provenance with the build platform’s identity. The developer’s key is insufficient; the build platform’s key is the trust anchor.
3. Verify provenance before deploying. cosign verify-attestation is the gate; the deployment fails if verification fails.

Cross-course references

• Git, CI/CD & GitOps — Part XLV-05 (Digest Pinning) establishes the digest reference this lesson verifies.
• Git, CI/CD & GitOps — Part XXXVII (CI Foundations) covers the trust model of build platforms.
• Linux for Production Sysadmins — Part XII (RepoSecurity) covers package signing, the OS-level analogue of provenance.

Quiz