ASD ISM 2040 Ensure secure programming practices in software development
What it says
Secure programming practices for the chosen programming language are used for software development.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishDevelop software using secure programming methods tailored to the chosen language to prevent vulnerabilities.
This control is about using safe and secure methods when building software, tailored to the specific programming language being used. It matters because if software is not developed securely, it can have weaknesses that hackers might exploit, putting data, finances, and reputations at risk.
Free. Save your status, tasks and notes.
Why it matters
Failure to apply secure programming practices can introduce vulnerabilities (e.g., injection, auth flaws), enabling compromise, data leakage, and service disruption.
How to implement
Identify key developers: The manager should identify and empower the key developers responsible for coding projects.
Ensure they have the necessary training or resources to learn secure programming practices specific to the languages they use.
Integrate security into code reviews: Team leaders should include security checks as a part of the regular code review process.
Ensure that every piece of code is not just checked for bugs but also for security vulnerabilities.
Set up developer guidelines: The IT team should develop and circulate clear, practical guidelines for secure coding.
These should be easy to follow and aligned with recognised standards like those from the Australian Cyber Security Centre (ACSC).
Use automated tools: The IT team should implement tools that automatically check code for vulnerabilities as it's written.
These tools can catch issues early, providing real-time feedback to developers.
Organise regular training: Management should arrange for ongoing training in secure coding tactics.
Keep these sessions interactive and include recent examples of security failures and how they could have been prevented.
Keep it running
Maintain language-specific secure coding standards and enforce them via peer reviews, SAST in CI/CD, dependency checks, and periodic developer secure-coding training.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A list of secure coding guidelines: Ensure these documents outline procedures for secure programming practices in the languages used.
Look at
Whether they're up to date and easy for developers to access and understand.
Good evidence
Guidelines explicitly tailored to the specific languages and frameworks in use.
- Check 2 of 5What an auditor asks for
Look at
Comments or annotations related to security issues and resolutions.
Good evidence
Each review session contains documented consideration of security vulnerabilities.
- Check 3 of 5What an auditor asks for
Ask for
The records of security training sessions attended by developers.
Look at
Attendance lists and materials used in training.
Good evidence
Regular sessions with high developer participation and updated content about current threats.
- Check 4 of 5What an auditor asks for
Look at
How they are integrated into the development process and any reports generated.
Good evidence
Tools are active, producing reports, and there's evidence of follow-up on identified issues.
- Check 5 of 5What an auditor asks for
Ask for
How developers are encouraged to share experiences and lessons learnt from applying secure coding practices.
Look at
The mechanisms like internal forums or retrospective meetings.
Good evidence
Regular feedback loops that help to continuously improve secure coding practices.
Mappings
Closest match in ISO/IEC 27001: A.8.28, Secure coding practices in software development, which asks for the same thing.
ISO/IEC 27001: 2 mappings
This control is equivalent to A.8.28.
Annex A 8.28 requires secure coding principles to be applied to software development. ISM-2040 directly requires the use of secure programming practices for the chosen programming language during software development, which is the practical expression of secure coding principles. Both controls address the same core requirement, with ISM-2040 providing slightly more implementation specificity (language-specific practices).
This control partially meets A.8.25.
ISM-2040 requires developers to use secure programming practices for the chosen language as part of building software securely. Annex A 8.25 is broader because it requires establishing and applying rules across the secure development lifecycle, which can include governance, design, build, test, release and maintenance practices. Secure programming in ISM-2040 is a key subset of the overall SDL rules expected by Annex A 8.25.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.