Check four things: the builder identity is one you trust, the signature on the provenance is valid, the build type matches what you expect, and the source repository and external parameters match your expectations. A valid signature alone only proves who signed, not that the build was the one you wanted.
What provenance is
Provenance is a signed record of how an artifact was built: where the source came from, which builder ran it and with what inputs. SLSA, the supply chain framework, describes how to verify it in its artifact verification specification. The steps below follow that document.
The verification steps
According to the SLSA specification, verification should include these steps:
- Ensure the builder identity is one in your map of trusted builder identities.
- Verify the signature on the provenance envelope.
- Ensure the buildType and externalParameters in the provenance match the expected values.
The specification adds that unrecognized external parameters should cause verification to fail, although an ecosystem may allow an approved list of parameters to be ignored.
Fields to compare and why
The specification lists fields to compare against expected values and the attack each comparison blocks:
| Field | What it prevents |
|---|---|
| Builder identity | Correct code built on an unintended platform |
| Canonical source repository | A build from an unofficial fork or disallowed source |
| buildType | Misreading of the build parameters |
| externalParameters | Injection of unofficial behavior into the build |
Each of these needs a stored expectation. That is the part teams skip: you cannot compare against nothing. Decide, per artifact, which repository and builder are legitimate, and keep that in version control.
Where to verify
The specification discusses architecture choices. One option is for a package ecosystem to check provenance at upload, which it recommends whenever possible because it benefits all clients. Consumers can also verify on their own. For your own deployments, the practical spot is admission or the release pipeline just before deploy, using the digest of the artifact being promoted.
A practical routine
- Write down the expectations for each service: builder, repository, build type, allowed parameters.
- Check provenance at release, and again at admission for anything coming from outside your pipeline.
- Start in warning mode, review mismatches, then enforce.
- Log every verification result, pass or fail, with the digest.
What provenance does not cover
Valid provenance from a trusted builder says the artifact came from the expected source through the expected process. It does not say the source is free of vulnerabilities or malicious changes. Treat it as one control alongside code review, dependency scanning and monitoring. Be wary of treating a provenance badge as a safety label.
Where Safeguard fits
Safeguard's policies, gates and guardrails and its SBOM and dependency scanning cover the part provenance does not: what is inside the software and whether it meets your rules. Run a free scan to see that view of a project.
Quick check
Is a valid signature on provenance enough?
No. You also need to confirm the builder, source repository, build type and parameters match what you expect.
What happens if provenance has an unknown external parameter?
The SLSA specification says unrecognized external parameters should cause verification to fail.
Sources
Last reviewed: 19 October 2026.
