Secure Software Development Lifecycle

​

SDLC Phases and Security Activities

​

Requirements Phase

• Risk-driven requirements: Threat modeling and risk assessment outputs should directly inform security requirements, ensuring coverage of identified attack vectors
• Verifiable acceptance criteria: Each security requirement needs measurable acceptance criteria that enable automated or manual verification
• Prioritization parity: Security requirements must be prioritized alongside functional requirements to ensure appropriate resourcing and sprint allocation
• Abuse case documentation: Document how the system could be misused to systematically identify security requirements (see OWASP Abuse Case Cheat Sheet)
• Early compliance mapping: Identify applicable compliance frameworks (SOC 2, PCI DSS, HIPAA, GDPR) early to prevent late-stage surprises

​

Design Phase

• Architecture security reviews: Conduct reviews before implementation begins, focusing on trust boundaries, data flows, and authentication mechanisms
• Structured threat modeling: Use methodologies like STRIDE or PASTA to systematically identify threats and mitigations
• Abuse case integration: Design should explicitly prevent documented abuse cases with appropriate controls
• Compensating controls: For accepted risks, identify and document compensating controls that reduce residual risk to acceptable levels
• Security design patterns: Apply established patterns (defense in depth, least privilege, secure defaults) to prevent common vulnerability classes
• Architecture Decision Records: Document security trade-offs in ADRs to preserve decision rationale for future maintainers

​

Implementation Phase

• Paved roads: Provide secure-by-default frameworks that make the secure path the easy path
• Security linters: Run on every commit using tools like Semgrep, ESLint security plugins, or Bandit for Python
• Static Application Security Testing (SAST): Tools like SonarQube, Checkmarx, or CodeQL should block builds on high-severity findings
• Software Composition Analysis (SCA): Use Snyk, Dependabot, or OWASP Dependency-Check to identify vulnerable dependencies
• Security-focused code review: Train reviewers on common vulnerability patterns and enforce security checklists via PR templates
• Pre-commit hooks: Enable local security checks for fast feedback before code leaves the developer machine

​

Verification Phase

• Dynamic Application Security Testing (DAST): Tools like OWASP ZAP or Burp Suite test running applications for runtime vulnerabilities
• Interactive Application Security Testing (IAST): Combines SAST and DAST approaches with runtime instrumentation for improved accuracy and context
• Fuzzing: Use AFL, libFuzzer, or OSS-Fuzz to discover edge cases—prioritize coverage of parsers and input handlers
• Penetration testing: Engage skilled testers to simulate real attack scenarios, following methodologies like OWASP Testing Guide or PTES
• Policy enforcement: Validate compliance with security policies; violations should block deployment
• Negative testing: Verify security controls work by testing that unauthorized actions are properly denied
• Security acceptance tests: Automate verification of security requirements as executable specifications

​

Release Phase

1. Artifact signing: Sign all release artifacts using Sigstore or GPG to prove authenticity
2. Provenance verification: Verify artifacts originate from trusted builds using SLSA framework attestations
3. Security-inclusive change management: Require security review as part of change approval processes
4. Tested rollback plans: Validate rollback procedures before release to enable rapid recovery
5. Gradual deployment: Use canary releases or progressive rollouts with monitoring to limit blast radius

​

Operations Phase

• Security event detection: Implement logging and monitoring capable of detecting security events and anomalies
• Incident response readiness: Conduct regular drills to validate incident response procedures
• Vulnerability management: Track and remediate vulnerabilities according to severity-based SLAs (see NIST vulnerability management guidance)
• Post-incident learning: Incorporate lessons learned into processes, requirements, and tests to prevent recurrence
• Security metrics reporting: Track and report metrics demonstrating program effectiveness to stakeholders

​

Security Gates

​

Gate Design Principles

• Objective and measurable criteria: Gate criteria should be automatable where possible, removing subjectivity and enabling consistent enforcement
• Blocking on failure: Gate failures must block progression to ensure issues are addressed before they propagate downstream
• Clear escalation paths: Define how exceptions are handled when legitimate business needs conflict with gate criteria

​

Common Security Gates

​

Gate Automation

1. Automate objective checks: SAST, SCA, policy validation, and test execution should run automatically in CI/CD pipelines
2. Define clear manual criteria: For gates requiring human judgment, document specific criteria and designate qualified approvers
3. Track gate metrics: Monitor pass/fail rates, time-to-pass, and retry frequency to identify systemic issues

​

Policy-as-Code and Test-Driven Security

​

Policy-as-Code Implementation

