Secure SDLC

What it is

Secure Software Development Lifecycle (Secure SDLC) is the practice of embedding security activities throughout every phase of software development — from requirements and design through coding, testing, release, and maintenance — rather than treating security as an afterthought applied after development is complete. Shift-left security refers to moving security testing earlier in the development pipeline, where vulnerabilities are cheaper and faster to fix (a vulnerability found in code review costs ~10x less to fix than one found in pen testing, and ~100x less than one found in production). The core automated scanning categories are: SAST (Static Application Security Testing) — analyses source code without executing it, identifying potential vulnerabilities like SQL injection, hardcoded secrets, and insecure API usage; DAST (Dynamic Application Security Testing) — tests the running application by sending HTTP requests that probe for vulnerabilities; and SCA (Software Composition Analysis) — identifies known vulnerabilities in third-party dependencies.

Threat modelling in design involves architects and developers systematically identifying threats during the design phase before code is written, when architectural changes are cheapest. The STRIDE framework (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) provides a structure for identifying threats against each component. Security champions are developers embedded in product teams who act as security advocates — they are trained in secure coding practices, own the team's security tooling, and are the first line of contact for security questions, enabling security to scale across many teams without requiring a security engineer on every team. Penetration testing (pen testing) is structured adversarial testing by specialist testers who attempt to find and exploit vulnerabilities using the same techniques as real attackers, providing assurance that automated tools have not missed exploitable vulnerabilities.

Why it exists

Traditional security gates — a pen test or security review before production release — catch vulnerabilities after weeks of development effort, creating expensive rework cycles and schedule pressure to ship insecure code anyway. Shift-left security catches vulnerabilities in minutes after a PR is opened, when the fix is a one-line code change rather than an architectural redesign. NIST research estimates that fixing a security vulnerability during the design phase costs $60–$200; during implementation, $500–$1,000; during testing, $5,000–$10,000; and post-release, $10,000–$100,000. The Microsoft Security Development Lifecycle (SDL) demonstrated in 2002 that consistent application of secure SDLC practices reduced security vulnerabilities in shipped software by 50–60%.

When to use

• All software development — a minimum Secure SDLC (SAST + SCA in CI/CD, basic security training for developers) is appropriate for all teams.
• Applications handling sensitive data or exposed to the internet — full Secure SDLC including threat modelling, DAST, and regular pen testing is required.
• Organisations targeting compliance with SOC 2, ISO 27001, or FedRAMP — all require documented secure development processes.

When not to use

• There are no appropriate exceptions. The maturity level scales with team size and risk profile, but the core practices (automated scanning, developer security training) apply universally.

Typical architecture

SECURE SDLC PHASES:

REQUIREMENTS:
  - Security requirements defined (auth, authorization,
    encryption, audit logging, data classification)
  - Abuse cases alongside use cases
  - Compliance requirements mapped to controls

DESIGN:
  - Threat modelling: STRIDE analysis of system DFDs
  - Security architecture review for new features
  - Security champion involved in design decisions
  - Mitigations documented for each identified threat

DEVELOPMENT:
  - Secure coding standards (OWASP Top 10 prevention)
  - Pre-commit hooks: secrets scanning (detect-secrets, gitleaks)
  - Code review security checklist (auth, input validation,
    error handling, logging, dependency versions)
  - Security champion reviews security-sensitive code

CI/CD PIPELINE GATES:
  PR opened:
  ├── SAST: CodeQL / Semgrep / Checkmarx
  │   Block on: high-severity findings (SQLi, XSS, SSRF)
  │   Warn on: medium findings
  ├── SCA: Snyk / Dependabot
  │   Block on: critical CVEs in dependencies
  ├── Secrets scan: detect-secrets
  │   Block on: any credentials detected in code
  └── License scan: fail on GPL in proprietary code

Pre-production:
  ├── DAST: OWASP ZAP / Burp Suite Enterprise
  │   Scan against staging environment
  ├── IaC scan: Checkov / Terraform Sentinel
  │   Block on: public S3 buckets, open security groups

