Reproducible Builds
What is Reproducible Builds?
Reproducible BuildsBuild practices that ensure compiling the same source code with the same instructions produces a bit-for-bit identical artifact, regardless of when or where it is built.
Reproducible builds eliminate non-determinism so that anyone with the source code and recipe can independently recreate the exact same binary and compare it byte-for-byte to a release. This requires controlling timestamps, build paths, environment variables, randomness, locale, file ordering, and compiler options. The Reproducible Builds project, Debian, NixOS, Arch Linux, Tor, F-Droid, and Bazel have invested heavily in this area. Combined with signed provenance, reproducible builds let independent rebuilders verify that a binary really came from the published source, helping detect compromise of single builders (as in SolarWinds). They are required to reach the highest SLSA build levels and underpin trust in critical open-source software.
● Examples
- 01
Independent rebuild of a Tor Browser release that matches the official binary byte-for-byte.
- 02
Bazel-based service producing the same SHA-256 digest from the same commit on any worker.
● Frequently asked questions
What is Reproducible Builds?
Build practices that ensure compiling the same source code with the same instructions produces a bit-for-bit identical artifact, regardless of when or where it is built. It belongs to the Application Security category of cybersecurity.
What does Reproducible Builds mean?
Build practices that ensure compiling the same source code with the same instructions produces a bit-for-bit identical artifact, regardless of when or where it is built.
How does Reproducible Builds work?
Reproducible builds eliminate non-determinism so that anyone with the source code and recipe can independently recreate the exact same binary and compare it byte-for-byte to a release. This requires controlling timestamps, build paths, environment variables, randomness, locale, file ordering, and compiler options. The Reproducible Builds project, Debian, NixOS, Arch Linux, Tor, F-Droid, and Bazel have invested heavily in this area. Combined with signed provenance, reproducible builds let independent rebuilders verify that a binary really came from the published source, helping detect compromise of single builders (as in SolarWinds). They are required to reach the highest SLSA build levels and underpin trust in critical open-source software.
How do you defend against Reproducible Builds?
Defences for Reproducible Builds typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for Reproducible Builds?
Common alternative names include: Deterministic builds, Bit-for-bit builds.
● Related terms
- appsec№ 1053
SLSA Framework
Supply-chain Levels for Software Artifacts: a tiered set of requirements published by OpenSSF that progressively hardens how software is built, signed, and verified against supply-chain tampering.
- appsec№ 1069
Software Supply Chain Security
The discipline of protecting every link of the software production chain - source, dependencies, build, signing, distribution, and deployment - against tampering, malicious code, and integrity loss.
- appsec№ 870
Provenance Attestation
A signed, machine-verifiable statement that describes how a software artifact was produced - including source, build system, parameters, and dependencies - so consumers can trust its origin.
- appsec№ 305
Dependency Pinning
The practice of declaring software dependencies at exact versions, often combined with cryptographic hashes, so that builds always consume the same artifacts and resist supply-chain tampering.
- appsec№ 166
CI/CD Security
The set of controls protecting continuous integration and continuous delivery pipelines from compromise, code injection, secret leakage, and unauthorized deployments.
- appsec№ 784
Package Signing
Applying a cryptographic signature to a software package so that consumers can verify the publisher's identity and that the artifact has not been altered after release.