ASD ISM 2082 Using cryptographic BOM in software development
What it says
If a cryptographic bill of materials is available for imported third-party software components, it is used during software development to ensure such software components provide support for standardised implementations of ASD-Approved Cryptographic Algorithms.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure imported software uses standard encryption by checking its cryptographic details.
When you bring new software into your business, it's important to check if it uses proper security methods to protect data. This matters because if the software's security isn't up to standard, it could lead to data breaches or other security problems, putting your business and customers at risk.
Free. Save your status, tasks and notes.
Why it matters
Without using cryptographic BOMs for third-party components, non‑ASD-approved or weak crypto may be introduced, risking data exposure and loss of integrity.
How to implement
Business managers should ensure that the IT team requests a cryptographic bill of materials (CBOM) from any new software vendor.
This CBOM is essentially a list detailing the encryption methods the software uses. It helps verify that the software meets Australian Government standards for data protection.
The IT team should validate the CBOM against the Australian Signals Directorate (ASD) Approved Cryptographic Algorithms.
They can do this by comparing the CBOM details with the list of approved methods available on the official ASD website, ensuring compliance.
Procurement officers should include a requirement for a CBOM in their contracts with software vendors.
They can do this by clearly specifying in the purchase contract that the vendor must provide a CBOM as part of the software delivery.
System administrators should cross-check the provided CBOM during software installation and configuration.
They should ensure that the encryption methods listed are correctly implemented in the software settings, aligning with the ASD standards.
Business leaders should arrange for an annual review of all third-party software for compliance with cryptographic standards.
They can schedule meetings with IT to ascertain that all software remains up-to-date and compliant with current ASD standards.
Keep it running
When third‑party crypto BOMs exist, review them at intake and on updates to confirm only ASD‑Approved algorithms/implementations are used, and record any exceptions.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The CBOM for each imported software product: Request a document showing all cryptographic measures used by the software.
Look at
Detailed descriptions of the encryption algorithms and methods.
Good evidence
Includes clearly labelled methods that match ASD-Approved Cryptographic Algorithms.
- Check 2 of 5What an auditor asks for
Look at
Clauses that mandate the provision of a CBOM upon delivery.
Good evidence
Is a contract signed by both parties with a CBOM requirement clause.
- Check 3 of 5What an auditor asks for
Look at
Clear steps detailing the validation against ASD guidelines.
Good evidence
Is a process document with specific steps and references to ASD standards.
- Check 4 of 5What an auditor asks for
Look at
Entries confirming the matched encryption methods in the CBOM.
Good evidence
Includes documented proof of settings that align with ASD standards.
- Check 5 of 5What an auditor asks for
Ask for
Meeting minutes or reports from the annual software compliance review.
Look at
Documentation that shows the review was completed and any corrective actions needed.
Good evidence
Is a report with compliance status and action items followed up.
Mappings
Closest match in ISO/IEC 27001: A.5.19, Managing information security in supplier relationships, which this control partially meets.
ISO/IEC 27001: 4 mappings
This control partially meets A.5.19.
ISM-2082 requires using a CBOM for imported third-party components during development to validate cryptographic support aligns with ASD‑Approved Cryptographic Algorithms. ISO/IEC 27001:2022 Annex A 5.19 requires processes to manage information security risks arising from supplier products and services, including security requirements and assurance for third-party deliverables. ISM-2082 is a specific control for one class of supplier risk (non-standard or weak cryptography), while Annex A 5.19 covers the full range of supplier relationship risks and controls.
This control partially meets A.5.21.
ISM-2082 requires developers to use a CBOM for imported third-party software components to confirm those components support standardised ASD‑Approved Cryptographic Algorithms. ISO/IEC 27001:2022 Annex A 5.21 addresses managing information security risks across the ICT supply chain for products and services, which includes evaluating security properties of third-party components. ISM-2082 is a specific technique within supply-chain assurance focused on cryptographic implementations, whereas Annex A 5.21 is broader across many supply-chain risk types and assurance activities.
This control partially meets A.8.24.
ISM-2082 requires using a cryptographic bill of materials (CBOM) for imported third-party components during software development to verify support for standardised ASD‑Approved Cryptographic Algorithms. ISO/IEC 27001:2022 Annex A 8.24 requires the organisation to define and implement rules for effective cryptography use and cryptographic key management, which would include algorithm standards and acceptable implementations. ISM-2082 is a specific supply-chain/development verification mechanism that can be used to satisfy part of Annex A 8.24, but Annex A 8.24 also covers broader cryptographic governance and key lifecycle controls beyond CBOM use.
This control supports A.8.27.
ISM-2082 requires checking imported third-party components via a CBOM to confirm they support standardised ASD‑Approved Cryptographic Algorithms. ISO/IEC 27001:2022 Annex A 8.27 requires secure system architecture and engineering principles to be established and applied during development, which typically include approved cryptographic primitives and patterns. ISM-2082 supports Annex A 8.27 by providing concrete evidence-based validation of cryptographic implementation choices in dependencies, though Annex A 8.27 extends well beyond cryptography to broader architectural principles.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.