Secure development lifecycle (SDL)

The term comes from Microsoft's Security Development Lifecycle, which grew out of Bill Gates's Trustworthy Computing memo of January 2002 and the security pushes that followed; from 2004 it was mandatory for Microsoft products exposed to meaningful risk. Its core activities are still recognisable in every later model: security and privacy requirements with bug bars, threat modelling of the design, approved tools and compiler hardening flags, banning unsafe functions, static analysis, dynamic testing and fuzzing, a final security review before release and a documented incident response plan for shipped products.

Today the reference points are frameworks rather than a single vendor process. NIST SP 800-218, the Secure Software Development Framework (SSDF), is outcome-based and deliberately does not prescribe a lifecycle model; it organises practices into four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW) and Respond to Vulnerabilities (RV). PW.1.1, for example, asks for risk modelling such as threat modelling, attack modelling or attack surface mapping. OWASP SAMM and BSIMM are maturity models used to measure and plan an SDL programme, and IEC 62443-4-1 specifies secure product development requirements for industrial automation suppliers. In ISO/IEC 27001:2022, Annex A controls 8.25 Secure development life cycle, 8.28 Secure coding and 8.29 Security testing in development and acceptance cover the same ground from the management-system side.

In a modern CI/CD pipeline the activities become automated gates: secret scanning and SAST on each commit, software composition analysis and SBOM generation for third-party components, container and infrastructure-as-code scanning, DAST against a staging environment, signed build provenance (for example SLSA levels) and branch protection requiring peer review. The manual activities that automation cannot replace are threat modelling, security architecture review, penetration testing of high-risk features and triage of findings against a defined bug bar. A frequent failure mode is a pipeline full of scanners whose findings are never triaged, which produces evidence of activity rather than fewer vulnerabilities.

Regulation is turning the SDL from good practice into an obligation for product manufacturers. The EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires products with digital elements to meet the essential requirements in Annex I, including vulnerability handling processes and security updates for the support period; its reporting obligations for actively exploited vulnerabilities have applied since 11 September 2026, and the bulk of the obligations apply from 11 December 2027. The SDL differs from security by design in that security by design is the principle, while the SDL is the repeatable process and evidence trail that implements it.