Secure coding
Purpose
Apply secure coding principles to software development to reduce the number of security vulnerabilities in the code.
How to meet this control
In short: Apply secure coding principles to software development.
- Step 01Set a secure coding baseline covering input validation, output encoding, error handling and no hard-coded secrets, applied to in-house and third-party code
- Step 02Configure developer IDEs with linters and security plugins and qualify developers through secure coding training
- Step 03Run static application security testing in CI and block merges on high-severity findings
- Step 04Use peer review and threat modelling during coding and manage external libraries with an inventory and regular updates
- Step 05Apply software composition analysis to vet and patch open-source dependencies
- Step 06Review the attack surface before release and securely handle vulnerabilities reported after deployment
Tip: Linting/SAST in CI plus a secure-coding checklist in code review.
What ISO 27002 says to cover
Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.
- ›Set organisation-wide secure coding governance with a minimum baseline, covering third-party code
- ›Monitor real-world threats and current vulnerability advice to keep practices improving
- ›Before coding, define secure coding expectations, configure IDEs and qualify developers
- ›During coding, use secure techniques such as peer review, threat modelling and no hard-coded secrets
- ›Run testing during and after development, including static application security testing
- ›Before going live, review the attack surface and confirm common errors are mitigated
- ›After release, securely deploy updates, handle reported vulnerabilities and review errors
- ›Manage external libraries with an inventory, regular updates and vetting of components
Audit evidence to keep
- - Secure coding standard and the minimum baseline
- - SAST configuration in CI and a sample blocked finding
- - Evidence of code review and threat modelling in development
- - Software composition analysis inventory and update records
- - Secure coding training completion for developers
Common mistakes
- - Treating security review as optional when release pressure rises
- - Testing only happy paths and missing abuse cases
- - Not linking production changes to approvals and rollback plans
Owner, cadence, and proof
Assign one accountable owner for A.8.28. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.
Policy templates for this control
Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.