ASD ISM 2041 Ensure use of memory-safe programming practices
What it says
Memory-safe programming languages, or less preferably memory-safe programming practices, are used for software development.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUse programming languages that prevent memory errors to enhance security in software development.
This control is about using safe coding practices in software development to avoid common mistakes that can lead to serious security problems. If a program misuses computer memory, it might crash or let hackers mess with the program in dangerous ways. By using safer programming languages or techniques, we reduce these risks and help keep our software secure.
Free. Save your status, tasks and notes.
Why it matters
Without memory-safe languages or practices, software is prone to buffer overflows and use-after-free bugs, enabling code execution, data theft, or system compromise.
How to implement
Software developers should select programming languages that are designed to prevent memory errors, such as Java, Python, or Rust, when starting a new project.
These languages automatically manage memory, which can prevent many types of security vulnerabilities. Developers can research and choose a language that best fits the project requirements while enhancing security.
IT managers should organise training for their team on memory-safe programming practices.
This can include workshops or online courses that focus on understanding how memory errors occur and how to avoid them using safe coding techniques. Engaging a trainer with expertise in memory-safe code is a practical approach to ensure the team has the necessary skills.
Project leaders should establish coding standards that prioritise memory safety.
These standards should be integrated into the development process and include guidelines on using safe libraries and frameworks. Document these standards and ensure that all developers are familiar with and follow them.
Quality assurance teams should incorporate static analysis tools to check the code for memory safety issues before the software is released.
Tools like Clang or Coverity can be set up to automatically scan code and highlight potential problems. This step helps catch errors early in the development cycle.
Procurement officers should ensure that external software vendors adhere to memory-safe practices.
When evaluating software from other companies, include memory safety requirements in their evaluation criteria and ask vendors to provide evidence of their memory management practices.
Keep it running
Prefer memory-safe languages (e.g., Rust) for new components; for C/C++, use sanitizers, fuzzing, and strict code review of unsafe memory operations.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The list of programming languages used in development projects: Request a document or report detailing the programming languages chosen for each project.
Look at
Whether the languages listed are recognised as memory-safe by industry standards.
Good evidence
Will show a selection of languages like Python, Java, or Rust, known for their memory safety features.
- Check 2 of 5What an auditor asks for
Look at
The dates, topics, and qualifications of the trainers to ensure they cover memory safety.
Good evidence
Is documentation showing regular training sessions addressing memory safety.
- Check 3 of 5What an auditor asks for
Ask for
The coding standard documents: Request the guidelines or standards documents used by developers.
Look at
Sections specifically addressing memory safety practices.
Good evidence
Is a comprehensive document with clear rules and examples of memory-safe code.
- Check 4 of 5What an auditor asks for
Ask for
To see the analysis results from tools like Clang or Coverity.
Look at
Reports highlighting memory issues and any follow-up actions taken to resolve them.
Good evidence
Includes recent reports showing a low number of memory-related issues and steps taken to address any that did occur.
- Check 5 of 5What an auditor asks for
Ask for
Vendor compliance documentation: Request documentation from vendors showing their adherence to memory-safe practices.
Look at
The details or certifications related to memory safety in the software they supply.
Good evidence
Is documentation that clearly outlines how vendors meet memory safety requirements.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.25.
ISM-2041 requires memory-safe languages or memory-safe programming practices as a concrete security requirement for software development. Annex A 8.25 requires establishing and applying rules for a secure development lifecycle across the full SDLC, which would typically incorporate secure coding standards such as memory safety. ISM-2041 is a specific technical rule within the broader governance and process scope of Annex A 8.25.
This control partially overlaps A.8.28.
Annex A 8.28 requires secure coding principles to be applied across software development. ISM-2041 overlaps by requiring memory-safe programming languages or (less preferably) memory-safe programming practices, which are specific secure coding choices to reduce memory corruption vulnerabilities. ISM-2041 is narrower and technology-specific, while Annex A 8.28 covers secure coding more broadly.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.




