OWASP Secure SDLC
The Software Development Lifecycle (SDLC) describes the stages every software project goes through — from initial idea to retirement. A Secure SDLC embeds security activities into each of those stages rather than treating security as a single review at the end. OWASP provides two key frameworks for this: the Software Assurance Maturity Model (SAMM) and the Application Security Verification Standard (ASVS).
The Renovation Analogy
Replacing the plumbing in a finished house is far more expensive than planning the plumbing layout before the walls go up. Security works the same way. Fixing a design flaw before a line of code is written costs hours. Fixing the same flaw in a live production system costs days of engineering work, emergency patches, potential data breach notification, and regulatory fines.
Traditional SDLC vs Secure SDLC
Traditional SDLC:
Requirements --> Design --> Build --> Test --> Release --> [Security review here]
|
Security issues found too late
Expensive to fix
Often skipped under deadline pressure
Secure SDLC:
Requirements --> Security requirements defined here
Design --> Threat modeling performed here
Build --> SAST, secure coding standards applied here
Test --> DAST, penetration testing here
Release --> Security sign-off checklist here
Operations --> Monitoring, patch management, incident response here
Stage 1: Requirements — Define Security Requirements
Every feature request should include security acceptance criteria. Use the OWASP ASVS as a source of requirements. The ASVS defines over 280 specific, testable security controls organized into 14 categories and three verification levels.
ASVS Verification Levels:
Level 1 --> Basic security for all applications
Level 2 --> Standard security for most business applications
Level 3 --> Advanced security for critical, high-risk applications
(banking, healthcare, government systems)
Example ASVS requirement (V2.1.1):
"Verify that user set passwords are at least 12 characters in length."
Stage 2: Design — Threat Modeling
The team reviews the system design and identifies what could go wrong. Attack trees and data flow diagrams visualize where sensitive data travels and which components an attacker could target. This was covered in depth in the Insecure Design topic.
Stage 3: Build — Secure Coding Standards
Developers follow organization-wide secure coding standards. Code reviews include security checks. SAST tools flag issues automatically in the IDE and the CI pipeline.
Secure coding standards cover: Input validation rules --> How to validate each data type Output encoding requirements --> Prevent XSS at the display layer Authentication implementation --> Use approved auth libraries only Cryptography standards --> Approved algorithms and key sizes Error handling rules --> No stack traces to end users Dependency management --> Approved package list, SCA required Secrets management --> No secrets in code, use vault
Stage 4: Test — Security Verification
Automated DAST scans run against every release candidate. High-risk features receive manual security testing. Annual penetration tests cover the full application.
Stage 5: Release — Security Gate
A security release checklist confirms all required checks passed before deployment. This gate prevents releases that contain known critical vulnerabilities.
Release Security Gate Checklist: [ ] SAST scan passed with no critical issues [ ] SCA scan: no known critical CVEs in dependencies [ ] DAST scan passed [ ] All security requirements from ASVS verified [ ] Secrets scan: no credentials committed to repository [ ] Security headers configured correctly [ ] Debug mode disabled in production config
Stage 6: Operations — Continuous Security
Security does not stop at deployment. The operations phase requires ongoing patch management, active monitoring for incidents, and a defined incident response process.
Operations security activities: Patch management --> Apply security patches within defined SLA Monitoring --> SIEM alerts on attack patterns Vulnerability scans --> Regular external scans of production Incident response --> Tested plan for breach detection and containment Penetration testing --> Annual test of production environment
OWASP SAMM: Measuring Your Security Program
OWASP SAMM (Software Assurance Maturity Model) gives organizations a way to measure and improve their security practices across five business functions:
Governance --> Strategy, policy, education Design --> Threat modeling, security requirements Implementation --> Secure build, secure deployment, defect management Verification --> Architecture assessment, testing, requirements-driven testing Operations --> Incident management, environment management, operational management Each function has three maturity levels. Organizations assess their current level and build a roadmap to improve.
DevSecOps: Security in Continuous Delivery
DevSecOps integrates security tooling into the automated pipeline so security checks run alongside every code change — not as a separate team gate at the end.
Classic model: Dev team --> [months later] Security team --> Release
DevSecOps model: Dev + Sec + Ops collaborate on every commit
Automated security tools in every pipeline stage
Security feedback reaches developers in minutes
Quick Implementation Checklist
[✓] Security requirements defined in every feature specification [✓] Threat modeling performed at the design stage [✓] Secure coding standards documented and trained [✓] SAST and SCA tools in the CI/CD pipeline [✓] Security release gate before every production deployment [✓] OWASP ASVS used as the verification standard [✓] OWASP SAMM used to measure and improve program maturity
Key Takeaway
Security built into every phase of development costs far less than security bolted on at the end. The OWASP ASVS provides the requirements, SAMM provides the maturity roadmap, and DevSecOps tooling makes security checks automatic and continuous.