SDLC Phases and Security Activities
Requirements Phase Risk assessment and threat modeling outputs drive security requirements. Requirements should be based on identified risks. Security requirements should have acceptance criteria. Acceptance criteria enable verification. Security requirements should be prioritized alongside functional requirements. Prioritization ensures security work is resourced. Abuse cases document how system could be misused. Abuse cases identify security requirements. Compliance requirements should be identified early. Early identification prevents late surprises. Design Phase Architecture reviews assess security of design. Reviews should occur before implementation. Threat modeling identifies threats and mitigations. Threat modeling should use structured methodology (STRIDE, PASTA, etc.). Abuse cases should be incorporated into design. Design should prevent abuse. Compensating controls should be identified for accepted risks. Compensating controls reduce residual risk. Security design patterns should be applied. Patterns prevent common vulnerabilities. Architecture Decision Records (ADRs) should document security trade-offs. ADRs provide rationale. Implementation Phase Paved roads provide secure-by-default frameworks and libraries. Paved roads make secure coding easy. Linters catch common security mistakes. Linting should run on every commit. Static Application Security Testing (SAST) finds vulnerabilities in code. SAST should block builds on high-severity findings. Software Composition Analysis (SCA) identifies vulnerable dependencies. SCA should block builds on critical vulnerabilities. Pull request templates enforce security checklists. Templates ensure consistent review. Code review should include security review. Reviewers should be trained on security. Pre-commit hooks enable local security checks. Local checks provide fast feedback. Verification Phase Dynamic Application Security Testing (DAST) tests running applications. DAST finds runtime vulnerabilities. Interactive Application Security Testing (IAST) combines SAST and DAST. IAST provides runtime context. Fuzzing discovers edge cases and crashes. Fuzzing should cover parsers and input handlers. Penetration testing simulates real attacks. Penetration testing should be performed by skilled testers. Policy checks enforce security policies. Policy violations should block deployment. Negative tests verify security controls work. Negative tests ensure authorization is enforced. Security acceptance tests verify security requirements. Acceptance tests should be automated. Release Phase Artifacts should be signed. Signing proves authenticity. Provenance should be verified. Provenance ensures artifacts are from trusted builds. Change management should include security review. Review ensures changes do not introduce vulnerabilities. Rollback plans should be tested. Rollback enables recovery from issues. Deployment should be gradual with monitoring. Gradual deployment limits blast radius. Operations Phase Logging and monitoring should detect security events. Detection enables response. Incident response drills validate procedures. Drills ensure readiness. Vulnerability management should track and remediate vulnerabilities. Vulnerability management should have SLAs. Post-incident updates should incorporate lessons learned. Learning prevents recurrence. Security metrics should be tracked and reported. Metrics show program effectiveness.Security Gates
Gate Criteria Security gates define criteria that must be met before proceeding. Gates ensure security requirements are met. Gate criteria should be objective and measurable. Objectivity enables automation. Gate failures should block progression. Blocking ensures issues are addressed. Common Gates Requirements gate ensures security requirements are defined. Requirements gate prevents building wrong thing. Design gate ensures architecture is reviewed. Design gate prevents architectural flaws. Code gate ensures SAST and SCA pass. Code gate prevents vulnerable code from merging. Test gate ensures security tests pass. Test gate validates security controls. Release gate ensures artifacts are signed and scanned. Release gate prevents vulnerable releases. Gate Automation Gates should be automated where possible. Automation ensures consistency. Manual gates should have clear criteria and approvers. Clarity prevents delays. Gate metrics should be tracked. Metrics show gate effectiveness.Policy-as-Code and Test-Driven Security
Policy-as-Code Security policies should be encoded as code. Code enables automation and version control. Open Policy Agent (OPA) and Cedar provide policy engines. Policy engines enable declarative policies. Policies should be enforced in CI/CD and runtime. Multi-stage enforcement provides defense-in-depth. Policy violations should block merges and deployments. Blocking ensures compliance. Policies should be tested. Testing validates policy correctness. Security Acceptance Tests Security requirements should be codified as tests. Tests provide executable specifications. Security tests should be automated. Automation enables continuous verification. Security tests should run in CI/CD. CI/CD integration provides fast feedback. Test coverage should be measured. Coverage ensures comprehensive testing. Abuse Case Regression Tests Abuse cases should be converted to regression tests. Regression tests prevent reintroduction. Abuse case tests should verify attacks are prevented. Tests validate mitigations. Abuse case tests should be maintained. Maintenance ensures continued protection.Exception and Risk Acceptance Management
Exception Process Security exceptions should require formal approval. Approval ensures appropriate authority. Exception thresholds should be defined by impact level. High-impact exceptions require higher authority. Exception approvers should be identified. Approvers should have appropriate expertise. Exception rationale should be documented. Documentation enables review. Compensating Controls Exceptions should require compensating controls. Compensating controls reduce risk. Compensating controls should be documented and verified. Verification ensures effectiveness. Compensating controls should be monitored. Monitoring detects control failures. Exception Expiration Exceptions should have expiration dates. Expiration forces periodic review. Exception renewal should require re-approval. Re-approval ensures continued appropriateness. Expired exceptions should be automatically flagged. Flagging ensures timely action.Secure SDLC Metrics
Security Test Coverage Security test coverage measures percentage of security requirements with tests. Coverage should increase over time. Test coverage should be tracked by requirement type. Type-specific coverage identifies gaps. Gate Pass/Fail Rates Gate pass rate measures percentage of attempts passing gate. Low pass rate indicates systemic issues. Gate fail rate by reason identifies common issues. Reason analysis drives improvement. Gate retry rate measures rework. High retry rate indicates unclear criteria. Defect Escape Rate Defect escape rate measures vulnerabilities found in production. Escape rate shows SDLC effectiveness. Defect escape rate by phase identifies where defects escape. Phase analysis drives process improvement. Defect escape rate should decrease over time. Decreasing rate shows improving process. Mean Time to Remediate Mean time to remediate (MTTR) measures time from vulnerability discovery to fix. MTTR should be measured by severity. MTTR should be tracked against SLAs. SLA compliance shows operational effectiveness. MTTR trends show improvement or degradation. Trends guide resource allocation. Security Debt Security debt measures known vulnerabilities not yet fixed. Debt should be tracked and prioritized. Security debt should have remediation plans. Plans ensure debt is addressed. Security debt should decrease over time. Increasing debt indicates unsustainable pace.Secure SDLC Maturity
Ad Hoc Security Ad hoc security has no defined process. Security is reactive. Security activities are inconsistent. Inconsistency creates gaps. Defined Process Defined process documents security activities. Documentation enables consistency. Security activities are repeatable. Repeatability improves quality. Measured Process Measured process tracks security metrics. Metrics enable data-driven decisions. Process effectiveness is measured. Measurement drives improvement. Optimized Process Optimized process continuously improves. Improvement is systematic. Automation maximizes efficiency. Automation scales security.Conclusion
Secure Software Development Lifecycle embeds security into every development phase through requirements, design, implementation, verification, release, and operations activities. Security engineers encode security as tests and policies, implement security gates, and measure effectiveness. Success requires security activities in each SDLC phase, automated security gates, policy-as-code and test-driven security, formal exception management with compensating controls, and metrics tracking coverage, gate pass rates, defect escape rate, and remediation time. Organizations that invest in secure SDLC make security an outcome of the development process.References
- BSIMM (Building Security In Maturity Model)
- OWASP SAMM (Software Assurance Maturity Model)
- NIST SP 800-64 Security Considerations in the System Development Life Cycle
- Microsoft Security Development Lifecycle (SDL)
- SAFECode Fundamental Practices for Secure Software Development