ASD ISM 2060 Ensure code reviews for secure software design
What it says
Code reviews are utilised to ensure software components meets Secure by Design principles and practices as well as secure programming practices.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishCode reviews are used to verify software security and adherence to secure design principles.
A code review is like having a second pair of eyes to check software for any security issues. If we skip this step, there's a risk hackers could exploit hidden weaknesses in the software, leading to data breaches or other cyber threats.
Free. Save your status, tasks and notes.
Why it matters
Without code reviews, software may contain vulnerabilities that hackers can exploit, leading to serious security breaches.
How to implement
The IT team should set up a code review process.
This involves scheduling regular sessions where another developer checks the work for security flaws before it's finalised.
Managers need to ensure that their teams are aware of secure coding practices.
This can be done by organising training sessions to keep everyone's skills up to date.
Developers should document code changes clearly.
This helps reviewers understand what was changed and ensures no security gaps are introduced accidentally.
The project manager should monitor code review schedules.
Ensuring these reviews happen regularly and are not skipped when deadlines loom ensures consistent security checks.
IT leads should set up checklists of common security pitfalls.
Reviewers can then use these checklists as guides when evaluating code to ensure all bases are covered.
Keep it running
Ensure that code reviews remain a consistent part of your development process by addressing any bottlenecks promptly and maintaining comprehensive checklists.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
the code review records: Request documentation showing the reviews were completed for specific software releases.
Look at
dates, reviewer names, and notes on identified and fixed issues.
Good evidence
is a clear record showing regular reviews with detailed feedback.
- Check 2 of 5What an auditor asks for
Ask for
if training records are available: Request evidence of secure coding training sessions for developers.
Look at
attendance lists and course content.
Good evidence
includes dates, content specifics, and proof that all team members attended.
- Check 3 of 5What an auditor asks for
Ask for
the workflow documentation: Request a description of how code reviews are integrated into the development process.
Look at
documented steps and how feedback is tracked. A well-documented workflow shows a strong emphasis on incorporating security into everyday practices.
- Check 4 of 5What an auditor asks for
Ask for
examples of feedback given in recent code reviews.
Look at
whether the suggestions led to improvements in security. Good documentation shows specific issues identified and how they were resolved.
- Check 5 of 5What an auditor asks for
Ask for
the security checklist used in reviews: Request the actual checklists used by reviewers.
Look at
comprehensive lists that cover common security vulnerabilities. A thorough and specific checklist demonstrates a proactive approach to secure coding.
Mappings
Closest match in ISO/IEC 27001: A.8.25, Secure development lifecycle, which this control partially meets.
ISO/IEC 27001: 4 mappings
This control partially meets A.8.25.
ISM-2060 requires code reviews to be utilised to confirm Secure by Design and secure programming practices are being followed. ISO/IEC 27001:2022 Annex A 8.25 requires an established and applied secure development lifecycle, within which peer review and secure design verification activities commonly sit. Annex A 8.25 covers many lifecycle rules beyond code review, whereas ISM-2060 focuses specifically on the code review assurance activity.
This control partially meets A.8.28.
Annex A 8.28 requires secure coding principles to be applied throughout software development to prevent vulnerabilities. ISM-2060 supports this by requiring code reviews to verify Secure by Design and secure programming practices are present in the implemented code. Annex A 8.28 is broader (principles and practices overall), while ISM-2060 focuses on one key assurance mechanism (reviews).
This control partially overlaps A.8.29.
ISM-2060 requires code reviews to validate Secure by Design and secure programming practices in software. ISO/IEC 27001:2022 Annex A 8.29 requires security testing processes to be defined and implemented in the development lifecycle, which can include static analysis, manual review, and other verification activities that may overlap with code review. Annex A 8.29 is broader across multiple testing approaches, while ISM-2060 is specifically about the review of code/design conformance rather than testing outcomes.
This control supports A.8.27.
ISM-2060 requires code reviews to check that implementations reflect Secure by Design and secure programming practices. ISO/IEC 27001:2022 Annex A 8.27 requires secure architecture and engineering principles to be established and applied, and code reviews under ISM-2060 help verify that those principles are actually realised in code (e.g. correct use of security patterns and controls). Annex A 8.27 is design/engineering-principle focused, while ISM-2060 is an implementation verification mechanism.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.