Microsoft Security Development Lifecycle Practices This is the Trace Id: 8fafc648eb5e558447f0e6890ff4ae1a
User looking at his computer

Security Development Lifecycle (SDL) Practices

It’s been 20 years since we introduced the Microsoft Security Development Lifecycle (SDL)—a set of practices and tools that help developers build more secure software. While the goal has not changed, the cyber security landscape on how software and services are built and deployed has. 

Learn about the practices of the SDL, and how to implement them in your organization.

 

These are the 10 key security practices of the SDL that help you integrate security into each stage of your overall development process. These practices will be updated as the SDL, learnings, best practices, and tooling evolve.  

sdl lifecycle graphic

Security risks (and the need to mitigate them) can occur at any point in the development lifecycle:

  • Design – ensure that the design doesn’t naturally allow attackers to easily gain unauthorized access to the workload, its data, or other business assets in the organization.
  • Code – ensure that writing (and re-use) of code doesn’t allow attackers to easily take control of the application to perform unauthorized actions that harm customers, employees, systems, data, or other business assets. Developers should also work in a secure environment that doesn’t allow attackers to do this without their knowledge.
  • Build and Deploy – ensure that the continuous integration and continuous deployment (CI/CD) processes don’t allow unauthorized users to alter the code and allow attackers to compromise it.
  • Run – ensure that environment running the code (cloud, servers, mobile devices, others) follows security best practices across people, process, and technology to avoid attackers compromising and abusing the workload. This includes the adoption of well-established best practices, security baseline configurations, and more.
  • Zero Trust architecture and governance – All of these stages should follow Zero Trust principles to assume breach (assume compromise), explicitly verify trust, and grant the least privilege required for each user account, machine/service identity, and application component.