No. The SLSA v1.1 build requirements do not require reproducible builds at any level. They ask for provenance that exists, a hosted build platform, signed provenance, and at Build L3 isolated, ephemeral builds. Reproducibility is a separate and useful property, but it is not a SLSA gate.
Teams often assume the two travel together because both live in the "trustworthy builds" conversation. They solve related problems in different ways, and mixing them up can stall a project that could have shipped provenance months earlier.
What each Build level asks for
The table below summarizes the v1.1 requirements page. That page is now marked retired in favor of v1.2, so check the current text before you quote it in a contract.
| Level | Name on the page | Core ask |
|---|---|---|
| L1 | Provenance exists | Provenance identifies the output by cryptographic digest. Completeness is best effort. |
| L2 | Hosted | All build steps ran on a hosted platform, not an individual workstation. Signing is recommended. |
| L3 | Unforgeable and isolated | Provenance strongly resists forgery by tenants, signing secrets stay out of the build steps, and each build gets an ephemeral environment. |
None of these rows mention bit for bit identical output.
What reproducible means
The Reproducible Builds project defines a build as reproducible if, given the same source code, build environment and build instructions, any party can recreate bit by bit identical copies of all specified artifacts. That is a stronger statement about the output than anything in the SLSA level table.
The one place the two touch is cache behavior. The L3 text on isolation and cache poisoning says output must be the same whether or not a cache is used. That is a narrow consistency rule, not a reproducibility requirement.
Why people still pair them
Provenance tells a consumer what the platform says happened. Reproducibility lets a second party check it by rebuilding. The SLSA provenance page notes that others can rebuild the artifact if they want, which hints at the link, but it does not make rebuilding mandatory.
Put another way, provenance is a claim you can verify against expectations. A reproducible build is a claim you can verify by repeating the work. You can have the first without the second, and many teams start there.
A sensible order of work
- Build on a hosted platform so you are not producing releases from a laptop.
- Generate provenance for every release artifact and keep it with the artifact.
- Sign it and check the signer and builder identity in your deploy step.
- Move to ephemeral, isolated builds as your platform allows.
- Chase reproducibility for the components where independent rebuilds matter most, such as base images and firmware.
If your build embeds timestamps or absolute paths, reproducibility will take real effort. That should not delay steps one to three.
A note on wording
When you answer a customer, say which level you meet and which version of the spec you used. Do not write that you are "SLSA compliant" without naming the track and level. Safeguard offers SBOM generation, dependency scanning and policy gates that sit beside provenance in a pipeline, and the free scan at https://gold.safeguard.sh/scan can show you your current component inventory.
Quick check
Does Build L3 require hermetic builds?
Not in the v1.1 text. The page lists hermetic builds under future directions.
If my build is reproducible, do I meet a SLSA level?
Not automatically. Levels depend on provenance, platform and isolation properties, not on output identity.
Sources
- SLSA v1.1 build requirements (page marked retired, v1.2 is current)
- Reproducible Builds definition
Last reviewed: 19 October 2026.
