Your build already publishes an SBOM for every artifact. What does a build provenance attestation tell a consumer that the SBOM cannot, and what does verifying one actually check?

## Two documents, two questions Teams that have adopted SBOMs often assume provenance is the same idea with more ceremony. It is not. - **SBOM** — *what is in this thing.* A structured inventory of components with versions and identifiers, typically in CycloneDX or SPDX format. Its consumers are vulnerability response ("which of our artifacts contain this library?") and licence compliance. - **Provenance** — *where this thing came from.* A statement describing the build that produced the artifact: who built it, from what source, how. A useful way to hold them apart: the SBOM describes the *contents*, the provenance describes the *process*. An attacker who tampers with your build can produce a perfectly accurate SBOM of their tampered artifact. Provenance is what makes tampering visible, because forging it requires the builder's identity rather than just a text editor. ## What a provenance statement contains The common format is an in-toto attestation: a signed envelope wrapping a statement that binds a **subject** (the artifact, identified by digest) to a **predicate** (the claim being made about it), where the predicate type names the schema — for build provenance, the SLSA Provenance predicate. ```json { "_type": "https://in-toto.io/Statement/v1", "subject": [{ "name": "myapp", "digest": { "sha256": "9f2b0c…" } }], "predicateType": "https://slsa.dev/provenance/v1", "predicate": { "buildDefinition": { "buildType": "…", "externalParameters": { "repository": "…", "ref": "refs/heads/main" } }, "runDetails": { "builder": { "id": "…" } } } } ``` The two structural points that matter more than the field names: the statement is **bound to a digest**, so it cannot be transplanted onto a different artifact; and the **builder identity** is part of the claim, so "a valid signature" is meaningless until you say *whose* signature you require. ## What verification actually means A verifier that only checks "the signature parses and validates" has verified nothing useful — anyone can sign anything with their own key. Real verification is a policy evaluation: 1. **Locate** the attestation for the exact artifact digest you are about to deploy or run. 2. **Authenticate** it — the signature chains to an identity, and that identity is *the builder you expect*, not merely a valid one. 3. **Evaluate the claims** — does the recorded source repository match the repository you believe owns this artifact? Is the ref a release branch or tag rather than an arbitrary contributor branch? Is the build entry point the one you sanctioned? 4. **Fail closed** — an artifact with no attestation, a mismatched claim, or an unknown builder is rejected, not warned about. Step 4 is where most programmes quietly fail. Generating provenance is a checkbox a pipeline can tick in an afternoon; enforcing it at the point of deployment is an organisational commitment, because on day one it will block something legitimate. ## How the two documents work together They compose. The strong pattern is to attach the SBOM to the artifact **as an attestation too** — a signed statement whose subject is the same digest. That fixes an ignored weakness of standalone SBOMs: an unsigned SBOM sitting next to an artifact can be swapped, edited or simply be about a different build. Once it is attested, "this inventory belongs to this exact artifact and was produced by this builder" is verifiable. It also helps with a second common defect: an SBOM generated from the source manifest lists what the project *declares*, whereas one generated from the built artifact lists what actually shipped — system packages pulled in by the base image, vendored files, tools left in the final layer. When incident response asks "are we affected", the manifest-derived inventory can be confidently wrong. Generating from the finished artifact, at the point where its digest exists, and attesting both together is what makes the pair trustworthy. ## Honest limits Provenance is an *integrity* claim, not a *quality* claim. It tells you the artifact came from your pipeline and your repository. It does not tell you the code was reviewed, the dependencies were sane, or the build was not itself compromised through a poisoned input. Likewise an SBOM tells you a component is present, not that it is reachable or exploitable. Presented as guarantees, both invite the criticism that they are paperwork; presented as what they are — a verifiable answer to "what is in it" and "where did it come from" — they are the two facts you desperately want during an incident.