Verification summary & policy

VSAs and requiring multiple claims before trust.

Expert25 min · lesson 6 of 15

Raw attestations — provenance, SBOMs, scan results — are evidence, but verifying all of them at every consumer is repetitive and error-prone. A Verification Summary Attestation (VSA) records that a trusted authority already checked an artifact against policy, so downstream consumers can trust the decision instead of re-deriving it, and policy becomes the thing you compose from many claims.

Requiring several claims before trust

Because every claim shares the in-toto shape, a policy can demand a combination before an artifact is trusted: built by our release pipeline (provenance) AND carrying a signed SBOM AND passing a scan with no unaddressed criticals. Each requirement is checked against the digest-bound, signed attestations attached to the artifact. This is where the earlier pieces converge — signing proves who, provenance proves how, the SBOM proves what — and policy is the expression that says which combination is sufficient for this environment (stricter for prod than for a sandbox).

policy composed from multiple attestations
# Conceptual verification policy for production admission:
require:
- type: slsaprovenance
builder_id: "https://github.com/acme/*/.github/workflows/release.yml@refs/heads/main"
min_slsa_level: 3
- type: cyclonedx # a signed SBOM must be present
- type: https://acme.dev/scan/v1
predicate.criticals_unaddressed: 0 # scan attestation must show none
# All three, bound to the SAME image digest, signed by trusted identities.

The VSA: verify once, trust downstream

When a central verifier evaluates that policy and the artifact passes, it emits a VSA — itself a signed attestation stating "this artifact was verified against policy X at level Y". Downstream systems (a deploy gate, another team, an air-gapped environment) can then trust the VSA rather than re-running every check and needing access to every underlying attestation. It is the supply-chain equivalent of a signed inspection certificate: the heavy verification happens once at a trusted point, and its result travels with the artifact as compact, checkable evidence.

From many claims to one trusted decision
1attestations
provenance + SBOM + scan, by digest
2policy evaluation
require the right combination
3VSA emitted
signed "verified vs policy X"
4downstream trusts VSA
no need to re-verify everything
Compose evidence into policy, verify once at a trusted authority, and let the VSA carry the decision. Verify heavy, trust light.
A VSA is only as trustworthy as the policy behind it
Downstream consumers trust a VSA without re-checking the underlying claims — so a weak or misconfigured verification policy silently propagates false assurance everywhere the VSA travels. Treat the verification policy as critical, reviewed infrastructure, and scope VSAs to the environment whose policy actually produced them.