Start with the control that removes the most ambiguity for the least effort: pin your inputs and build on a hosted platform. Add provenance next, verify it at deploy, tighten isolation after that, and pursue reproducible builds where independent rebuilds matter most.
Teams ask this because the vocabulary is crowded: pinning, signing, provenance, attestations, isolation, reproducibility. This guide orders them by effort and payoff.
The controls, in plain words
| Control | What it gives you | Typical effort |
|---|---|---|
| Pin inputs | Same inputs each time, by digest or lockfile | Low |
| Hosted platform | Releases not built on a workstation | Low to medium |
| Provenance | A record of how each artifact was built | Medium |
| Verify at deploy | Provenance actually checked | Medium |
| Ephemeral, isolated builds | One build cannot affect the next | Medium to high |
| Reproducible builds | Anyone can rebuild bit for bit identical output | High |
SLSA levels line up with several of these. Build L1 asks for provenance that identifies the output by digest, L2 asks for a hosted platform, and L3 adds unforgeable provenance and ephemeral, isolated builds. Reproducibility is not a SLSA requirement.
Step by step order
- Pin. Use lockfiles and pin base images by digest. Without this, everything later rests on moving ground.
- Move release builds off laptops. Use a hosted platform so builds are repeatable and logged.
- Emit provenance. Use the platform's attestation feature rather than your own script.
- Verify before deploy. Check the builder, the source repository and the parameters, not just the signature. An unchecked attestation is only a file.
- Isolate. Use fresh environments per build and keep signing secrets away from build steps.
- Reproduce selectively. Pick components where a second party rebuilding would add real assurance, such as base images or firmware.
Choosing by situation
- Small team, one service. Steps one to four are plenty for now. Do not wait on reproducibility.
- Regulated customers asking questions. Prepare a short evidence pack: pinning policy, builder description, a sample provenance file and the verification command.
- Open source library with many consumers. Provenance on releases matters, and so does a reproducible build, since many parties may want to rebuild.
- Firmware or system images. Reproducibility is more valuable here, but expect real work around timestamps and filesystem metadata.
What to avoid
Do not buy or build for the last step before the first is done. A beautifully reproducible build that pulls an unpinned base image will not reproduce. Do not publish provenance nobody verifies, then describe it to buyers as a control. And do not describe yourself as meeting a SLSA level without naming the track, level and spec version.
Measure progress
Pick simple measures: percent of release artifacts with provenance, percent of deploys that verify it, and number of unpinned inputs in release builds. Review monthly.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a gate turns a policy into something that blocks a change, the same shift you want from provenance that is checked at deploy.
Safeguard provides SBOM and dependency scanning, policies and gates. The free scan is at https://gold.safeguard.sh/scan.
Quick check
Do I need all six controls?
No. Start at the top and stop where the remaining risk is acceptable for your customers and data.
Is provenance useful without verification?
Little. It becomes a control when something checks it before deploy.
Sources
- SLSA v1.1 build requirements (page marked retired, v1.2 is current)
- Reproducible Builds definition
Last reviewed: 19 October 2026.
