9.1. Security in the SDLC
💡 First Principle: Security defects are cheaper to fix the earlier in the SDLC they are found. A flaw caught during requirements review costs roughly 1× to fix; the same flaw in production costs 100× — not only in technical remediation, but in operational disruption, potential breach costs, and reputational damage. This multiplicative cost model is the argument for integrating security throughout the SDLC rather than testing for it at the end.
The secure SDLC is not a separate, parallel process bolted onto development — it is security-specific activities integrated into every existing phase of development. Developers write better code when security requirements are defined before they write the code. Architects design safer systems when threat models are built during design. Testers find more vulnerabilities when security test cases are derived from threat models.
Why this matters: SDLC phase sequencing and "which activity belongs in which phase" questions are directly tested. The key distinction: activities that define what should be built (requirements, design) must precede activities that verify what was built (testing, code review). Security cannot be added after the fact — it must be designed in.
⚠️ Common Misconception: "Penetration testing at the end of development finds all security issues." A penetration test at the end finds what a skilled attacker can exploit — typically a fraction of the actual vulnerability set. Flaws that don't rise to the level of exploitation, design-level weaknesses, insecure data handling in code paths not tested, and configuration issues may all be missed. The penetration test at the end is a final safety net, not a substitute for security throughout.
