All articles

The bit-for-bit software factory your auditors will love

AGELAIOS

Engineering

Diagram of two parallel build chains starting from the same revision, converging on a bit-for-bit comparison and producing the audit artifacts.

The source code has been reviewed. The architecture has been documented. The security controls have been approved. One question still remains when the system reaches the field: can the deployed image be traced back to that exact source revision?

For conventional software, the answer often depends on records collected from a build server. AGELAIOS takes a more direct approach. Its image factory builds the same revision twice in separate environments, compares the resulting artifacts byte for byte and fails the pipeline if they differ.

This is not simply a quality metric. It creates a verifiable link between source code, system image and audit evidence. It also gives security teams, operators and auditors a shared basis for making release decisions.

The question every critical system must answer

Imagine an auditor examining a deployed node six months after its release. The source repository shows the approved revision. The update service identifies the published image. The device contains a binary with its own cryptographic digest. Documentation can assert that these elements correspond, but an assertion is not the same as a reproducible result.

The Reproducible Builds project provides the technical standard. Given the same source code, build environment and build instructions, another party must be able to create bit-for-bit identical copies of the specified artifacts [1].

Applied to AGELAIOS, the verification path is straightforward:

one approved revision → two complete builds → two artifact sets → one cryptographic comparison

The comparison covers the published system image, modules and their archives. If one byte changes, the digest changes and the pipeline stops. The compared double build is one of the nine CI pipelines described by the reference project.

This control is executed for each revision. A dependency that starts embedding a timestamp, an archive whose file order becomes unstable or a toolchain update that changes an output is therefore detected when the regression is introduced. The team can investigate the relevant commit instead of reconstructing the problem during an accreditation review months later.

Reproducibility is engineered, not declared

A build has more inputs than its source tree. Time, path names, account identifiers and even language settings can alter the final bytes without changing the software’s intended behavior. A reproducible factory must expose and control this ambient variability.

AGELAIOS addresses five common sources.

  1. Timestamps are normalized. Build tools often record the current time. SOURCE_DATE_EPOCH, the convention established by the Reproducible Builds project, provides a stable date derived from the revision [2].
  2. File order is made deterministic. Filesystems do not guarantee the order in which directories are traversed. File lists are sorted explicitly before archives are created.
  3. Build paths are controlled. Absolute working paths can leak into debug information, macros and generated files. The build maps them to fixed values.
  4. Locale and time zone are pinned. Sorting and string formatting can vary between machines. Both settings are fixed for the build.
  5. User and group identifiers are normalized. Archives can record the account that created each file. Fixed identifiers remove this machine-specific variation.

These measures turn hidden environmental variables into explicit build inputs. The list is deliberately treated as open ended because a new dependency can introduce a new source of variation. The double build remains the safety net. It makes an overlooked difference visible before the artifact is accepted.

One build, one image, one body of evidence

Reproducibility answers an essential question, but an auditor needs more than matching digests. They need to know what the image contains, how it was produced and which known risks were identified when it was released.

The AGELAIOS factory therefore produces the image and its supporting evidence in the same build:

  • an SBOM in SPDX format, standardized as ISO/IEC 5962:2021, that inventories the software components and covers the minimum elements defined by the NTIA [3] [7];
  • a CVE report generated by checking the SBOM against public vulnerability databases, with matches reported even when they are unfavorable;
  • a license report that inventories dependency licenses and checks their compatibility with the project’s Apache-2.0 license;
  • a signed provenance manifest recording the source revision, build environment and inputs, following the principles formalized by SLSA and in-toto [5] [6];
  • Rust binaries enriched by cargo-auditable, so their dependency information can be inspected directly from a deployed binary [4].

The provenance manifest accompanies the image in the TUF update repository. The evidence is therefore attached to a precise revision and refreshed whenever that revision changes. There is no separate build prepared for an audit and no manually curated evidence pack that can quietly drift away from the deployed system.

For an organization operating sensitive systems, this approach has practical value. Engineering teams spend less time reconstructing release history. Security teams receive current component and vulnerability data. Auditors can follow a documented chain from requirement to mechanism and from mechanism to generated evidence. The broader approach is explained in Continuous accreditation through evidence produced by every build.

What this proves, and what it does not

Bit-for-bit reproducibility is an established software supply chain practice, not an invention or a proprietary label. The Reproducible Builds project and contributors such as Debian have defined the conventions, developed tools including SOURCE_DATE_EPOCH and diffoscope, and demonstrated that the approach can operate at distribution scale [1] [2]. AGELAIOS applies these practices to its own controlled perimeter: an immutable system image, signed modules and their associated audit artifacts.

Matching outputs provide strong evidence that the declared inputs and build process produced the published artifact. They also reduce reliance on a single build result. They do not, by themselves, prove that the source code is free of vulnerabilities or that every component in the toolchain is trustworthy.

Three limits remain explicit:

  1. Independent rebuilders are still an open objective. The compared builds currently run within the project’s CI. Rebuilds performed by external organizations would provide stronger organizational independence.
  2. The toolchain bootstrap is outside the current perimeter. Compilers and build tools are pinned by version and digest, but reproducing those tools from their own source is a separate challenge.
  3. Coverage is focused on published artifacts. The image and module artifacts are compared today. Extending the guarantee to every secondary artifact remains work in progress.

These boundaries matter. They allow buyers and assurance teams to evaluate the control that exists today without confusing it with a broader claim that has not yet been demonstrated.

Trust the result because you can challenge it

The commercial value of a secure platform does not come from asking customers to accept stronger promises. It comes from giving them stronger means of verification.

AGELAIOS makes the reproducibility control inspectable and repeatable. A qualified team can clone the Apache-2.0 reference repository, select a revision, follow the build documentation and compare the resulting cryptographic digests. The repository also reports approximately 930 automated tests across nine published CI pipelines, including the compared double build.

For a program preparing an accreditation, evaluating software supply chain risk or operating a sovereign instance, this changes the conversation. The image is no longer presented as an opaque deliverable supported by static paperwork. It is delivered with a process that produces current evidence, exposes discrepancies and can be challenged by the customer.

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