|

As a company-wide initiative and a mandatory policy at Microsoft since 2004, the SDL has played a critical role in embedding security and privacy in Microsoft’s culture and software. The SDL has proven to be effective at reducing vulnerability counts of flagship Microsoft products after release.

Microsoft is committed to protecting customers and enabling a more trusted computing experience. One of the ways to reach this goal is by sharing security and privacy expertise, guidance, technology, and processes. 

Some of our publicly available SDL process documentation is available to the development community under the Attribution, Non-Commercial, Share Alike (cc by-nc-sa) terms of the Creative Commons license—which allows organizations to copy, distribute, and transmit the documentation to others. This allows organizations to incorporate content from the SDL documents released under Creative Commons into their internal process documentation.

Cybercrime poses a significant threat to every organization, large or small. By adopting the Microsoft SDL in their development processes, organizations will be better able to reduce risk and improve trust by making software inherently more secure and better at protecting sensitive information.
 
 
 
 
Customers now demand highly secure products and services out-of-the box. And with today’s complex threat and regulatory landscape, it’s important that security and compliance is top of mind for everyone in the organization. However, delivering on customers’ expectations and regulatory requirements is almost impossible without a standardized approach. 
 
By introducing standardized security and compliance considerations throughout all phases of the development process, developers can help reduce the likelihood of vulnerabilities in products and services and avoid repeating the same security mistakes. Similarly, security integration throughout the operations lifecycle will assist in maintaining the integrity of those products and services. These Operational Security practices should align with the development processes. This will result in less time—and therefore cost—being spent on triage and response after the fact, and provide your customers with assurance that your products are highly secure.

Yes. The SDL is composed of proven security practices that work in development organizations regardless of their size or platform.

|

The core concepts and individual security activities of the Microsoft SDL that should be performed by development organizations are described in the Simplified Implementation of the Microsoft SDL white paper:

  • Provide Training
  • Define Security Requirements
  • Define Security Quality Bars and KPIs
  • Use Threat Modeling
  • Establish Design Requirements
  • Encrypt Data Everywhere
  • Use Secure 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 for Your Organization


Microsoft makes SDL training resources, templates for SDL practices, and SDL tools available on the Microsoft SDL Resources page to help perform the security activities of the Microsoft SDL process. If you have any questions related to the SDL process or SDL tools, visit the SDL forum.

Microsoft Services offers training, consulting, and tools and services designed to help organizations adopt the SDL process and make security and privacy an integral part of their software development.  

No. The Microsoft SDL Process Guidance illustrates the way Microsoft applies the SDL to its own technologies and software. You should download and use the Simplified Implementation of the Microsoft SDL white paper which provides clear guidance on the twelve security practices to support secure development. Each organization being unique, it is important that you determine your own security requirements and which tools are appropriate for your organization.