ASD ISM 2155 Reproducible builds enabling independent verification of release artefacts
What it says
Software is built using reproducible build practices that enable independent verification that release artefacts were produced from the stated source code.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishBuild 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.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
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.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the build recipe and environment definition for a recent release, including how toolchain and dependency versions are pinned.
Look at
Check 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.
Good evidence
Every 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.
- Check 2 of 5What an auditor asks for
Ask for
Ask how the build has been made deterministic and what sources of variation were removed.
Look at
Look for evidence that timestamps, paths, file ordering, random values and network fetches during the build have been controlled, and that these decisions are documented.
Good evidence
The organisation can explain and show each non-determinism source it has addressed, and successive builds of the same source produce identical outputs.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the release record for a recent version showing the stated source revision and published artefact hashes.
Look at
Confirm 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.
Good evidence
Anyone can see exactly which source code a release claims to be built from and what the resulting artefacts should hash to.
- Check 4 of 5What an auditor asks for
Ask for
Ask for evidence that a release was independently rebuilt and compared against the shipped artefacts.
Look at
Check that the rebuild ran on an environment separate from the original build system, that hashes were compared, and how any mismatch was handled.
Good evidence
The 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.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the reproduction instructions provided to outside parties for the current release.
Look at
Test whether the instructions are complete enough for someone without internal access to rebuild from the stated source and compare against the published hashes.
Good evidence
A 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.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.25.
ISM-2155 requires reproducible builds to enable independent verification that release artefacts were produced from the stated source code. Annex A 8.25 requires an organisation to establish and apply rules for a secure development lifecycle, which commonly includes rules for build pipeline integrity, traceability and release governance. ISM-2155 is a specific secure-SDLC rule focused on deterministic, verifiable builds, whereas Annex A 8.25 extends to many other SDLC practices such as design reviews, dependency management and secure release procedures.
This control supports A.5.21.
ISM-2155 requires reproducible builds so that released binaries can be independently verified against the stated source code, reducing the risk of build-time tampering. Annex A 5.21 focuses on managing ICT supply chain security risks across products and services, and ISM-2155 supports this by providing a strong integrity assurance mechanism for supplier-delivered software and internally built components used in the supply chain. Annex A 5.21 is broader governance over suppliers and components, while ISM-2155 is a technical assurance practice focused on build provenance.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.