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.
This control maps to 69 controls across 26 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
ISO 27002:2022 8.28 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of ISO 27002:2022 your existing evidence covers. Hold NIST SP 800-53 Rev 5 and 79 of 93 ISO 27002:2022 controls already carry evidence.
Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 180 were rejected on the NIST SP 800-53 Rev 5 pair alone.
The graph holds this control, the 69 it maps to, and the evidence behind each claim, over MCP and REST.