A SLSA verification summary attestation, or VSA, is a signed statement from a verifier saying it checked an artifact against a named policy and recording the result and the SLSA levels the artifact met. Consumers who trust that verifier can rely on the summary instead of re-checking every underlying attestation.
The problem a VSA solves
Build provenance is detailed. A single release can carry a provenance file, an SBOM attestation and test results, and each of those may reference dependencies with their own attestations. Asking every consumer to walk that whole tree is slow and error prone.
A VSA moves that work to one party. The verifier does the checking once, then publishes a short, signed result. The SLSA specification also notes a second benefit: a producer can show that verification happened without exposing the internal details of its build pipeline.
What a VSA contains
A VSA is an in-toto attestation, so it follows the usual Statement shape with a subject (the artifact digest) and a predicate. The SLSA spec gives the predicate type as https://slsa.dev/verification_summary/v1. Required predicate fields:
| Field | What it says |
|---|---|
| verifier | Who ran the check, with an id URI |
| resourceUri | Where the artifact is expected to be fetched from |
| policy | The policy applied, with a URI and ideally a digest |
| verificationResult | PASSED or FAILED |
| verifiedLevels | Highest SLSA level verified per track, such as SLSA_BUILD_LEVEL_3 |
Optional fields include timeVerified, inputAttestations (the attestations the verifier used) and dependencyLevels, which counts transitive dependencies at each level. If dependencyLevels is unset, the verifier is making no claim about dependencies at all.
How to consume one
The spec lists the checks a consumer should run on a VSA:
- Verify the signature on the envelope against roots of trust you chose.
- Confirm the subject digest matches the artifact in your hands.
- Confirm the predicate type is the expected string.
- Confirm the verifier identity matches the key that signed.
- Confirm the resource URI is the one you expect.
- Confirm the result is PASSED.
- Confirm the verified levels include the level you require.
A passing VSA from a verifier you do not trust tells you nothing. The spec is direct that a VSA does not protect against a compromised verifier, so decide which signer and verifier pairs you accept and write that list down.
When a VSA is worth the effort
| Situation | VSA useful? |
|---|---|
| One team consuming its own builds | Usually not, check provenance directly |
| Many consumers, one trusted internal verifier | Yes, one check replaces many |
| Supplier who cannot share build internals | Yes, it shows verification happened |
| Checking deep dependency trees | Yes, a VSA can record earlier results |
Where Safeguard fits
Safeguard's policy gates can block a pull request or release on findings from SBOM and dependency scanning, which covers the vulnerability questions a VSA does not answer.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through a gated pull request and watch how a single pass or fail decision stands in for many individual checks, which is the idea behind a VSA.
Quick check
Is a VSA the same as provenance?
No. Provenance describes how an artifact was built. A VSA records the outcome of a verifier checking that artifact, often including its provenance, against a policy.
Does a PASSED VSA mean the software is safe?
No. It means the artifact met the stated policy and SLSA levels. It does not say the code is free of vulnerabilities or malicious intent.
Sources
Last reviewed: 19 October 2026.
