A reproducible build lets any party recreate bit by bit identical copies of the specified artifacts from the same source, build environment and instructions. It does not make code safe, it is not a SLSA requirement and it is not automatic. Six myths below get short corrections.
Reproducibility is easy to oversell and easy to dismiss. Getting the facts straight helps you decide where it is worth the effort.
Myth 1: A reproducible build is a secure build
Fact. Reproducibility says the output can be recreated. If the source contains a flaw or a malicious dependency, a reproducible build reproduces it faithfully. The value is that a second party can check that the published binary matches the source, which makes tampering in the build step detectable.
Myth 2: SLSA requires reproducible builds
Fact. The SLSA v1.1 requirements page does not require reproducibility at any Build level. It asks for provenance, a hosted platform, signed provenance, isolation and ephemeral environments. The page also defers hermetic builds to future directions.
Myth 3: It is just about timestamps
Fact. Timestamps are a famous source of differences, which is why the SOURCE_DATE_EPOCH convention exists. It is a standard environment variable holding a timestamp for the last modification of the source, which build tools use in place of the current time. But the definition covers more. It names source code, build environment and build instructions, and lists dependencies, versions, configuration flags and environment variables such as locale. Any of them can change output.
Myth 4: You get it by pinning dependencies
Fact. Pinning is necessary, not sufficient. You also need stable file ordering, normalized metadata and a controlled toolchain. The Reproducible Builds project says it is preferable to reduce the set of environment attributes the build depends on.
Myth 5: One successful rebuild proves reproducibility
Fact. A single match on one machine is a good sign. The definition says any party. Try a different machine, a different path and a different user, and ideally a different time of day, before you claim it.
Myth 6: It only matters for open source
Fact. Anyone who wants independent confirmation of a build benefits, including firmware makers, vendors who ship to regulated customers and teams that want to know their CI did not alter output. How much it matters depends on who might want to check.
Where to start
| Step | Action |
|---|---|
| 1 | Build the same commit twice in the same environment and compare |
| 2 | Build on a second machine in a clean container and compare |
| 3 | Set the timestamp variable from the last commit time |
| 4 | Remove build paths and sort inputs where tools allow |
| 5 | Record the toolchain versions in provenance |
For git users, the project suggests deriving the timestamp from the last commit with a one line shell expression, export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct).
When to stop
Not every project needs full reproducibility. If nobody will ever rebuild your artifact independently, put the effort into pinning, hosted builds and verified provenance first. Revisit when a customer, auditor or regulator starts asking.
Safeguard offers SBOM generation and dependency scanning that work alongside reproducible build efforts, and the free scan at https://gold.safeguard.sh/scan can show what your build pulls in.
Quick check
Does a reproducible build prove the code has no vulnerabilities?
No. It proves the output can be recreated from the stated inputs.
Which environment variable is used for stable timestamps?
SOURCE_DATE_EPOCH, a standard variable holding the time of the last source modification.
Sources
- Reproducible Builds definition
- SOURCE_DATE_EPOCH
- SLSA v1.1 build requirements (page marked retired, v1.2 is current)
Last reviewed: 19 October 2026.