TESTING:
  - Security test cases cover OWASP Top 10 scenarios
  - Integration tests include authorisation boundary tests
  - Pen test: annual (external) + pre-major-release

RELEASE:
  - Security sign-off for high-risk changes
  - SBOM generated and published
  - Runtime security monitoring (WAF, SIEM) updated

SECURITY CHAMPIONS PROGRAMME:
  - 1 champion per product team (volunteer developers)
  - Monthly security guild meeting (share findings)
  - Quarterly security training (new techniques, CVEs)
  - Priority access to AppSec team consultation
  - Gamification: bug bounty credit for internal findings

Pros and cons

Implementation notes

Start with the highest-value, lowest-friction controls: secrets scanning on git commits (gitleaks pre-commit hook) and SCA dependency scanning (Dependabot/Snyk) in CI are both low false-positive and catch common, critical vulnerabilities. Add SAST after tuning; do not start with SAST in block mode — start in report mode, suppress known false positives, and only block on high-confidence findings. For SAST tooling, consider GitHub Advanced Security (CodeQL) for GitHub-hosted repos — it is deeply integrated and provides good signal-to-noise. Semgrep with custom rules allows writing precise, application-specific rules that generic SAST tools miss.

For threat modelling, use a lightweight format that developers can produce themselves: data flow diagrams (DFDs) showing data stores, processes, and external entities, with trust boundaries drawn, then STRIDE applied to each crossing. Tools like Microsoft Threat Modeling Tool or draw.io with templates help. A 2-hour threat modelling session before implementation of a significant new feature consistently identifies 3–5 security issues that would otherwise reach production. The key output is a set of mitigations that become requirements, tracked like any other requirement.

Common failure modes

• SAST in warn-only mode forever: SAST that produces warnings but never blocks merges provides no enforcement; teams eventually learn to ignore the warnings.
• No false positive suppression process: SAST false positives that cannot be formally suppressed (with justification and review) lead developers to disable scans or route around them.
• Security reviews as a final gate only: Concentrated security review only at release creates bottlenecks, high rework cost, and pressure to approve insecure code to meet deadlines.
• No developer security training: SAST findings are meaningless to developers who don't understand why SQL injection is dangerous and how to fix it; training is a prerequisite for effective automated tooling.
• Pen test findings never remediated: Annual pen tests that produce reports that are filed and not acted on are pure compliance theatre rather than actual risk reduction.

Decision checklist

• Are SAST and SCA tools integrated into CI/CD with defined blocking thresholds?
• Is secrets scanning enforced on all code commits (pre-commit hook or CI gate)?
• Is threat modelling performed for new system components and significant features?
• Are security champions trained and active in each product team?
• Is DAST run against staging environment before production releases?
• Are pen test findings tracked and remediated with defined SLAs?

Example use cases

• Fintech startup maturing security: Team adds gitleaks pre-commit hooks (immediate wins — catches developer accidentally committing AWS keys), then Snyk SCA in CI blocking critical CVEs, then CodeQL SAST in warn mode for 1 month to suppress false positives, then CodeQL blocking on high-severity findings; total time: 4 weeks, no developer velocity impact.
• Enterprise new feature security: Payment processing feature triggers mandatory security champion review and 2-hour threat modelling session; STRIDE analysis identifies missing authorisation check on amount field (tampering threat); mitigation added as a requirement before implementation; vulnerability prevented before a single line of code is written.
• SOC 2 Type II certification: Auditors require evidence of secure SDLC; team provides: CI pipeline SAST scan history, Snyk dependency scan reports, threat model documents for core systems, annual pen test report with remediation tracking, developer security training completion records.

Related patterns

• Threat Modeling — Design-phase security analysis within Secure SDLC.
• Supply Chain Security — SCA and SBOM as part of Secure SDLC.
• CI/CD Pipelines — CI/CD pipeline where security gates are implemented.

Further reading

• OWASP DevSecOps Guideline
• Microsoft Security Development Lifecycle
• Semgrep: Custom SAST Rules