ASD ISM 0938 Select secure-by-design committed vendors
What it says
Vendors that have demonstrated a commitment to Secure by Design and Secure by Default principles and practices, including secure programming practices and either memory-safe programming languages or less preferably memory-safe programming practices, are used for user applications.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishChoose vendors who prioritise secure design and development in their applications.
Choosing the right software vendors is like picking the best insurance for your business. When you select vendors that build their products with security in mind from the ground up, you're less likely to suffer from data breaches or system failures. If a vendor doesn't prioritise secure design, you might end up with software that exposes your business to hackers, leading to data loss, financial damage, and reputational harm.
Free. Save your status, tasks and notes.
Why it matters
Using vendors lacking Secure-by-Design/Default and memory safety increases exploitable flaws in user applications and likelihood of compromise.
How to implement
IT managers should collaborate with the procurement team to set evaluation criteria for vendors.
They should draft a checklist of security features and practices that vendors must meet and ensure this is part of the vendor selection process.
Compliance officers should ensure contracts with vendors include clauses on security practices.
This can involve reviewing legal documents to mandate that vendors adhere to secure programming standards throughout the relationship.
IT teams should run penetration tests on applications from vendors.
This involves attempting to find vulnerabilities in the software, ensuring they are quickly addressed by the vendor.
Keep it running
Regularly assess vendor security posture: evidence of Secure-by-Design/Default practices, secure coding SDLC, and use of memory-safe languages where feasible.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The vendor evaluation report: Request documents used to assess the vendor's security practices.
Look at
Whether the vendor's secure-by-design commitment and practices were clearly evaluated.
Good evidence
A well-documented report showing vendors align with secure-by-design requirements.
- Check 2 of 5What an auditor asks for
Ask for
The procurement decision criteria checklist: Review the checklist used by the procurement team.
Look at
Whether it includes specific security criteria related to programming practices.
Good evidence
A checklist that clearly benchmarks vendor practices against industry security standards.
- Check 3 of 5What an auditor asks for
Ask for
Contracts with vendors: Request the contract or agreement details which outline security practices.
Look at
Clauses or sections that stipulate security expectations from the vendor.
Good evidence
A contract with clear terms on required secure design and practices.
- Check 4 of 5What an auditor asks for
Ask for
Results of vendor application penetration tests: Review the reports from these tests.
Look at
Whether any vulnerabilities were found and how the vendor reacted.
Good evidence
A test report showing vulnerabilities identified, fixes applied, and vendor cooperation.
- Check 5 of 5What an auditor asks for
Ask for
Examples of vendor support responses: Request evidence of vendor responses to any security incidents or queries.
Look at
The timeliness and thoroughness of these responses.
Good evidence
Documented and timely vendor responses detailing the resolution steps taken.
Mappings
Closest match in ISO/IEC 27001: A.5.21, Managing information security in the ICT supply chain, which this control partially meets.
ISO/IEC 27001: 4 mappings
This control partially meets A.5.21.
ISM-0938 focuses on choosing vendors for user applications who demonstrate Secure by Design/Secure by Default practices. ISO/IEC 27001:2022 Annex A 5.21 covers managing information security risks in the ICT supply chain, including setting supplier security expectations. Annex A 5.21 spans broader ICT supply chain risks, while ISM-0938 is application-specific.
This control partially meets A.8.25.
ISM-0938 requires selecting vendors whose development practices demonstrate Secure by Design/Secure by Default. ISO/IEC 27001:2022 Annex A 8.25 speaks to rules for a secure development lifecycle, supporting the assurance ISM-0938 seeks from vendors. Annex A 8.25 covers development governance, while ISM-0938 focuses on vendor selection based on their adherence to these principles.
This control partially meets A.8.27.
ISM-0938 seeks vendors with commitment to Secure by Design/Secure by Default, like memory safety. ISO/IEC 27001:2022 Annex A 8.27 involves secure system architecture and engineering principles, which vendors should follow. Annex A 8.27 guides organisational engineering, whereas ISM-0938 targets vendor selection who apply such practices.
This control partially meets A.8.28.
ISM-0938 requires organisations to select user application vendors that demonstrate Secure by Design/Secure by Default, including secure programming practices and use of memory-safe languages. ISO/IEC 27001:2022 Annex A 8.28 mandates secure coding principles in software development, which ISM-0938 expects vendors to follow. Annex A 8.28 focuses on development practices, while ISM-0938 focuses on procurement based on these practices.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.