Bit-for-bit reproducible: why your auditor will like our image factory

An auditor examining a hardened system must be able to establish a simple fact: the deployed binary comes exactly from the source code that was reviewed. OC2-Edge provides a mechanical answer: the build is bit-for-bit reproducible. Two independent builds of the same revision produce identical artifacts, byte for byte, and continuous integration (CI) verifies it on every build. This article describes the principle, what must be pinned to get there, the audit artifacts produced as output and what the state of the art already does.

The principle: two independent builds, one identical artifact

The Reproducible Builds project defines a reproducible build as follows: given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts [1].

OC2-Edge applies this definition in CI as a compared double build. The pipeline runs two complete, independent builds of the same revision, in separate environments, then compares the cryptographic digests of the produced artifacts: the system image, the modules and their archives. A single diverging byte fails the pipeline. The public repository counts 9 CI pipelines; the compared double build is one of them.

This property changes the nature of trust. Without reproducibility, the binary is an act of faith: one has to believe that the build machine was not compromised at compilation time. With it, trust is distributed: a third party who rebuilds the same revision and obtains the same digest confirms the binary; a compromised build environment produces a detectable divergence instead of an invisible backdoor.

The double build is not a one-off verification. It runs on every revision, like the other pipelines. A reproducibility regression, for example a dependency that embeds a new source of variation or an updated tool that changes behavior, is detected at the commit that introduces it, not months later during an audit. Reproducibility is treated like a test: it breaks the build as soon as it stops being true.

What must be pinned

An ordinary build absorbs ambient entropy. Reproducibility requires identifying every source of variation and pinning it:

1. timestamps: most tools embed the build time in artifacts. The SOURCE_DATE_EPOCH variable, a convention established by the Reproducible Builds project, imposes a single date derived from the revision, identical from one build to the next [2];
2. file iteration orders: filesystems do not guarantee directory traversal order. Two machines can archive the same files in a different order. The build explicitly sorts every file list before archiving;
3. build paths: absolute paths of the working directory end up in binaries, through debug information and certain macros. The build normalizes these paths to fixed values;
4. locales and time zones: sort order and string formatting depend on the locale. The build pins the locale and the time zone to single values;
5. uid/gid: archives carry the identifiers of the account that created them. The build normalizes them to fixed values.

What these five work items have in common: each of these values is a hidden input of the build. Reproducibility consists of turning every hidden input into an explicit, pinned input.

This list is not closed. Every new dependency can introduce a previously unseen source of variation. The compared double build serves precisely as the safety net: a forgotten source shows up as a visible divergence in CI, never as a silently non-reproducible artifact.

The audit artifacts produced by every build

The build does not only produce an image. It produces, in the same pass, the file intended for the auditor:

• an SBOM (Software Bill of Materials, an inventory of software components) in the SPDX format, standardized as ISO/IEC 5962:2021 [3], covering the minimum elements defined by the NTIA [7];
• a CVE (Common Vulnerabilities and Exposures) report: the SBOM is matched against public vulnerability databases. The report is not filtered: matches are published as they are, including when they are unfavorable;
• a license report: the inventory of dependency licenses and their compatibility with the project’s Apache-2.0 license;
• a signed provenance manifest: the exact revision, the build environment and the inputs used, in the spirit of the SLSA [5] and in-toto [6] frameworks that formalize provenance in the software supply chain. The manifest accompanies the image in the TUF (The Update Framework) update repository;
• auditable Rust binaries: cargo-auditable embeds the list of dependencies in the binary itself [4]. An auditor queries the binary deployed in the field, without access to the CI or to the source repository.

The whole set is produced by the build, on every build, for every revision. There is no “prepared for audit” version distinct from the current version.

The link with accreditation

An accreditation file requires linking each security requirement to the mechanism that satisfies it and to the evidence that the mechanism works. In OC2-Edge, this requirement-mechanism-evidence matrix is generated by the build, not written after the fact: the SBOM, the CVE report, the license report and the provenance manifest are dated, signed and attached to a precise revision. When the image changes, the evidence changes with it, in the same CI pass. The complete approach is covered in a dedicated article of the series: continuous accreditation (article in French).

For the auditor, the consequence is concrete. They do not receive a frozen document describing a system that has already changed since it was written. They receive a process that regenerates the evidence on every build, and that they can replay themselves on the revision of their choice.

What the state of the art already does, and what we take from it

Bit-for-bit reproducibility is not an OC2-Edge invention. The Reproducible Builds project, carried notably by Debian, defined the notion, built the tooling, including SOURCE_DATE_EPOCH and diffoscope for comparing diverging artifacts, and demonstrated feasibility at the scale of an entire distribution [1] [2]. OC2-Edge adopts these conventions and applies them to a narrower, more constrained perimeter: an immutable system image, its signed modules and their audit artifacts.

What the project does today: the compared double build in CI, the audit artifacts generated on every build, the auditable binaries.

What remains open, and is marked as such:

1. rebuilding by genuinely independent third parties: the double build runs in the project’s own CI. External rebuilders, on the model of those in the Debian ecosystem, would provide stronger independence; open point;
2. the reproducibility of the compilation toolchain itself: the compiler and the build tools are pinned by version and by digest, but their own reproducible bootstrap is outside the current perimeter;
3. coverage: reproducibility is verified on the published artifacts of the image and the modules. Extending it to every secondary artifact is work in progress.

Verify the build

Verification does not require believing us. Clone the repository, build the same revision twice following the build documentation, compare the digests: equality is observed, not asserted. The public repository, under the Apache-2.0 license, counts ~930 automated tests passing, and the compared double build is one of the 9 published CI pipelines.

Sources

1. Reproducible Builds, “Definition”, accessed 2026, https://reproducible-builds.org/docs/definition/
2. Reproducible Builds, “SOURCE_DATE_EPOCH”, accessed 2026, https://reproducible-builds.org/docs/source-date-epoch/
3. SPDX, Linux Foundation, “The Software Package Data Exchange (SPDX) Specification”, ISO/IEC 5962:2021, https://spdx.dev/
4. rust-secure-code, “cargo-auditable”, accessed 2026, https://github.com/rust-secure-code/cargo-auditable
5. OpenSSF, “SLSA: Supply-chain Levels for Software Artifacts”, accessed 2026, https://slsa.dev/
6. in-toto, “A framework to secure the integrity of software supply chains”, accessed 2026, https://in-toto.io/
7. NTIA, “The Minimum Elements For a Software Bill of Materials (SBOM)”, 2021, https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom