Security and privacy should never be an afterthought when developing software. A formal process must become standard practice to ensure they are considered at all points of the product's lifecycle. The rise of software supply chain attacks—including the XZ Utils, SolarWinds attack and Log4j vulnerabilities—highlights the critical need to build security into the software development process, from the ground up.
Over the last 20 years, there have been many improvements to the security development lifecycle (SDL) reflecting changes in internal tools and processes. We are excited to announce that this week, we have updated the security practices on the SDL website, and we will continue to update this site with new information on a regular basis.
Microsoft Security Development Lifecycle (SDL) Timeline
Figure 1: Graphic of the SDL Timeline
In the early 2000s, personal computers (PCs) were becoming increasingly common in the home and the internet was gaining more widespread use. This led to a rise in malicious software looking to take advantage of users connecting their home PCs to the internet. It quickly became evident that protecting users from malicious software required a fundamentally different approach to security.
In January 2002, Microsoft launched its Trustworthy Computing initiative to help ensure Microsoft products and services were built to be inherently highly secure, available, reliable, and with business integrity.
In 2004, the Microsoft Security Development Lifecycle (SDL) was born out of the Trustworthy Computing initiative and introduced security throughout all phases of software development at Microsoft. The SDL began life to bake security and privacy principles into the culture of Microsoft. It originally consisted of a relatively small set of requirements aligned to each phase of the waterfall model of software development, aimed at preventing developers from inadvertently introducing vulnerabilities into their code. It also included a few supporting tools that could identify what was, at the time, a short list of known issues. Back then, the SDL was updated annually. Products were released every two to three years and a final security review to confirm that best practices had been followed was a great advancement from existing approaches.
We no longer live in a world where software releases are months or even years apart. The cloud and continuous integration/continuous deployment (CI/CD) practices, enable services to be shipped daily or sometimes multiple times a day. The software supply chain has grown more complicated as more dependencies on open-source software are created. And while the SDL has continued to evolve to keep up with these changes and the shifting threat landscape, it has also grown more complex.
SDL Now
Secure software development still requires embedding security into each step of the development process, from the design and build stages to deployment and operations(run). The SDL now continuously measures security throughout the development lifecycle. SDL continues to evolve with the changing landscape of cloud computing, AI, and CI/CD automation. As seen in the image below, security controls are integrated to ensure continuous enforcement of zero trust principles and governance from Design stage all the way to Run.
Figure 2: A more modern SDL lifecycle
The image below shows key security capabilities in each of the stages of the development lifecycle.
Figure 3: Key capabilities during each stage of the SDL cycle
The SDL is the approach Microsoft uses to integrate security into DevOps processes (sometimes called a DevSecOps approach). You can use this SDL guidance and documentation to adapt this approach and practices to your organization.
The practices described in the SDL approach can be applied to all types of software development and all platforms from classic waterfall through to modern DevOps approaches and can be generally applied across:
- Software – whether you are developing software code for firmware, AI applications, operating systems, drivers, IoT Devices, mobile device apps, web services, plug-ins or applets, hardware microcode, low-code/no-code apps, or other software formats. Note that most practices in the SDL are applicable to secure computer hardware development as well.
- Platforms – whether the software is running on a ‘serverless’ platform approach, on an on-premises server, a mobile device, a cloud hosted VM, a user endpoint, as part of a Software as a Service (SaaS) application, a cloud edge device, an IoT device, or anywhere else.
The SDL recommends 10 security practices to incorporate into your development workflows. Applying the 10 security practices of SDL is an ongoing process of improvement so a key recommendation is to begin from some point and keep enhancing as you proceed. This continuous process involves changes to culture, strategy, processes, and technical controls as you embed security skills and practices into DevOps workflows.
Next steps
Head over to the SDL site and start adapting the SDL guidance and practices to your organization.
