Ensure Software Components Meet Build Standards
Use available build history for third-party software to verify it meets standards during development.
🏛️ Framework
ASD Information Security Manual (ISM)
🧭 Control effect
Preventative
🔐 Classifications
NC, OS, P, S, TS
🗓️ ISM last updated
May 2025
✏️ Control Stack last updated
22 Feb 2026
🎯 E8 maturity levels
N/A
Guideline
Guidelines for software developmentIf 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.
Source: ASD Information Security Manual (ISM)
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.
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
-
Ask: the software build history documentation: Request all relevant records from the procurement or IT team
Good: shows clear records with verifiable information about how the software was built
-
Ask: 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
Good: is a detailed report indicating each point of compliance or discrepancy
-
Ask: meeting minutes discussing software reviews: Request notes from meetings where third-party software assessments were discussed
Good: includes dated records showing involvement from relevant teams and actions agreed upon
-
Ask: records of testing or simulations: Request evidence from the software developers regarding any simulations or tests conducted on the software
Good: is comprehensive documentation with clear results and any corrective actions taken
-
Ask: the internal audit record: Obtain records of internal audits related to software builds
Good: features 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.
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| Partially meets (3) | ||
| 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... | |
| Partially overlaps (1) | ||
| Annex A 8.29 | ISM-2055 requires using third-party build provenance (when available) during development to validate that imported components meet approp... | |