Ensure No Vulnerabilities in Third-Party Software Components
Use available software bill of materials to check third-party components for vulnerabilities during development.
Plain language
When you use third-party software components in your business software, it's crucial to make sure those components don't have any known security problems. This matters because vulnerabilities in these components could be exploited by attackers to steal sensitive information or cause disruption to 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 bill of materials is available for imported third-party software components, it is used during software development to ensure such software components have no known vulnerabilities.
Why it matters
If SBOMs aren’t used to check imported third‑party components, known vulnerable libraries can ship in builds, enabling compromise, outages and data exposure.
Operational notes
Where available, ingest the vendor SBOM into build tooling and compare components/versions against CVE feeds; block or update any third‑party component with known vulnerabilities.
Implementation tips
- Business owners should work with their IT team to create a software bill of materials. This list should include all third-party components used in your software, detailing what each component does and where it comes from.
- The IT team should conduct regular checks against a vulnerability database for each listed component. Use tools like those provided by the Australian Signals Directorate (ASD) to scan for known issues that may affect these components.
- Managers should ensure that relevant team members are trained to understand the importance of the software bill of materials and how to update it. This training should include instruction on how to use any tools or databases that are part of the process.
- Owners or managers should schedule regular meetings with the IT team to review the status of third-party components. This meeting should discuss any new threats or updates required to keep the software secure.
- IT teams should implement a process for removing or patching any third-party component found to have vulnerabilities. This involves having a protocol in place for quickly deploying updates or finding alternative components.
Audit / evidence tips
- AskThe software bill of materials: Request a complete list of third-party software components currently in use GoodA detailed, regularly updated document categorising each component, its version, and source
- AskVulnerability scan reports: Request records showing checks against vulnerability databases for listed components GoodRecent scan results with actions noted for any issues found
- AskTraining records: Request evidence of staff training sessions related to the software bill of materials process GoodDetailed training logs with participant feedback and a clear schedule of future sessions
- AskMeeting minutes: Request documentation from regular meetings discussing third-party component security GoodClear, recorded action items with responsible persons and completion dates
- AskChange management logs: Request evidence of processes used to handle vulnerable components GoodDetailed change logs showing resolutions and approvals
Cross-framework mappings
How ISM-2054 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.8 | ISM-2054 requires that, where an SBOM exists for imported third-party software components, it is used during development to ensure those ... | |
| handshake Supports (1) expand_less | ||
| Annex A 8.29 | ISM-2054 requires using an available SBOM for third-party components to identify and avoid known vulnerabilities during software development | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.