Skip to content

Provenance Attestation Check

Attestation audit — instantiates Transitive Trust Boundary Hardening

Verifies the signed record of how and where an artifact was built against an expected-provenance policy, so a genuine signature on a maliciously-built artifact still fails.

A signature says who signed the final bytes; it says nothing about how those bytes came to exist. Provenance Attestation Check closes that gap. It consumes a signed, machine-readable provenance attestation — a statement of the artifact's build inputs, the builder identity, the source it was drawn from, and the steps applied — and checks that story against an expected-provenance policy: the source repository, the builder, and the parameters the consumer requires. Its defining move is to verify the lineage of creation, not just the authenticity of the result — so an artifact that is validly signed but built from a forked repo, on an unexpected builder, or with tampered steps still fails, even though its signature is genuine.

Example

A container image is about to deploy to production. Its CI pipeline attached a provenance attestation in the in-toto format: built by the org's hardened builder, from git repository X at commit Y, with no manual intervention. The deploy gate checks the attestation against policy — expected builder? expected source? The image's own signature is valid, so a signature check alone would wave it through. But the provenance shows it was built from a developer's personal fork on a laptop, not the hardened CI builder the policy requires. The lineage is out of scope, so the gate blocks the deploy — catching a build-system detour that authentic bytes and a valid signature would have hidden.

How it works

Parse the signed provenance predicate, then compare its fields — builder identity, source URI and digest, build parameters — against a declared policy of what the trusted build path is allowed to have produced. Fail when the lineage does not match expectation, even when the artifact itself is authentic. The check is only meaningful once the attestation's own signature and issuer are verified first; it then judges the build story that signature vouches for.

Tuning parameters

  • Policy strictness — which fields must match and how exactly (pinned builder and repo versus loose patterns). Tighter scope catches more substitution but rejects legitimate variation.
  • Required assurance level — how complete and hermetic the build must be (e.g., a minimum SLSA level) before the attestation is accepted.
  • Trusted attestor set — which builders and issuers may produce provenance you will honor at all.
  • Missing-provenance stance — whether absent or incomplete provenance is a hard fail or a warning; fail-closed makes provenance mandatory rather than decorative.
  • Digest binding — whether the attestation must be bound to this exact artifact digest, defeating replay of a good attestation onto a swapped artifact.

When it helps, and when it misleads

Its strength is distinguishing authentic bytes from built the way we require — catching build-system compromise, source substitution, and unauthorized build paths that a signature check structurally cannot see. It is the mechanism that makes "signed" insufficient on its own.

Its failure mode is inherited honesty: provenance is only as truthful as the builder that generated it. A compromised build platform can emit truthful-looking provenance for a poisoned build — garbage in, attested garbage out.[1] A policy left loose enough to match almost anything gives the same false comfort. The classic misuse is accepting the mere presence of an attestation as a pass without reading its contents. The discipline: verify the attestation's own signature and issuer, keep the expected-provenance policy tight and reviewed, and pair it with an independent rebuild rather than trusting the builder's self-report alone.

How it implements the components

  • transformation_and_custody_record — the provenance attestation is the record of the artifact's build transformations and custody (inputs → builder → output); this mechanism reads and adjudicates it.
  • trust_scope_contract — the expected-provenance policy is a scope contract: the build path is trusted only to produce artifacts from source S via builder B, and anything outside that scope is refused.

It does not verify the artifact's final signature or trust anchors (origin_and_integrity_evidence, Artifact Signature Verification); it does not independently rebuild to confirm the bytes match (reproducibility_evidence_slot, Reproducible Build or Derivation Check); and it does not enumerate the dependency set (dependency_and_substitution_inventory, Dependency Lockfile and Allowlist).

Notes

Provenance verifies the builder's claim about creation; it is only as trustworthy as the platform that issued it. That is why it pairs naturally with builder hardening and with an independent reproducible-build check — the attestation says what the builder did, and reproducibility tests whether an independent build agrees.

References

[1] SLSA (Supply-chain Levels for Software Artifacts) frames provenance as graded assurance about how an artifact was produced — the attestation is trustworthy only to the degree the build platform issuing it is itself protected, which is why higher levels demand hardened, tamper-resistant builders. ↩