Reproducible Build

A build is reproducible when the declared source code, build environment, and instructions allow another party to recreate every specified output byte. The Reproducible Builds definition makes both the input conditions and the output scope explicit.

The authors or distributors define which environment attributes, instructions, source, and outputs the claim covers. Reproducibility is therefore a property of specified outputs under stated conditions, not a promise that every file or log from a build will match.

Compare the specified outputs directly or through secure content hashes. Matching output establishes reproducibility for that comparison; it does not establish that the software is correct.

What makes two builds differ

Almost nothing on this list is in your source code, which is why the first attempt at a reproducible build is usually surprising. The project’s documentation catalogs the categories; grouped by where they come from, they are:

• Time. Embedded build timestamps, and archive metadata that records modification times. This is common enough to have a standard mitigation, the SOURCE_DATE_EPOCH convention.
• The machine’s settings. Timezone and locale — a locale can change sort order and therefore the order of anything sorted during the build.
• Paths. The absolute build path leaking into debug information or generated files, so building in a different directory produces a different binary.
• Order. Filesystem iteration order for inputs, and unstable ordering of outputs such as archive entries or hash-map traversal.
• Deliberate variation. Randomness, uninitialized values, and version strings derived from the build environment rather than the source.

Relevant environment attributes can include dependency versions, build flags, and environment variables such as locale. Reproducible Builds recommends reducing those inputs where possible. Fewer hidden dependencies make variance easier to understand.

The expected outputs commonly include executables, packages, and filesystem images. Logs are usually outside that specified set, so a timestamp in a log is not necessarily a reproducibility failure.

Three practices and their evidence

These practices answer different questions and can be adopted together. Their costs depend on the build system and threat model.

Practice	The question it answers	Cost
Recorded provenance	What does the build record say about its origin and inputs?	Depends on platform support and required verification
Deterministic inputs	Are the inputs I control the same on a rebuild?	Pin dependencies and version the build environment
Bit-for-bit reproducibility	Can another party reproduce the specified output bytes?	Control output variance; effort depends on the build system

SLSA Build L1 requires automatically generated provenance identifying the builder, build process, and top-level inputs. It is useful for investigating mistakes and understanding how a package was made, but offers no tamper protection.

The L1 record can be incomplete or unsigned. It does not certify the full transitive dependency inventory. A software bill of materials provides separate inventory evidence whose scope and accuracy also need verification.

Pin dependencies and version the build environment to control known inputs and make changes reviewable. This can be useful before investing in full reproducibility, but its adequacy depends on the risk and cost of an unexplained output difference.

Resist the step people take next, though: pinning inputs is not a demonstration that behavior is identical. A build that reads the clock, draws a random value, or fetches a response over the network can produce differing behavior from the same pinned dependencies and the same image — and differing bytes are how you would have noticed, which is the signal this level gives up. Pinning shrinks the set of uncontrolled inputs rather than enumerating it.

Treat a rebuild with unverified output as a new candidate. Matching output bytes can preserve the connection to earlier artifact checks, while the new invocation still needs the provenance and approvals required by the release policy. If bytes differ, investigate and validate the candidate rather than assuming a shared tag establishes equivalent behavior.

Independent rebuilding checks the correspondence between declared inputs and output bytes. It reduces dependence on the original builder, but the verifier still depends on the source, toolchain, environment, and comparison process. This is valuable when distributed binaries or an untrusted build service need independent checking.

Reproducibility and provenance are not a sequence

SLSA Build levels concern the trustworthiness of builds and their provenance, not an ordered path to reproducibility. L2 requires platform-generated, signed provenance; L3 adds stronger protections against interference and forgery.

At L3, build runs must not influence one another, and user-defined steps must not be able to access provenance signing secrets. Examine shared caches and workspaces as well as key access: a signature is useful only with a trustworthy signer and a record that consumers verify.

SLSA permits trustworthy provenance to be generated during an original build or through an after-the-fact reproducible build. Such a rebuild can create independent evidence that particular inputs produce the output. It cannot authenticate every claim in an earlier record: matching bytes do not prove who ran the original build, when it ran, or who approved it. Those claims need their own evidence and verification.

SLSA’s L0 use case includes development and test builds consumed on the same machine. L0 imposes no Build Track requirements; test-result integrity, runner isolation, credential protection, and interference with release jobs still need controls appropriate to their risks.

A last note on terminology, since the word travels badly. This is about build outputs, not about reproducing a bug — a minimal example that reproduces a defect is a different practice with a different purpose. And the reproducibility of a data or model pipeline, where the concerns are seeds, configuration, and checkpoints, is a related idea applied to a different kind of output.

Why any of this matters beyond tidiness is the subject of software supply chain security. The object whose reproducibility is at stake is a build artifact, moved between environments by environment promotion, and how much of this to adopt is worked through in You Tested a Different Binary.

References

• Reproducible Builds, Definitions
• SLSA v1.2, Build Track Basics
• SLSA v1.2 — Build: Provenance