SLSA Provenance Verification in CI: Trust the Build, Not a Badge

Supply-chain provenance states how an artifact was built. Verification must connect the artifact digest to an expected builder, repository, revision, and policy. A badge or uploaded attestation is not sufficient if the deployment pipeline never validates it.

The practical problem

A deployment receives an image and in-toto provenance. The verifier confirms the image digest but accepts any workflow from the organization. A compromised test workflow could therefore produce a valid signature. The team narrows policy to the release workflow identity, protected repository, expected branch or signed tag, approved reusable workflow version, and disallowed build parameters. A negative test proves an artifact from an unapproved workflow is rejected.

This scenario defines the boundary for slsa provenance verification: the system of record, the component that enforces the decision, the asset or money at risk, and the condition that ends an exception. If one of those is unknown, discover it before changing production or presenting the number.

A step-by-step workflow

1. Scope the system. Define the deployment trust policy.
2. Establish the baseline. Pin verifier and trust roots.
3. Apply the control. Fetch provenance by immutable digest.
4. Test failure paths. Validate signature or transparency evidence.
5. Verify the result. Require the expected predicate and builder identity.
6. Record ownership. Compare source repository and commit with the approved release.
7. Close the loop. Inspect build parameters and materials for mutable or external inputs.
8. Review the change. Enforce branch, tag, and environment rules.
9. Complete the review. Fail closed with an emergency exception process.
10. Complete the review. Log the policy decision..

Prove the failure paths

Start with a healthy case based on “Define the deployment trust policy”, then repeat the exercise while deliberately violating the assumption behind “validate signature or transparency evidence”. Capture the observable result, the alert that should fire, and the person who decides whether to stop or continue. Next, simulate the most credible failure in this guide: checking only signature validity ignores who was authorized to sign. The test passes only when the team detects the condition, limits its impact, and restores service or the decision model without relying on undocumented knowledge. A final replay should cover resolving tags after verification can change meaning; this is the check most likely to reveal that a control works in a diagram but not at the actual boundary.

Evidence worth keeping

• Store artifact digest
• Attestation digest
• Builder identity
• Source revision
• Materials
• Policy version
• Verifier result
• Exception owner
• And deployment target. Periodically replay verification against retained releases.

Attach each record to the concrete object under review: the relevant asset, release, customer, contract, key, query, or configuration. Preserve timestamps and version identifiers so another reviewer can reconstruct the sequence. The evidence list above should answer three questions: what was true before the change, what changed, and what proves the intended outcome. For this topic, the most useful cross-check is “require the expected predicate and builder identity”. Keep sensitive fields out of screenshots and tickets; retain structured exports or signed records when they provide stronger provenance. Set retention according to incident, audit, privacy, and contractual needs rather than keeping everything indefinitely.

Common mistakes

• Checking only signature validity ignores who was authorized to sign.
• trusting organization-wide workflow identity is too broad.
• resolving tags after verification can change meaning.
• allowing unrecorded network downloads weakens reproducibility.
• manual exceptions without expiry become a second deployment path..

A focused operating checklist

• Name the owner of the system and the owner of the decision.
• Verify “pin verifier and trust roots” from the actual production or financial source.
• Exercise the failure described by “Checking only signature validity ignores who was authorized to sign”.
• Reconcile the observed result with the evidence list above.
• Put an expiry and rollback condition on every exception.
• Monitor the user, security, reliability, or cash outcome—not only activity.
• Revisit dependencies when the underlying product, contract, or standard changes.

Make this control sustainable

Assign the owner closest to the enforcement point described in “fetch provenance by immutable digest”, plus a backup who can execute the rollback. Review the control after a material release, supplier change, incident, financing event, or policy change that affects its assumptions. An alert is useful only when it names an action: inspect, throttle, revoke, reconcile, fail over, or escalate. Use the evidence measurements above to set thresholds from observed workload or financial behavior. Treat trusting organization-wide workflow identity is too broad as a specific review trigger. Close temporary exceptions with an owner, expiry, compensating control, and proof that the normal path was restored.

Primary references and further verification

Use the SLSA specification and in-toto attestation framework. Align rules with the actual CI identity claims issued by the build platform.

For a current slsa provenance verification decision, record the publication or effective date of the primary material and the version actually deployed or executed. Recheck vendor, standards-body, regulator, or accounting guidance when the product, protocol, vulnerability, or contract changes. Discovery summaries can point to an issue, but the decision record should link to the authoritative source and the organization’s own reproducible evidence.

Conclusion

The practical outcome is a control the team can explain and test: define the deployment trust policy, then log the policy decision.. Keep the assumptions and exception path visible. That is more useful than a generic checklist because the next reviewer can reproduce the decision, see where it can fail, and reverse it safely.