ASD ISM 2056 Provide provenance for software builds
What it says
A software build provenance is produced and made available to consumers of software.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure that details about how software is created are available to its users.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
Generate and publish build provenance with each release (builder, source commit, dependencies, build steps, artefact hashes) so consumers can independently verify integrity and origin.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The software build documentation: Request a copy of the documentation that outlines how the software is created.
Look at
The structure and completeness of the document, ensuring it covers all steps and tools used.
Good evidence
Is a well-organised document that is clear and thorough, allowing someone non-technical to understand the process.
- Check 2 of 5What an auditor asks for
Ask for
To see the update history of the build documentation: Request evidence of when the documentation was last updated.
Look at
Recent dates and notes on changes made to reflect the current build process.
Good evidence
Shows regular updates, especially after major software changes.
- Check 3 of 5What an auditor asks for
Ask for
User communication records: Request copies of any communications sent to users informing them about the software build documentation.
Look at
The frequency and clarity of these communications.
Good evidence
Includes clear, regular reminders that documentation is available and where it can be accessed.
- Check 4 of 5What an auditor asks for
Ask for
Feedback or queries from users about the documentation: Request examples of feedback or queries from users regarding the software build process documentation.
Look at
The nature of the feedback and how the organisation addressed it.
Good evidence
Includes records showing responsiveness to user concerns and improvements made to the documentation as a result.
- Check 5 of 5What an auditor asks for
Ask for
To see training records for IT support staff: Request evidence of training sessions or resources provided to IT support staff on the software build process.
Look at
Attendance records or materials used in training.
Good evidence
Includes recent training events and materials that ensure support staff are knowledgeable about the build process and documentation.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets 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 created. Annex A 8.25 establishes and applies rules for a secure development lifecycle, within which generating and publishing build provenance is a common supply-chain assurance practice. Annex A 8.25 is broader (covers many SDLC activities such as design, testing, change control), while ISM-2056 focuses specifically on producing and distributing provenance artefacts.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.