ASD ISM 2054 Ensure no vulnerabilities in third-party software components
What it says
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.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUse available software bill of materials to check third-party components for vulnerabilities during development.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
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.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The software bill of materials: Request a complete list of third-party software components currently in use.
Look at
How comprehensive and up-to-date this list is.
Good evidence
A detailed, regularly updated document categorising each component, its version, and source.
- Check 2 of 5What an auditor asks for
Ask for
Vulnerability scan reports: Request records showing checks against vulnerability databases for listed components.
Look at
The dates of these checks and any decisions made from the results.
Good evidence
Recent scan results with actions noted for any issues found.
- Check 3 of 5What an auditor asks for
Ask for
Training records: Request evidence of staff training sessions related to the software bill of materials process.
Look at
The attendee list and the content covered.
Good evidence
Detailed training logs with participant feedback and a clear schedule of future sessions.
- Check 4 of 5What an auditor asks for
Ask for
Meeting minutes: Request documentation from regular meetings discussing third-party component security.
Look at
Discussions on updates, vulnerabilities, and necessary actions.
Good evidence
Clear, recorded action items with responsible persons and completion dates.
- Check 5 of 5What an auditor asks for
Ask for
Change management logs: Request evidence of processes used to handle vulnerable components.
Look at
Records of decisions made to patch or replace components.
Good evidence
Detailed change logs showing resolutions and approvals.
Mappings
Closest match in ISO/IEC 27001: A.8.8, Management of technical vulnerabilities, which this control covers in full and more.
ISO/IEC 27001: 2 mappings
This control is broader than 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 components have no known vulnerabilities. This aligns with Annex A 8.8 because both require obtaining vulnerability information and acting on exposure, with ISM-2054 being a specific method focused on SBOM-driven third-party component checking in the SDLC. Annex A 8.8 is broader, covering technical vulnerability management across information systems generally, not only third-party components or SBOM usage.
This control partially meets A.8.29.
ISM-2054 requires using an available SBOM for third-party components to identify and avoid known vulnerabilities during software development. This supports Annex A 8.29 by providing a concrete input to security testing (component inventory plus versioning) that can be used to drive SCA checks and vulnerability-focused test activities within the development life cycle. Annex A 8.29 is broader in testing scope (e.g. dynamic testing, acceptance testing) whereas ISM-2054 is specifically about SBOM-informed vulnerability checking of third-party components.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.