You decide what provenance to expect by choosing how you form expectations. The SLSA verification page names three ways: trust on first use, expectations defined by the producer, and expectations defined in the source. Each trades convenience against assurance, and you can combine them.
A valid signature only says a document is intact. To know whether the document describes the right build, you compare it with something you already believe. That something is your expectation.
What an expectation contains
The verification page says expectations should cover at least the builder identity, the canonical source repository, the build type and the external parameters. It also notes that expectations attach to a package name, while provenance attaches to a specific artifact. Different versions of the same package usually have different provenance, so the expectation must stay stable across them.
A simple example from the page is a mapping from package names to their canonical source repositories.
Option 1: trust on first use
You record the first provenance you see for a package and expect later versions to match it.
- Easy to start, no coordination needed.
- Weak if the first release was already wrong.
- Useful for internal tooling where you control both sides.
Option 2: defined by the producer
The producer publishes what consumers should expect, such as the builder and the repository.
- Gives consumers a clear reference.
- The channel carrying the expectation needs its own protection, or an attacker edits both the artifact and the promise.
- Works well when you have a direct relationship with the supplier.
Option 3: defined in the source
Here the package identity itself implies the source. The page uses the Go ecosystem as the example, since a package name there is the source repository location. Expectations follow from the name.
- Little extra infrastructure.
- Needs an ecosystem where names and source locations are tied together.
Comparison
| Approach | Setup effort | Main risk | Good fit |
|---|---|---|---|
| Trust on first use | Low | Bad first observation | Internal packages |
| Producer defined | Medium | Unprotected channel | Direct suppliers |
| Defined in source | Low where supported | Ecosystem dependent | Name equals location ecosystems |
A practical blend
- For internal builds, write the expectation in a file in the consuming repository and review changes.
- For key suppliers, ask for their builder identity and source repository in writing, and record both.
- For everything else, fall back on trust on first use, then alert when the builder or repository changes.
Treat a change in builder or source as an event to review, not a routine update.
Where tooling fits
Verification tooling can enforce an expectation file, but someone must own the file. Name an owner per supplier. Safeguard's dependency scanning and policy gates can flag changes in what enters a build, and the free scan at https://gold.safeguard.sh/scan gives a starting inventory to build expectations from.
Quick check
Can I skip expectations if the signature is valid?
No. A valid signature on provenance for the wrong repository still verifies. The comparison is the control.
Why attach expectations to a package name?
Provenance is per artifact, but versions of one package should share builder and source, so the name is the stable key.
Sources
- SLSA v1.1 verifying artifacts (page marked retired, v1.2 is current)
Last reviewed: 19 October 2026.
