Project: promote an image with verifiable supply-chain evidence

Last updated: 5 Oct 20269 min read

project

Use a disposable source registry, a separate destination registry, a protected build workflow, and a test cluster. Build a synthetic settlement worker for two architectures. Record the immutable image index digest and child-manifest digests before testing. The exercise is accepted only if the running image, final-image inventories, provenance, vulnerability disposition, and retained registry evidence can be joined to the approved release bytes without relying on a mutable tag.

Inventory the shipped artifact

Produce a lockfile inventory and final-image inventories for both architectures. Compare application packages, operating-system packages, copied binaries, dependency edges, and unknown components. Give each document a subject digest and generator record. Move a release tag after tests; the inventory job must still read the tested digest. Verify each SBOM remains retrievable after tag cleanup. Introduce a second platform variant with a changed base package and prove that the first variant's inventory does not silently stand in for both.

Triage and document one finding

Inject a synthetic vulnerable-component alert. Match it to ecosystem, package origin, distribution build, and the deployed digest. Create one affected disposition with remediation work and one not-affected disposition with a testable reason tied to an exact digest. Rebuild the image with a different module set and show that the old not-affected statement is not automatically inherited. Keep the reviewer, evidence, and revisit trigger in the release record. If component identity is unknown, leave it unresolved and assign investigation rather than forcing a false match.

Supply evidence acceptance
Image index and platform digests recorded before tests
Each runtime SBOM names its actual subject and unknowns
Advisory disposition names component and release digest
Not-affected claim has evidence and rebuild trigger
Provenance signer and builder are both approved
Admission verifies the exact subject the cluster pulls
Destination registry exposes image and required referrers
Rollback digest and evidence survive cleanup dry-run

Verify builder and admission

Generate provenance in the protected release workflow. Test a copied statement with an altered source field, a properly signed statement from an unapproved workflow, and a statement for another image digest. Admission should reject the wrong builder or subject even when the document parses. Turn the verifier into audit mode first, measure timing and false denials, then test enforced behavior against a canary Deployment. Simulate registry and verifier outages and record the chosen failure path. Compare the admitted reference with the runtime image ID after Pod start.

Promote and retain proof

Refresh the base image without changing application source, then rebuild, scan, and retest. Copy the selected image to the destination by digest and enumerate its attached evidence there; do not infer a copy from source-side discovery. Run a cleanup dry-run protecting current, canary, rollback, and incident-held digests with their required evidence. Delete an unused tag in the disposable registry and verify the retained subject remains pullable from a clean node. Report scan time, admission latency, missing referrers, stale dispositions, registry bytes, and rollback pull time. Mark provider- or registry-specific behavior unverified when the disposable environment cannot reproduce it.

Common Mistakes

Do not equate a valid SBOM file with an inventory of the deployed bytes.
Do not let a finding exception follow a mutable tag across rebuilds.
Do not clean up the only evidence needed to admit a rollback image.

Connected lessons

devops

project