Reproducible Build

A build is hermetic when it is fully self-contained and has zero reliance on external, uncontrolled network resources. This is a prerequisite for reproducibility.

Key practices include:

• Dependency pinning: Locking all dependencies to exact cryptographic hashes, not version ranges.
• Vendoring: Storing all required source code and libraries within the project repository.
• Air-gapped execution: Running the build process in an isolated container or sandbox with no network access.
• Fixed toolchain: Specifying the exact version of the compiler, linker, and build tools, often distributed as a self-contained toolchain archive.

This prevents 'works on my machine' problems and blocks dependency confusion attacks.

The ultimate proof of integrity is a cryptographic hash comparison. Independent parties rebuild the software from source and compare their output's hash against the officially distributed binary.

The verification workflow:

1. Acquire source: Obtain the exact source code revision from a trusted repository.
2. Recreate environment: Instantiate the declared hermetic build environment.
3. Execute build: Run the deterministic build command.
4. Compute hash: Generate a SHA-256 hash of the resulting artifact.
5. Compare: Verify the hash matches the publisher's signed hash, often stored in a transparency log like Rekor.

A matching hash proves no tampering occurred during the publisher's compilation or distribution.

Several tools and frameworks are designed to enforce reproducible builds:

• Debian Reproducible Builds: A pioneering project that has made over 95% of Debian packages reproducible.
• Reprotest: A tool to test software for reproducibility by varying build parameters.
• Bazel & Pants: Build systems with hermeticity and determinism as first-class design principles.
• Nix & Guix: Purely functional package managers where builds are defined as mathematical functions, guaranteeing identical results.
• Docker Multi-stage builds: When combined with --platform and pinned base image digests, can produce reproducible container images.

These tools integrate with SLSA and in-toto attestation frameworks to create a verifiable chain of custody.

Reproducible builds are a foundational control in modern supply chain security, directly addressing threats like the SolarWinds and xz utils backdoor attacks.

Key benefits:

• Detects compiler backdoors: A seminal attack by Ken Thompson showed a compromised compiler could inject vulnerabilities invisible in source code. Reproducible builds using a trusted second compiler can detect this.
• Enables multi-party verification: No need to trust a single publisher; any independent party can validate the binary.
• Meets SLSA Build L3: Reproducible builds are a key requirement for achieving SLSA Level 3, which demands auditable, non-falsifiable build provenance.
• Supports VEX statements: Confidently declaring the exploitability of a vulnerability requires knowing the exact binary composition, which reproducibility guarantees.

Reproducibility is meaningless if the source code itself is not immutably preserved. The build must be tied to a specific, verifiable source tree.

Critical requirements:

• Cryptographic Git signing: Every commit and tag must be signed with a developer's verified key.
• Immutable revision references: The build process must reference a specific Git commit SHA, not a mutable branch name.
• Archival of build instructions: The exact build script, environment definition (e.g., Dockerfile), and dependency lockfile must be committed to the same source repository.
• Timestamp clamping: Using tools like SOURCE_DATE_EPOCH to force all internal timestamps to a single, declared value from the source commit, not the build machine's clock.