ASD ISM 2055 Ensure software components meet build standards
What it says
If a software build provenance is available for imported third-party software components, it is used during software development to ensure such software components are built to an appropriate standard.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUse available build history for third-party software to verify it meets standards during development.
When you bring in software made by someone else, it's essential to check that it was built following certain standards. This matters because if the software isn't up to scratch, it could contain hidden problems that might put your business at risk. Ensuring quality in the software can prevent potential security breaches or failures that can harm your business operations.
Free. Save your status, tasks and notes.
Why it matters
Not using available build provenance for imported third-party components can allow untrusted builds into products, increasing exploit risk and outages.
How to implement
Procurement team should request software build documentation: When purchasing third-party software, the procurement team should ask the vendor for detailed build history reports.
These reports should include when the software was built, what standards were followed, and any changes made during its development.
IT team should verify build standards: The IT team should compare the build history of the software against the organisation's own build standards.
They can do this by creating a checklist of required standards and ensuring each is present in the documentation provided.
Software developers should review build integrity: Software developers must examine the provenance of the software, ensuring that each part of the software meets expected security and performance criteria.
They can perform tests or simulations to verify this alignment.
Management should establish a review process: Management should set up a routine process for reviewing third-party software, involving both the IT and procurement teams.
This process should include regular meetings to discuss any differences or issues found in the build documentation.
Internal auditor should document findings: The internal auditor should maintain a record of all third-party software assessments, noting any issues found and actions taken.
They should also suggest improvements based on their findings to ensure ongoing compliance with build standards.
Keep it running
When third-party components are imported, obtain and verify their build provenance (e.g., signed attestations/SBOMs) and gate use on meeting defined build standards.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The software build history documentation: Request all relevant records from the procurement or IT team.
Look at
The build dates, version numbers, and any notes about changes or fixes.
Good evidence
Shows clear records with verifiable information about how the software was built.
- Check 2 of 5What an auditor asks for
Ask for
The result of verification against standards: Obtain reports from the IT team showing the comparison of the software build history to the organisation's standards.
Look at
How thoroughly every standard was checked.
Good evidence
Is a detailed report indicating each point of compliance or discrepancy.
- Check 3 of 5What an auditor asks for
Ask for
Meeting minutes discussing software reviews: Request notes from meetings where third-party software assessments were discussed.
Look at
Evidence of management involvement and decisions made based on the reviews.
Good evidence
Includes dated records showing involvement from relevant teams and actions agreed upon.
- Check 4 of 5What an auditor asks for
Ask for
Records of testing or simulations: Request evidence from the software developers regarding any simulations or tests conducted on the software.
Look at
Documentation that outlines test results and identified risks.
Good evidence
Is comprehensive documentation with clear results and any corrective actions taken.
- Check 5 of 5What an auditor asks for
Ask for
The internal audit record: Obtain records of internal audits related to software builds.
Look at
Documentation of issues found and recommendations made.
Good evidence
Features a detailed audit trail with clear follow-up actions or resolutions.
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-2055 requires that where build provenance exists for imported third-party software components, it is used during development to confirm those components were built to an appropriate standard. ISO/IEC 27001:2022 Annex A 8.25 requires an organisation to establish and apply secure development rules across the software/system development lifecycle, which can include third-party component assurance practices such as provenance verification. ISM-2055 is a specific supply-chain assurance practice within the broader secure SDLC governance expected by Annex A 8.25.
ASD Essentials for enterprise IT: 1 mapping
- IT.PRO-16.1Verify integrity, authenticity and provenance of software, components and updates before usePartially overlaps
This control partially overlaps IT.PRO-16.1.
IT.PRO-16.1 requires software integrity and authenticity to be assessed before use, verifying provenance where supplier evidence exists; ISM-2055 overlaps on provenance, using available build provenance for imported third-party components to ensure they are built to an appropriate standard.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.