Ensure Software Components Meet Build Standards
Use available build history for third-party software to verify it meets standards during development.
Plain language
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.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
May 2025
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
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.
Why it matters
Not using available build provenance for imported third-party components can allow untrusted builds into products, increasing exploit risk and outages.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
-
Askthe software build history documentation: Request all relevant records from the procurement or IT team
Goodshows clear records with verifiable information about how the software was built
-
Askthe result of verification against standards: Obtain reports from the IT team showing the comparison of the software build history to the organisation's standards
Goodis a detailed report indicating each point of compliance or discrepancy
-
Askmeeting minutes discussing software reviews: Request notes from meetings where third-party software assessments were discussed
Goodincludes dated records showing involvement from relevant teams and actions agreed upon
-
Askrecords of testing or simulations: Request evidence from the software developers regarding any simulations or tests conducted on the software
Goodis comprehensive documentation with clear results and any corrective actions taken
-
Askthe internal audit record: Obtain records of internal audits related to software builds
Goodfeatures a detailed audit trail with clear follow-up actions or resolutions
Cross-framework mappings
How ISM-2055 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (3) expand_less | ||
| Annex A 8.25 | ISM-2055 requires that where build provenance exists for imported third-party software components, it is used during development to confi... | |
| Annex A 8.26 | ISM-2055 requires using build provenance (when available) for imported third-party software components during development to ensure they ... | |
| Annex A 8.28 | ISM-2055 requires developers to use available build provenance for third-party components to ensure they were built to an appropriate sta... | |
| sync_alt Partially overlaps (1) expand_less | ||
| Annex A 8.29 | ISM-2055 requires using third-party build provenance (when available) during development to validate that imported components meet approp... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.