A build produces an attestation and uploads it beside an artifact. The release job downloads both and continues without examining the relationship between them. Evidence exists, but no release decision depends on it yet.
Define the required build evidence
For a hypothetical application release, the publisher needs to establish that the candidate corresponds to an expected source revision and an acceptable build process. Name the artifact by digest, identify the approved builder and specify the source repository and revision requirements.
SLSA describes provenance as verifiable information about where, when and how an artifact was produced. That information gives a verifier claims to evaluate. The organization still needs a policy describing which claims are acceptable for its release.
Source: SLSA v1.2 · Provenance.
Match the evidence to the artifact
The publisher must check that the provenance applies to the artifact it is actually about to use. A valid statement about another build is irrelevant to this candidate. It also needs a trustworthy basis for accepting the issuer and integrity of that statement.
Write the policy as explicit conditions. Which builder identities are allowed? Which repository is expected? Is a particular revision or reviewed reference required? Which build parameters affect the candidate? A policy that accepts any available attestation answers very little about the selected release.
Test a build that should be rejected
Create harmless test fixtures for a matching artifact, a mismatched digest, an unexpected builder and an unexpected source. Run them through the same verification decision used by the publisher. Confirm that rejected candidates cannot reach the publication step.
Keep rejection messages useful. An operator should be able to distinguish missing evidence, failed verification and a policy mismatch. Those conditions may need different repairs; none should silently turn into permission to skip verification.
- The artifact digest matches the subject of the accepted evidence.
- The evidence comes through the approved verification path.
- The builder and source claims meet the release policy.
- A failed decision stops publication and leaves an inspectable result.
Understand the limits of provenance
An artifact can come from the expected builder and still contain a defect. It can satisfy the source policy and still require security review. Provenance supports an origin and process decision; functional tests, dependency assessment and deployment checks answer other questions.
Put the accepted evidence identity into the release record alongside those other results. Then a later investigation can establish both why the candidate was trusted and what behavior was actually tested before it shipped.