Provide Provenance for Software Builds
Ensure that details about how software is created are available to its users.
Plain language
This control is about making sure that everyone who uses your software knows exactly how it was created. It's like having a clear recipe for a dish-without it, people wouldn't trust what they're consuming. If you don't provide this information, users might think twice about using your software, and it could lead to misunderstandings or security issues.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
May 2025
Control Stack last updated
18 May 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
A software build provenance is produced and made available to consumers of software.
Why it matters
Without software build provenance, consumers cannot verify what produced the release, increasing supply-chain compromise risk via tampered dependencies or injected code.
Operational notes
Generate and publish build provenance with each release (builder, source commit, dependencies, build steps, artefact hashes) so consumers can independently verify integrity and origin.
Implementation tips
- System developers should document the software build process. Write down every step involved in creating the software, including tools and methods used. This guide should be easy to read and clear, so non-technical users understand it.
- IT managers should ensure documentation is up-to-date and accessible. Regularly review the build steps and update any changes to keep the document current. Store it in a location where users who need it can easily find and access it.
- Software vendors should communicate the availability of this documentation to their consumers. Include a mention of the build documentation in communications or user guides to ensure users know it's available and how they can access it.
- Security officers should review the build documentation for clarity and completeness. Ensure all major steps and tools are covered and that the document provides a comprehensive understanding of the software’s provenance.
- IT support teams should prepare to assist users with understanding this documentation. Be ready to answer questions or provide explanations to users who might have concerns or need further clarification on the software build process.
Audit / evidence tips
- AskThe software build documentation: Request a copy of the documentation that outlines how the software is created GoodIs a well-organised document that is clear and thorough, allowing someone non-technical to understand the process
- AskTo see the update history of the build documentation: Request evidence of when the documentation was last updated GoodShows regular updates, especially after major software changes
- AskUser communication records: Request copies of any communications sent to users informing them about the software build documentation GoodIncludes clear, regular reminders that documentation is available and where it can be accessed
- AskFeedback or queries from users about the documentation: Request examples of feedback or queries from users regarding the software build process documentation GoodIncludes records showing responsiveness to user concerns and improvements made to the documentation as a result
- AskTo see training records for IT support staff: Request evidence of training sessions or resources provided to IT support staff on the software build process GoodIncludes recent training events and materials that ensure support staff are knowledgeable about the build process and documentation
Cross-framework mappings
How ISM-2056 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| Annex A 8.25 | ISM-2056 requires that software build provenance is produced and made available to software consumers so they can verify how a build was ... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.