Secure development lifecycle (SDL)
Also known as: secure software development lifecycle, SSDLC, security development lifecycle
A fixed set of security steps built into every stage of making software, from planning and design through testing to release.
Draft - this entry has not been reviewed yet.
Formal
A development process that adds set security activities to each phase - security requirements at planning, threat modelling at design, secure coding rules and code review while building, security testing before release, and a plan for handling flaws found afterwards.
In plain English
Like the checks a new building must pass at each stage - drawings approved, foundation inspected, wiring tested - instead of one inspection when it is already finished.
In practice
A software house building a case system for a ministry will not hand over a new version until the design has a threat model, the code has passed review and automatic scans, and a tester has signed off; flaws found later follow a set fix-and-notify routine.
Why it matters
Security that depends on each developer remembering it is uneven; fixed steps in the process mean fewer flaws reach customers, and give buyers something concrete to check against.
How to put it into practice
The usual steps, in order. Adapt them to your organisation.
- Write an SDL policy that names the required security activities in each phase, who is responsible for them, and a bug bar that sets which flaws block a release.
- Train developers in secure coding and threat modelling, and give them approved tools, libraries and secure coding standards.
- At planning, record security and privacy requirements for each feature, and threat model every new or changed design.
- While building, require peer code review and run secret scanning, SAST and software composition analysis on every commit or pull request.
- Before release, run security tests such as DAST, fuzzing or a penetration test of high-risk features, and hold a final security review against the bug bar.
- Protect the pipeline and the builds with branch protection, signed builds and an SBOM for each release.
- After release, run a vulnerability disclosure and response process that triages reports, ships fixes and informs customers.
- Measure the programme with a maturity model such as OWASP SAMM, and improve it at least once a year.
Common pitfalls
- Filling the pipeline with scanners whose findings are never triaged, which produces evidence of activity rather than fewer vulnerabilities.
- Skipping threat modelling because tools cannot automate it, although design flaws are the most expensive to fix later.
- Treating the SDL as a single gate run by the security team at the end, instead of steps built into every phase.
Good guides
- NIST SP 800-218 - Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities(opens in a new tab) · NIST
- OWASP SAMM - The Model(opens in a new tab) · OWASP
- Threat Modeling - OWASP Cheat Sheet Series(opens in a new tab) · OWASP
- Microsoft Security Development Lifecycle (SDL)(opens in a new tab) · Microsoft
Technical deep dive
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.
Relationships
- Consists of
- Threat modelling
- Implements
- Security by design
- Mitigates
- Vulnerability
Sources & further reading
Standards & official texts
Official documentation
- Microsoft Security Development Lifecycle (SDL) · Microsoft
Where this data comes from
This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.
See the review queueSuggest a correction on GitHubThis term as JSON
Check yourself
Loading…