Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
A signed image can still be the wrong image for your release. Build provenance helps you examine where an artefact came from, but only when verification connects the statement to the exact bytes, a trusted builder and an acceptable source.
Imagine a fictional checkout pipeline that publishes an image under a familiar release tag. The signature check passes, yet the release owner cannot explain which repository revision produced the image. This guide turns that ambiguity into a verification workflow, with explicit acceptance criteria and evidence that another engineer can review later.
Build provenance answers a different question from scanning
An image scan examines identified packages, layers or files for the conditions a scanner knows how to detect. An SBOM describes components. A signature authenticates a signed statement under a verification scheme and trust policy. Provenance describes aspects of how an artefact was produced.
None of these records should be used as a substitute for the others. A trusted build can contain a vulnerable dependency. A clean scan can describe an image built from an unapproved repository. An authentic attestation can accurately describe a build your organisation does not allow into production.
Write your acceptance criteria as separate questions. Which artefact is being evaluated? Who is trusted to make the statement? Which source and build process are permitted? Which additional scan and release checks are required? This separation makes a failed verification understandable instead of reducing every outcome to “signature invalid”.
Bind build provenance to an immutable subject
Resolve the release candidate to a digest before evaluating its evidence. Tags are convenient references, but they can move. If the pipeline checks a tag and deployment later resolves the same tag to different bytes, the earlier evidence may no longer describe the release candidate.
In the checkout exercise, retain the requested tag, resolved digest and resolution time. Verify that the attestation’s subject matches the candidate artefact. A syntactically valid document stored next to an image is not sufficient: the relationship must be established by the verification process.
Now substitute a different test image while keeping the original provenance record. The verifier should reject the mismatch. Keep this negative example in the policy test suite; it demonstrates that the gate checks identity rather than merely checking whether an attestation exists in the registry.
Verify identity before trusting the statement
The SLSA verification model distinguishes checking provenance authenticity from evaluating its contents against expectations. Your policy therefore needs a configured root of trust and an expected builder identity, as well as checks on the provenance format and subject. Accepting arbitrary signed provenance would only move the trust problem into the signing process.
For checkout, document which build service is authorised to produce release candidates. Keep that expectation outside the artefact being verified. A field inside an untrusted statement cannot appoint itself as your trusted builder. Review the verifier’s result and the identity it accepted, not just whether a signature-shaped object was present.
Test an attestation from an unapproved test builder separately from a malformed attestation. Both may be rejected, but they should produce distinguishable reasons. Clear failure categories help the platform team route a configuration problem without asking an application developer to debug a cryptographic verification failure.
Match the source to the intended release
Once authenticity is established, compare the available provenance contents with your release expectations. Check the repository identity and revision, along with the relevant build parameters your policy actually understands. Do not assume that every build system emits the same fields or that every provenance statement captures every input.
Suppose the release request names a reviewed checkout commit but the provenance points to a different revision. Stop and resolve that disagreement. A valid signature does not explain why an unexpected source was built. Conversely, an absent optional field should not be described as a confirmed malicious build; it may mean the policy lacks enough evidence to permit the release.
Avoid normalising repository names so aggressively that distinct identities become equivalent. Document how your verifier treats URLs, organisation boundaries and expected repositories. The aim is a reproducible policy decision, not a collection of string comparisons that happen to accept the current pipeline.
Keep verification results separate and test the failures
Use a compact acceptance table before connecting the gate to a release workflow. Run these cases against non-production artefacts that your team controls. Store the expected decision and reason so future verifier changes cannot quietly weaken an important check.
| Test input | Expected policy treatment |
|---|---|
| Approved builder, matching digest and expected source | Continue to the remaining release checks |
| Valid statement for another digest | Reject the subject mismatch |
| Matching digest from an unapproved builder | Reject the trust-policy mismatch |
| Unexpected source revision | Reject or hold according to explicit policy |
| Missing or unreadable evidence | Record an evaluation problem; do not invent a pass |
Keep the decision vocabulary small and precise. “Verified provenance” should describe the provenance checks that passed, not imply that the image is free of vulnerabilities. Scan results, exceptions and deployment requirements still need their own evaluation.
For a fail-closed release gate, an evaluation error must not silently become permission to deploy. Also define the recovery procedure: who repairs missing evidence, how the candidate is re-evaluated, and how an exceptional decision is recorded if your organisation permits one.
Carry the verified identity into deployment and review
After admission, confirm which digest the workload actually uses. This links the release decision to the running environment instead of ending the investigation at the registry. A later deployment of another image needs its own relevant evidence; the earlier approval belongs to the earlier candidate.
Retain the subject digest, accepted identity, policy version, verification outcome and references needed to locate the evidence. Treat sensitive build parameters and credentials according to your data-handling rules rather than copying entire execution logs into an unrestricted report. The resulting record should let an authorised reviewer reconstruct the decision without exposing unrelated secrets.
Key takeaways
- Bind provenance to the exact image digest being evaluated and deployed.
- Verify the statement against an independently configured trust policy before trusting its contents.
- Test subject, builder and source mismatches as separate failure cases.
- Keep provenance verification distinct from vulnerability scanning and final release approval.
How SecurityVault approaches this
SecurityVault’s container security workflow connects image findings, signatures, provenance and workload relationships through artefact identity. This lets an investigator ask which image was checked, what evidence supported the release and where that digest subsequently ran. The relationship is useful because the records remain attributable to a specific artefact, not because a signed document makes the application safe by itself.
Deployment policy evaluates the relevant evidence and retains a reasoned outcome. Human review remains necessary when interpreting missing context, accepting an exception or deciding how to remediate a finding. A provenance result and a package vulnerability are different inputs to that decision and should remain distinguishable in the investigation.
During an evaluation, use your own test builder and registry to demonstrate a matching candidate, a mismatched digest and an unapproved source. Ask how each result appears in the retained record and who can inspect it. Start with the policy-authoring documentation to discuss the checks and evidence your release process requires.