• Policy engines: Use Open Policy Agent (OPA) with Rego or Cedar for declarative policy definition
• Multi-stage enforcement: Enforce policies in CI/CD (pre-deployment) and at runtime (admission controllers, service mesh) for defense-in-depth
• Blocking violations: Policy violations should block merges and deployments, not just generate warnings
• Policy testing: Policies are code—test them with unit tests covering expected allow/deny scenarios

# Example OPA policy: require resource limits on all containers
deny[msg] {
    input.kind == "Deployment"
    container := input.spec.template.spec.containers[_]
    not container.resources.limits
    msg := sprintf("Container '%v' missing resource limits", [container.name])
}

​

Security Acceptance Tests

• Codified requirements: Each security requirement should map to one or more automated tests
• CI/CD integration: Run security tests on every commit for fast feedback
• Coverage measurement: Track what percentage of security requirements have corresponding tests
• Continuous verification: Security tests should run not just at release, but continuously against production-like environments

​

Abuse Case Regression Tests

• Regression test conversion: Each documented abuse case should become a regression test that verifies the attack is prevented
• Mitigation validation: Tests should verify that identified mitigations actually prevent the abuse scenario
• Ongoing maintenance: Maintain abuse case tests as the system evolves to ensure continued protection

​

Exception and Risk Acceptance Management

​

Exception Process Requirements

• Formal approval workflow: Exceptions require documented approval from stakeholders with appropriate authority
• Impact-based thresholds: Higher-impact exceptions require higher-level approval
• Designated approvers: Pre-identify who can approve exceptions at each threshold level
• Documented rationale: Record the business justification and risk analysis enabling future review

​

Compensating Controls

• Mandatory compensating controls: Each exception should identify controls that reduce the risk to an acceptable level
• Documentation and verification: Document what compensating controls are in place and verify they function as intended
• Continuous monitoring: Monitor compensating controls to detect failures that would expose the accepted risk

​

Exception Expiration

• Mandatory expiration dates: All exceptions must have defined expiration dates forcing periodic review
• Re-approval requirements: Renewal requires fresh approval, not automatic extension
• Automated flagging: Systems should automatically flag expired exceptions and alert responsible parties

​

Secure SDLC Metrics

​

Key Metrics Dashboard

​

Security Test Coverage

• Coverage measurement: Track what percentage of documented security requirements have corresponding automated tests
• Type-specific tracking: Break down coverage by requirement type (authentication, authorization, encryption, etc.) to identify gaps
• Trend monitoring: Coverage should increase over time as the security test suite matures

​

Gate Pass/Fail Rates

• First-pass rate: Measures development team security awareness—low rates indicate training needs
• Failure analysis: Categorize failures by root cause to identify systemic issues worth addressing
• Retry rate: High retry rates suggest unclear gate criteria or tooling issues

​

Defect Escape Rate

• Production vulnerability tracking: Count vulnerabilities discovered in production that should have been caught earlier
• Phase attribution: Identify which phase should have caught each escaped defect to target process improvements
• Trend analysis: Escape rate should decrease over time as processes mature

​

Mean Time to Remediate (MTTR)

• Severity-stratified measurement: Track MTTR separately for critical, high, medium, and low severity findings
• SLA compliance: Compare actual MTTR against defined SLAs to measure operational effectiveness
• Trend analysis: Increasing MTTR trends indicate capacity or process issues requiring attention

​

Security Debt

• Debt quantification: Track known vulnerabilities awaiting remediation, weighted by severity and age
• Remediation planning: Each debt item should have an assigned owner and remediation plan
• Sustainability monitoring: Consistently increasing security debt indicates unsustainable development pace

​

Secure SDLC Maturity Model

​

Progression Indicators

1. Ad Hoc → Defined: Document security activities, implement basic security gates, train development teams
2. Defined → Measured: Implement metrics collection, establish baselines, create security dashboards
3. Measured → Optimized: Use data to drive improvement, maximize automation, implement predictive analytics

​

Conclusion

• Security activities integrated into each SDLC phase with clear ownership
• Automated security gates with objective, measurable criteria
• Policy-as-code and test-driven security for consistent enforcement
• Formal exception management with compensating controls and expiration dates
• Metrics tracking coverage, gate performance, escape rates, and remediation times

​

References

• BSIMM (Building Security In Maturity Model) - Industry benchmark for software security initiatives
• OWASP SAMM (Software Assurance Maturity Model) - Open framework for building security into development
• NIST SP 800-64: Security Considerations in the System Development Life Cycle - Federal guidance on integrating security into SDLC
• Microsoft Security Development Lifecycle (SDL) - Microsoft’s security development practices
• SAFECode Fundamental Practices for Secure Software Development - Industry consortium guidance
• CWE Top 25 Most Dangerous Software Weaknesses - Common vulnerability reference for requirements and testing