8.28 Secure coding

Software development is to follow secure coding principles. Purpose: have software written securely so that it contains fewer potential security vulnerabilities. Guidance: put organization-wide governance of secure coding in place with a minimum secure baseline, extended to third-party components and open source, and use real-world threat monitoring and current vulnerability advice to keep improving the principles. Apply them to new code and to reuse, internally and in products and services supplied to others. Before coding, plan for: the organization's expectations and approved secure coding principles for in-house and outsourced code; the coding habits and defects that have commonly caused vulnerabilities in the past; configuring tools such as IDEs to help enforce secure code; following guidance from tool and runtime providers; keeping development tools such as compilers up to date; developers' qualification in secure coding; secure design and architecture, with threat modelling; secure coding standards, mandated where relevant; and controlled development environments. While coding, consider language-specific secure practices; techniques such as peer review, pair programming, refactoring, test-driven development and security-focused iterations; structured programming; documenting code and removing defects that could be exploited; and banning insecure design choices, for example passwords written into code, code samples nobody approved, or web services that require no authentication. Test during and after development (8.29), for instance with static application security testing. Before release, evaluate the attack surface and least privilege, and analyse the most common programming errors and record that they have been mitigated. After release, package and deploy updates securely; handle reported vulnerabilities (8.8); log errors and suspected attacks and review the logs to adjust code; and protect source code from unauthorized access and tampering with configuration management tools offering access and version control. For external tools and libraries, keep an inventory with versions and update them in line with releases; select, authorize and reuse well-vetted components, especially for authentication and cryptography; weigh their licence, security and history; ensure software is maintainable, tracked and from proven, reputable sources; and ensure development resources and artefacts remain available long enough. When modifying a software package, consider the risk to built-in controls and integrity processes, whether vendor consent is needed, whether the vendor could supply the change as a standard update, the impact of taking over future maintenance, and compatibility with other software. Other information: security-relevant code should be invoked when needed and be tamper-resistant; interpreted code keeps this property only on servers users cannot reach, with administrator access protected by just-in-time administration and strong authentication and directory browsing disabled; code should assume it will be attacked, critical applications can check outputs against safe bounds with simple verifiable code, web applications are prone to injection and cross-site scripting; ISO/IEC 15408 covers security evaluation.

Source: ISO/IEC 27002:2022, 8.28. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.

ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.