ASD ISM 2155Reproducible Builds Enabling Independent Verification of Release Artefacts
Build software so that anyone with the stated source code can rebuild it and get byte-identical release artefacts, proving what shipped really came from that code.
Plain language
A reproducible build is one where the same source code, built the same way, always produces exactly the same output. That property lets someone who was not involved in the build (a customer, an auditor, a security team or an independent verifier) take the published source code, build it themselves and compare the result against the release artefact that was actually shipped. If the two match, they have strong evidence that the release really was produced from the stated source code and nothing else. This matters because a build pipeline is a tempting place for an attacker to interfere. Compromised build servers, tampered dependencies or a malicious insider can insert code into a release that never appears in the source repository, and source code review alone would never catch it. Without reproducibility, an organisation must simply trust that the build system did the right thing. With it, that trust can be checked independently, and any hidden difference between "what the source says" and "what was shipped" becomes visible. The control applies to how software is built. It requires the organisation to adopt build practices that make the output reproducible, and to make independent verification of release artefacts against the stated source possible, rather than leaving it as an unverifiable claim.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentTopic
Build solution
Official control statement
Software is built using reproducible build practices that enable independent verification that release artefacts were produced from the stated source code.
Why it matters
If builds are not reproducible, no one can independently confirm that a release artefact matches its stated source code. Code injected during the build (through a compromised build server, a tampered dependency or a malicious insider) can ship undetected, because source code review would show nothing wrong. Supply-chain compromises are harder to detect and investigate, and consumers of the software must rely purely on trust rather than evidence, which weakens assurance for both the organisation and everyone who depends on its releases.
Operational notes
Day to day, reproducibility is maintained by keeping the build deterministic and the inputs pinned. Build recipes, toolchain versions, dependencies and build environment definitions are recorded in version control alongside the source, and the build process avoids anything that varies between runs (embedded timestamps, absolute paths, random ordering, uncontrolled network fetches). Each release records exactly which source revision, toolchain and dependency set were used, and the resulting artefact hashes are published with the release.
Reproducibility is exercised regularly rather than assumed. A good way to confirm that independent verification genuinely works is to rebuild a release from the stated source on a separate, independent environment and compare hashes, treating any mismatch as a defect to be investigated so that the practices stay verifiable. Changes to the toolchain, build scripts or dependencies are reviewed for their effect on determinism, and the instructions needed for an outside party to reproduce the build are kept current and published with each release.
Implementation tips
- Development leads define and version-control the complete build recipe (build scripts, toolchain and compiler versions, pinned dependency versions with hashes, and a declarative build environment definition such as a container image or lockfile) so the exact inputs to any release can be reconstructed from the repository.
- Build engineers remove sources of non-determinism from the build by fixing embedded timestamps (for example by setting a source-date value derived from the commit), normalising file ordering and paths, disabling uncontrolled network fetches during the build, and configuring compilers and packagers for deterministic output.
- The release manager records, for every release, the exact source revision (commit hash or tag), the build recipe version and the cryptographic hashes of each release artefact, and publishes these alongside the artefact so verifiers know precisely what to reproduce.
- The build team periodically tests that independent verification actually works by rebuilding a release on a separate, clean environment (a different runner or verifier system, not the original build server) and comparing the resulting artefact hashes with the published ones, investigating and fixing any mismatch so the build practices remain reproducible.
- Technical writers or the platform team publish and maintain step-by-step reproduction instructions with each release so that customers, auditors or other outside parties can rebuild from the stated source and confirm the artefact hashes themselves.
Audit / evidence tips
- AskAsk for the build recipe and environment definition for a recent release, including how toolchain and dependency versions are pinned.Look atCheck that scripts, toolchain versions, dependency lockfiles with hashes and the build environment definition are all held in version control and tied to the release revision.GoodEvery input needed to rebuild the release is recorded and pinned, so the build can be reconstructed exactly rather than depending on whatever happened to be installed on the build server.
- AskAsk how the build has been made deterministic and what sources of variation were removed.Look atLook for evidence that timestamps, paths, file ordering, random values and network fetches during the build have been controlled, and that these decisions are documented.GoodThe organisation can explain and show each non-determinism source it has addressed, and successive builds of the same source produce identical outputs.
- AskAsk for the release record for a recent version showing the stated source revision and published artefact hashes.Look atConfirm the release links a specific commit or tag to each artefact and its cryptographic hash, and that this information is published where verifiers can find it.GoodAnyone can see exactly which source code a release claims to be built from and what the resulting artefacts should hash to.
- AskAsk for evidence that a release was independently rebuilt and compared against the shipped artefacts.Look atCheck that the rebuild ran on an environment separate from the original build system, that hashes were compared, and how any mismatch was handled.GoodThe organisation can show that an independent rebuild of a release from the stated source has been performed and produced matching hashes, and that any mismatch was investigated and resolved, demonstrating that the build practices genuinely enable independent verification.
- AskAsk for the reproduction instructions provided to outside parties for the current release.Look atTest whether the instructions are complete enough for someone without internal access to rebuild from the stated source and compare against the published hashes.GoodA third party can follow the published steps and obtain byte-identical artefacts, demonstrating that verification is genuinely independent and not reliant on the vendor's own build system.
Cross-framework mappings
How ISM-2155 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 8.25 | ISM-2155 requires reproducible builds to enable independent verification that release artefacts were produced from the stated source code | |
handshakeSupports(2)expand_less | ||
| Annex A 5.21 | ISM-2155 requires reproducible builds so that released binaries can be independently verified against the stated source code, reducing th... | |
| Annex A 5.22 | ISM-2155 requires reproducible build practices that provide verifiable evidence that release artefacts match the stated source code | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Software development
See all Guidelines for software development controls, or browse the full ASD ISM library.