When you verify provenance you are trusting three things: the build platform that wrote and signed it, the roots of trust you used to check the signature, and the expectations you compare it against. If any one is wrong or stale, a passing check can still mislead.
The trust map
| You trust | Why it matters | What failure looks like |
|---|---|---|
| The build platform | It generates the provenance | A compromised builder writes false claims |
| Your roots of trust | They decide which keys count | A wrong or stale root accepts the wrong signer |
| Your expectations | They define what correct looks like | Edited expectations accept a bad build |
| The verifier tool | It performs the checks | A bug or compromise returns false passes |
The build platform
SLSA says provenance is only as trustworthy as the builder. The spec states that consumers do not accept provenance from a build platform unless they trust sufficient controls are in place. Build L2 has the platform generate and sign provenance. Build L3 adds isolation and keeps the signing secret away from user defined build steps, so a tenant cannot forge fields.
This is why the builder id matters. The verification steps tell you to look up the builder id and its level in your roots of trust. If no entry matches, the level defaults to Build L1.
Roots of trust
A signature is only meaningful against keys you decided to accept. Choose them deliberately and write them down. For keyless signing, that includes the Sigstore trust root and the specific certificate identity and issuer you expect. A signature from the wrong identity is valid cryptography and a failed trust check.
Expectations
Expectations are the facts you compare provenance to: canonical source repository, build type, allowed external parameters. The SLSA threat model lists tampering with recorded expectations as a threat and suggests authorization such as two party review for changes. Treat the expectation file like code: review it.
The verifier
A VSA lets one verifier record a result for many consumers, but the spec notes it does not protect against a compromised verifier. The same logic applies to your own tooling: pin versions, keep it updated, and limit who can change it.
Audit your own setup
- List the builders you accept and the evidence for their controls.
- List the identities and issuers allowed to sign.
- Store expectations in version control with review.
- Record which verifier version made each decision.
- Revisit the list each quarter or when a platform changes.
What stays outside. Dependencies, producer intent and availability are not covered by build provenance, according to the SLSA threat model, which says a future version might address dependency and availability threats.
Where Safeguard fits
Safeguard's policy gates and SBOM scanning give you rule based checks on what enters a build, and asset discovery helps you see which build systems exist at all.
Quick check
If provenance verifies, is the build trustworthy?
Only to the extent you trust the builder, your roots and your expectations. A pass means the claims match your rules, not that the rules are right.
What if the builder id is not in my list?
Under the SLSA verification steps, an unmatched builder defaults to Build L1, so treat it as low assurance.
Sources
- SLSA v1.2 Threats
- SLSA v1.2 Verifying artifacts
- SLSA v1.2 Build requirements
- SLSA v1.1 Verification Summary
Last reviewed: 19 October 2026.
