Secure coding means writing software to avoid introducing vulnerabilities that attackers could exploit. It begins while code is written, rather than relying only on tests before deployment. Security-focused coding standards give developers a consistent way to make those choices. section 7.4.5
Restricting input
An application that accepts input can be coded to allow only approved input types. This is a concrete secure coding choice: it reduces the opportunity for unapproved input to create a security weakness. section 7.4.5
Secure coding works alongside other development controls. Threat modeling identifies possible attacks during design; code reviews and static application security testing (SAST) help find flaws in code; dynamic application security testing (DAST) checks running software. Scanning third-party and open source libraries addresses risks introduced through dependencies. These checks support secure coding but do not replace it. section 4.1.3 section 7.4.5
Figure 7.7 An overview of how security is integrated into each SDLC phase, highlighting critical security tasks associated with planning, development, testing, deployment, and maintenance stages.
Use the SDLC overview to place secure coding among security tasks in planning, development, testing, deployment, and maintenance. section 7.4.5
For a new product, make security checks part of design reviews, prototyping, and testing milestones rather than a late obstacle to launch. Train developers in secure coding practices relevant to their role, and use measures such as compliance readiness and production vulnerabilities to keep security aligned with product goals. section 4.1.3 section 7.2
