What is the Microsoft Security Development Lifecycle (SDL), and what are its 12 practices?
A set of security practices Microsoft established in 2004 to improve the security of its products, with threat modelling as the core practice and a supporting tool suite. The classic list has 12 practices.
- Provide training
- Define security requirements
- Define metrics and compliance reporting
- Perform threat modelling (the core practice)
- Establish design requirements
- Define and use cryptography standards
- Manage the security risk of using third-party components
- Use approved tools
- Perform static analysis security testing (SAST)
- Perform dynamic analysis security testing (DAST)
- Perform penetration testing
- Establish a standard incident response process
The SDL grew out of Microsoft's "perfect storm" of worms around 2001 to 2003, such as Code Red, Nimda and Blaster, and Bill Gates's Trustworthy Computing memo. Mapped onto the product lifecycle, it covers the development loop well. Of the post-launch loop it covers only incident response, so vulnerability management, monitoring and end of life need other standards.
The 12 practices are the classic SDL. Microsoft's current SDL page regroups the work into 10 practices, adding for example "secure the software supply chain" and "secure the engineering environment". The core, threat modelling and security testing, is unchanged.
Go deeper:
Microsoft — Security Development Lifecycle — the current SDL with its practices and tools- Microsoft Security Development Lifecycle (Wikipedia) — history and versions
- Trustworthy computing (Wikipedia) — the 2002 initiative the SDL grew out of