Verifying build evidence before deployment

Assumptions and constraint

Assume a team releases container images through several CI systems. Builds produce scan reports, but release owners cannot consistently connect the selected image to its source revision and build process. The organisation already has source-review rules; the proposed workflow needs to carry evidence into the release decision.

The constraint is evidence continuity. Adding another scanner would not resolve a broken link between a report and the image being deployed.

Decision: bind evidence to the released artifact

I would use the image digest to associate provenance, a software bill of materials (SBOM), and scan results with the artifact selected for promotion. The deployment would reference that same digest rather than a mutable image tag.

A digest identifies content; it does not establish who produced it or whether it should be trusted. Verification would check the provenance signature, match its subject to the artifact digest, and compare the builder, source repository, and build parameters with approved expectations. These checks follow SLSA's artifact-verification guidance. Source-review approval would remain a separate release-policy input.

Open the full-size verification diagram.

Alternative and trade-off

Checking evidence only when CI finishes would be simpler, but a later release could select a different image. I would place verification at promotion, where the intended artifact is known, while retaining earlier CI feedback so engineers can fix problems before release.

This adds operational dependencies: evidence retention, trusted-builder configuration, and the verifier all need owners. Missing evidence would block a new promotion under this design, without triggering removal of an already running workload. A verifier outage therefore needs a documented recovery path. Any exceptional release would require a recorded reason, an owner, and an expiry rather than a permanent bypass.

Failures should identify the artifact and rejected check, with a useful next action. An unexplained block would push teams toward workarounds.

Pilot and evaluation plan

I would start with one service and run checks in observation mode before enforcing them. The pilot would exercise an accepted release, a mismatched digest, an untrusted builder, missing evidence, and an expired exception. It would also test evidence-store unavailability and recovery.

Before rollout, measure how often release owners can trace an image to its build and how long investigation takes. During the pilot, record rejected promotions, incorrect rejections, verification latency, and exception age. Use those findings to agree on policy and support requirements before extending coverage. Producing more attestations alone would not demonstrate a better release process.