Skip to content
Software development
ASD ISMISM-2041

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 English

Use 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.

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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 27001

ISO/IEC 27001: 2 mappings

  • A.8.25Secure development lifecyclePartially meets

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.