Verify Build Provenance Claims
Check a provenance statement against the artifact digest, trusted builder identity, source revision, and expected build path.
This check belongs at the release gate for software your team builds. Its question is whether the candidate artifact came from the approved builder, workflow, source revision, and build entry point. The SLSA provenance specification defines claims about a build and its subject artifact. A valid attestation is useful only after it passes your team's policy for that release.
Release gate policy
| Claim | Expected value | Gate result |
|---|---|---|
| Subject digest | Candidate artifact digest | Deny on mismatch |
| Builder identity | Approved build service | Deny unknown identity |
| Source | Reviewed repository and commit | Deny wrong revision |
| Build definition | Approved workflow path and revision | Deny unexpected job |
| Parameters | Approved release inputs | Review unexplained changes |
| Signature | Trusted issuer verification | Deny invalid proof |
Store the expected values in a protected release policy or approved change record, not inside the untrusted artifact. Verify the attestation signature with the issuer's supported verifier. Then compare its subject digest with the candidate file or image digest. Check the repository and exact commit against the reviewed change. A tag name is not enough because tags can move or point to a different build input.
Enforce the decision
Run this gate before production promotion. Capture the attestation digest, verifier version, policy revision, candidate digest, and each comparison result. A missing claim is not a pass. If the builder model cannot provide a required property, mark the property unknown and follow the exception process rather than silently weakening the gate. Compare build parameters only where the builder records them reliably.
Do not infer that a trusted builder produced safe code. Code review, tests, and dependency checks remain separate release controls. For an emergency release, record who approved the exception, which claim failed, the exposure window, and when the evidence will be repaired. Keep the failed artifact out of the normal promotion path. Keep the gate result with the approved release record so deployment reconciliation can compare running digests later.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.
Sources
- SLSA Provenance Specification v1.2Accessed
- OpenSSF Scorecard ChecksAccessed