Topics · Domain workflow

Supply chain and infrastructure

Verifiers match running digests to signed release receipts and, when present, confirm on-log recognition through inclusion proofs independent of the CI vendor dashboard.

Concrete scenario

What this looks like in practice

A critical service outage traces to a container image promoted through three CI systems. Security needs to prove the image digest running in production matches the signed attestation from release day — after two key rotations and a vendor migration.

Problem

What breaks today

Deployments, firmware, and build attestations rotate across vendors and keys. After an incident, teams need to prove what artifact was running, who signed it, and when it was witnessed — not what the latest wiki page claims.

Mechanism

How ZK-SNAP responds

Release and runtime events anchor operational claims in receipts at promotion and deploy time. Optional Chain recognition ties them to batch roots so later auditors can connect signed claims to governed witness material after key rotation or vendor migration.

Verifiable outcome

What a verifier can check

  • Build and image digests recomputed from artifacts match receipt commitments.
  • Issuer keys and rotation events are visible in provenance claims.
  • Anchor inclusion proofs connect release receipts to witness batches when claimed.
  • Gaps between promoted and running artifacts are explicit when receipts are missing.

Related profiles and labels

Evidence trailTransformation trailOn-log witness

Scope boundary

What a receipt does not replace

Attestation receipts strengthen supply-chain proof — not SBOM completeness, vendor security posture, or runtime integrity without instrumenting the environments that actually execute workloads.

Go deeper

Try the workflow, then read the spec.

Use Cases tells the story with cards. Proof Lab runs create and verify locally. Protocol holds the normative reference.