9.1.1. SDLC Methodologies and Security Integration
💡 First Principle: Every SDLC phase has a corresponding security activity that costs dramatically less than finding the same flaw later. The developer who writes a SQL query without parameterization doesn't know it's a vulnerability; the architect who reviews data flows during design might catch that the query is being built with user input; the threat model explicitly identifies injection as a risk before a line of code is written. Prevention at source is always cheaper than detection and remediation.
Security activities by SDLC phase:
| Phase | Primary Activity | Security Activity | Output |
|---|---|---|---|
| Requirements | Define what the system must do | Security requirements, privacy requirements, abuse cases | Security requirements document |
| Design | Architect the system | Threat modeling (STRIDE), security architecture review, data flow analysis | Threat model; design review findings |
| Implementation | Write code | Secure coding standards, code review (manual + SAST), SCA | Code review findings; clean SAST baseline |
| Testing | Verify functionality | DAST, IAST, security test cases from threat model, fuzz testing | Security test report |
| Deployment | Release to production | Configuration review, hardening verification, pre-prod pentest | Deployment checklist; hardening verification |
| Maintenance | Operate and support | Vulnerability scanning, patch management, ongoing monitoring | Vulnerability reports; patch records |
Threat modeling — the most impactful security activity: Threat modeling during design asks: "What could go wrong with this system, and how could it be attacked?" It produces a structured list of threats that informs security requirements, design decisions, and test cases.
STRIDE threat categories:
| Threat | Targets | Example | Countermeasure |
|---|---|---|---|
| Spoofing | Authentication | Attacker impersonates legitimate user | Strong authentication; MFA |
| Tampering | Integrity | Attacker modifies data in transit or storage | Integrity controls; signing; MAC |
| Repudiation | Non-repudiation | User denies performing an action | Audit logging; digital signatures |
| Information Disclosure | Confidentiality | Attacker reads data they shouldn't | Encryption; access controls; least privilege |
| Denial of Service | Availability | Attacker exhausts resources | Rate limiting; redundancy; input validation |
| Elevation of Privilege | Authorization | Attacker gains more permissions than intended | Least privilege; authorization checks; sandboxing |
Software development methodologies:
| Methodology | Security Consideration |
|---|---|
| Waterfall | Security reviews at phase gates; late-stage changes expensive |
| Agile/Scrum | Security stories in backlog; security testing in each sprint; DevSecOps |
| DevOps/DevSecOps | Security automated in CI/CD pipeline; SAST/DAST/SCA on every commit |
| Spiral | Risk-driven; explicit risk analysis at each spiral iteration |
DevSecOps security pipeline integration:
⚠️ Exam Trap: "We run DAST in the CI/CD pipeline, so we have DevSecOps." DAST without SAST leaves source code vulnerabilities undetected. SAST without SCA leaves third-party library vulnerabilities undetected. DevSecOps requires security automation at each stage — code analysis, build analysis, runtime testing, and production monitoring — not just one tool in the pipeline.
Reflection Question: A development team delivers code to a security review team at the end of every six-month release cycle. The security team performs a penetration test and returns findings. The development team addresses critical findings before release, but many medium findings are deferred. Describe three specific changes to this security model that would find more vulnerabilities earlier and reduce the cost of remediation, and explain what SDLC phases they belong to.
