Signing an artifact proves who built it. It does not prove what they built it from. A compromised build machine can produce a signed binary containing code that never existed in the repository, and every signature check passes because the signature is valid — it just attests to the wrong thing.
Reproducible builds close that gap. If anyone can take the source, rebuild, and get byte-identical output, then the binary is verifiably what the source says it is.
What changed in 2026
- Regulatory pressure increased. Supply chain security requirements in several sectors made build verifiability a procurement question.
- Toolchain support broadened. More compilers and packaging tools gained flags and defaults supporting deterministic output.
- Attestation frameworks matured. Standards for recording and verifying build provenance became practical to adopt alongside reproducibility.
- Independent rebuild services appeared. Third parties verifying that published artifacts match their sources became more common for widely used software.
Sources of non-determinism
| Cause |
Typical fix |
| Build timestamps embedded in output |
Set a fixed source date from the commit |
| Absolute build paths in artifacts |
Path remapping to relative or normalized paths |
| Filesystem iteration order |
Sort file lists explicitly |
| Locale-dependent sorting |
Set locale explicitly in the build environment |
| Random identifiers or seeds |
Seed deterministically or remove |
| Parallel build ordering |
Ensure assembly is order-independent |
| Compiler version differences |
Pin the exact toolchain |
| Dependency resolution drift |
Lockfiles with checksums |
| Archive metadata |
Normalize permissions, ownership, timestamps |
Timestamps are the single most common cause and the easiest to fix. Most tooling now respects a standard environment variable specifying a fixed build date, and setting it from the commit date gives a value that is stable for a given source state and still meaningful.
Path embedding is the second. Compilers record source paths in debug information, so building in different directories yields different binaries. Path remapping flags exist in major compilers for exactly this.
Verifying it
The test is not reading your configuration. It is building the same commit twice, in different environments, and comparing bytes.
Start locally: build twice in different directories on the same machine. That catches path and timestamp issues. Then build on a different machine, which catches toolchain and environment differences. Then have someone else build independently, which is the real verification.
Where artifacts differ, diffing tools that understand archive and binary formats will show you which embedded field differs, which is far more useful than knowing the hashes do not match.
Then publish enough for others to verify: the exact source revision, the toolchain versions, the build environment definition, and the expected artifact hash. Reproducibility nobody can check is a property you believe you have.
This composes with the inventory work in SBOM and supply chain security — an SBOM says what is in the artifact, reproducibility proves the artifact came from the source those components were declared in.
Common mistakes
- Assuming signing is enough. It attests to the builder, not the source.
- Never testing. Most projects have never rebuilt and compared.
- Fixing the hash without fixing the cause. Stripping a differing field can hide a real divergence.
- Ignoring the toolchain. Different compiler versions produce different output legitimately.
- Publishing no verification information. Nobody can check what you do not document.
FAQ
Do I need full byte-identical output?
For verification, yes — that is the property being tested. Partial determinism is still useful for caching, which is the argument in hermetic builds explained.
Is this achievable in every language?
Support varies. Some ecosystems have strong tooling for it; others embed non-determinism in ways that are harder to eliminate.
How much work is it?
For a project with pinned dependencies and a containerized build, often a handful of fixes. For a project with none of that, it is the larger project of getting those first.
Who actually verifies builds?
Distribution maintainers, security-conscious downstream consumers, and increasingly procurement processes. Publishing the information is what makes verification possible.
Where to go next
For the enabling property, read hermetic builds explained. For inventory and provenance, SBOM and supply chain security, and for dependency control, dependency pinning strategy.