ASD ISM 1730 Provide a software bill of materials to consumers
What it says
A software bill of materials is produced and made available to consumers of software.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure software users receive a detailed list of included software components.
A Software Bill of Materials (SBOM) is like a list of ingredients for your software. It tells you what software components and versions are included in any application you use. This is important because knowing what's inside can help identify potential security risks or legal issues, like if a component has vulnerabilities that need to be fixed, which could otherwise lead to hacks or data breaches.
Free. Save your status, tasks and notes.
Why it matters
Without an SBOM, vulnerabilities in third-party components may be missed, slowing mitigation and increasing breach risk.
How to implement
Software developers should create and document an SBOM for each product they develop.
They can do this by listing all the libraries and components they use, including open source ones, along with their versions and sources.
Managers should ensure that the IT team regularly updates the SBOM when changes or updates are made to the software.
This can be done by scheduling routine checks and updates after every major release or patch.
The IT team should work on making the SBOM accessible to consumers, such as clients or users.
This could be achieved by including it as part of the user documentation or software packaging.
Procurement teams should request an SBOM from their software vendors before purchasing software products.
This involves contacting the vendor and verifying that the SBOM includes detailed component information.
Legal and compliance teams should review the SBOM to ensure all components comply with relevant licensing agreements.
They can do this by cross-referencing components against known licence databases to spot any compliance issues.
Keep it running
Automate SBOM generation in CI/CD and publish it with every release; keep component identifiers/versions consistent across updates.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A copy of the SBOM for a chosen software application.
Look at
Whether it lists all components, versions, and sources for each part of the software.
Good evidence
Includes a complete list with no omissions and accurate details.
- Check 2 of 5What an auditor asks for
Look at
The date of the last update and what changes were tracked.
Good evidence
Is a recent update log with details on what was changed.
- Check 3 of 5What an auditor asks for
Ask for
A demonstration of how the SBOM is provided to consumers.
Look at
How easily a consumer can access this information, such as a download link on a customer portal.
Good evidence
Is an accessible and user-friendly method for consumers.
- Check 4 of 5What an auditor asks for
Look at
Whether there are clear guidelines on when and how updates occur.
Good evidence
Includes documented procedures adhered to by the software development team.
- Check 5 of 5What an auditor asks for
Ask for
To see the review process that checks component compliance.
Look at
How components are verified against licensing restrictions.
Good evidence
Shows a systematic check, possibly using specialised software or a detailed review checklist.
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-1730 requires that a software bill of materials (SBOM) is produced and made available to consumers of software. This is a specific secure-development and supply-chain transparency practice that fits within ISO/IEC 27001:2022 Annex A 8.25, because publishing an SBOM operationalises "rules for secure development" around component governance, third‑party dependency management, and enabling downstream vulnerability response by customers. Annex A 8.25 is broader and includes secure coding, design, testing, build/release controls and toolchain practices, whereas ISM-1730 focuses narrowly on the SBOM artefact and its availability to consumers.
ISO/IEC 42001: 1 mapping
This control depends on A.6.2.7.
Annex A 6.2.7 requires the organisation to provide AI system technical documentation to categories of interested parties (such as consumers/users and partners) in an appropriate form. ISM-1730 requires producing and making available a Software Bill of Materials (SBOM) to consumers, which can be included as a component of AI system technical documentation packages distributed under Annex A 6.2.7. ISM-1730 is narrowly focused on component transparency for software supply chain risk, while Annex A 6.2.7 covers broader AI system documentation needs and audience-specific tailoring.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.