Microsoft Security Development Lifecycle (SDL)

Security and privacy should never be an afterthought when developing secure software. A formal process must be in place to ensure the development team considers security and privacy at all points of the product's lifecycle. Microsoft's Security Development Lifecycle (SDL) embeds comprehensive security requirements, technology-specific tooling, and mandatory processes into the development and operation of all software products. All development teams at Microsoft must adhere to the SDL processes and requirements. This adherence results in more secure software with fewer and less severe vulnerabilities at a reduced development cost.

Microsoft SDL consists of seven components, including five core phases and two supporting security activities. The five core phases are requirements, design, implementation, verification, and release. Each of these phases contains mandatory checks and approvals to ensure all security and privacy requirements and best practices are properly addressed. The two supporting security activities, training and response, are conducted before and after the core phases respectively to ensure they're properly implemented, and software remains secure after deployment.

Training

All Microsoft employees are required to complete general security and privacy awareness training as well as specific training related to their role. New employees receive initial training upon hire, and annual refresher training is required throughout their employment at Microsoft.

Developers and engineers must also participate in role-specific training to keep them informed on security basics and recent trends in secure development. All full-time employees, interns, contingent staff, subcontractors, and third parties are also encouraged and provided with the opportunity to seek advanced security and privacy training.

Requirements

Every product, service, and feature Microsoft develops starts with clearly defined security and privacy requirements. These requirements form the foundation of secure applications and inform their design. Development teams define these requirements based on factors such as the type of data the product handles, known threats, best practices, regulations and industry requirements, and lessons learned from previous incidents. Once defined, the development team clearly documents and tracks the requirements.

Software development is a continuous process, meaning that the associated security and privacy requirements change throughout the product's lifecycle to reflect changes in functionality and the threat landscape.

Design

Once you define the security, privacy, and functional requirements, you can start designing the software. As part of the design process, create threat models to help identify, categorize, and rate potential threats according to risk. Maintain and update threat models throughout the lifecycle of each product as you make changes to the software.

The threat modeling process begins by defining the different components of a product and how they interact with each other in key functional scenarios, such as authentication. Create Data Flow Diagrams (DFDs) to visually represent key data flow interactions, data types, ports, and protocols used. Use DFDs to identify and prioritize threats for mitigation that you add to the product's security requirements.

Service teams use Microsoft's Threat Modeling Tool to create threat models, which enable the team to:

• Communicate about the security design of their systems
• Analyze security designs for potential security issues by using a proven methodology
• Suggest and manage mitigation for security issues

Before releasing any product, review all threat models for accuracy and completeness, including mitigation for unacceptable risks.

Implementation

Implementation begins with developers writing code according to the plan they created in the previous two phases. Microsoft provides developers with a suite of secure development tools to effectively implement all the security, privacy, and function requirements of the software they design. These tools include compilers, secure development environments, and built-in security checks.

Verification

Before releasing any written code, you need to complete several checks and approvals to verify that the code conforms to SDL, meets design requirements, and is free of coding errors. A manual review is conducted by a reviewer who isn't the engineer that developed the code. Separation of duties is an important control in this step to minimize the risk of code being written and released that leads to accidental or malicious harm.

You also need to run various automated checks that are built into the pipeline to analyze code during check-in and when builds are compiled. The security checks used at Microsoft fall into the following categories:

• Static code analysis: Analyzes source code for potential security flaws, including the presence of credentials in code.
• Binary analysis: Assesses vulnerabilities at the binary code level to confirm code is production ready.
• Credential and secret scanner: Identifies possible instances of credential and secret exposure in source code and configuration files.
• Encryption scanning: Validates encryption best practices in source code and code execution.
• Fuzz testing: Uses malformed and unexpected data to exercise APIs and parsers to check for vulnerabilities and validate error handling.
• Configuration validation: Analyzes the configuration of production systems against security standards and best practices.
• Component Governance (CG): Open-source software detection and checking of version, vulnerability, and legal obligations.

If the manual reviewer or automated tools find any issues with the code, they notify the submitter. The submitter must make the necessary changes before submitting the code for review again.

Additionally, both internal and external providers regularly conduct penetration tests on Microsoft online services. Penetration tests provide another means for discovering security flaws that other methods didn't detect. For more information about penetration testing at Microsoft, see Attack simulation in Microsoft 365.

Release

After passing all required security tests and reviews, builds aren't immediately released to all customers. The release process systematically and gradually releases builds to larger and larger groups, referred to as rings, in what is called a safe deployment process (SDP). The SDP rings can generally be defined as:

• Ring 0: The development team responsible for the service or feature
• Ring 1: All Microsoft employees
• Ring 2: Users outside of Microsoft who have configured their organization or specific users to be on the targeted release channel
• Ring 3: Worldwide standard release in sub-phases

Builds stay in each of these rings for an appropriate number of days with high load periods, except for Ring 3 since the build is appropriately tested for stability in the earlier rings.

Response

After release, all Microsoft services are extensively logged and monitored. A centralized proprietary near-real-time monitoring system identifies potential security incidents. For more information about security monitoring and security incident management at Microsoft, see Security monitoring overview and Microsoft security incident management.