| name | design-secure-sdlc |
| description | Use when establishing or improving a software development lifecycle — embedding security requirements, threat modeling, and security testing at each phase to find vulnerabilities when they cost 10× less to fix. |
| source | OWASP Top 10 Proactive Controls C04 (owasp.org/www-project-top-ten/); OWASP SAMM v2.0; Microsoft Security Development Lifecycle (SDL); NIST SP 800-218 (SSDF) |
| tags | ["security","owasp","sdlc","threat-modeling","security-requirements","appsec","developer"] |
Design Secure SDLC
Integrate security requirements at design, threat modeling in sprint planning, SAST/DAST in CI, and security acceptance criteria in definition of done — finding vulnerabilities at 10× lower cost than post-deployment remediation.
Why This Is Best Practice
Adopted by: OWASP Top 10 Proactive Controls C04 (Address Security from the Start) and OWASP SAMM v2.0 are the primary references. Microsoft's Security Development Lifecycle (SDL) has been mandatory for all Microsoft products since 2004 and documented a 50% reduction in security vulnerabilities post-SDL. NIST SP 800-218 (Secure Software Development Framework) is the US federal mandate for software supply chain security. Google, AWS, and GitHub all publicly describe security-integrated SDLC as core to their engineering practice.
Impact: IBM Systems Science Institute's research (confirmed by NIST) found that fixing a security defect in requirements costs $0.1×, in design $0.3×, in development $1×, in testing $3×, and in production $30×. Gartner (2022) estimates that organizations integrating security into SDLC reduce security incidents by 70% compared to bolt-on security testing. Microsoft's SDL reduced critical vulnerabilities by 50% in Windows Vista vs. Windows XP across the same codebase by adding security requirements, threat modeling, and mandatory security review.
Penetration testing at the end of a release cycle (the alternative) finds vulnerabilities too late — they've already been designed, coded, and deployed. Retrospective security testing cannot change architecture decisions that create entire classes of vulnerabilities. Shifting security left means decisions like "use parameterized queries" are made in sprint 1, not discovered as a critical finding post-launch.
