Security development and operations overview
How does Microsoft implement secure development practices?
Microsoft's Security Development Lifecycle (SDL) is a security assurance process focused on developing and operating secure software. The SDL provides detailed, measurable security requirements for developers and engineers at Microsoft to reduce the number and severity of vulnerabilities in our products and services. All Microsoft software development teams must follow SDL requirements, and we continuously update the SDL to reflect the changing threat landscape, industry best practices, and regulatory standards for compliance.
How does Microsoft's SDL improve application security?
The SDL process at Microsoft can be thought of in terms of five phases of development: requirements, design, implementation, verification, and release. It begins by defining software requirements with security in mind. We ask security-relevant questions about what the application must accomplish. For example, does the application need to collect sensitive data? Will the application perform sensitive or important tasks? Does the application need to accept input from untrusted sources?
Once relevant security requirements have been identified, we design our software to incorporate security features that meet these requirements. Our developers implement SDL and design requirements in the code, which we verify through manual code review, automated security tooling, and penetration testing. Finally, before code can be released, new features and material changes undergo final security and privacy review to ensure all requirements are met.
For more information on the SDL, please read Microsoft Security Development Lifecycle.
How does Microsoft test source code for common vulnerabilities?
To support our developers in implementing security requirements during code development and after release, Microsoft provides a suite of secure development tools to automatically check source code for security flaws and vulnerabilities. Microsoft defines and publishes a list of approved tools for our developers to use, such as compilers and development environments, along with the built-in security checks that execute automatically within Microsoft build pipelines.
Before code can be checked into a release branch, the SDL requires manual code review by a separate reviewer. Code reviewers check for coding errors and verify that code changes meet SDL and design requirements, pass functional and security tests, and perform reliably. They also review associated documentation, configs, and dependencies to ensure code changes are documented appropriately and will not cause unintended side-effects. If a reviewer finds problems during code review, they can ask the submitter to resubmit the code with suggested changes and additional testing. Code reviewers may also decide to block check-in entirely for code that does not meet requirements. Once the code has been deemed satisfactory by the reviewer, the reviewer provides approval, which is required before code can proceed to the next deployment phase.
In addition to secure development tools and manual code review, Microsoft enforces SDL requirements using automated security tooling. Many of these tools are built into the commit pipeline and automatically analyze code for security flaws as it is checked in and as new builds are compiled. Examples include static code analysis for common security flaws and credential scanners that analyze code for embedded secrets. Issues uncovered by automated security tools must be fixed before new builds can pass security review and be approved for release.
How does Microsoft manage open-source software?
Microsoft has adopted a high-level strategy for managing open-source security, which uses tools and workflows designed to:
- Understand which open-source components are being used in our products and services.
- Track where and how those components are used.
- Determine whether those components have any vulnerabilities.
- Respond properly when vulnerabilities are discovered that affect those components.
Microsoft engineering teams maintain responsibility for the security of all open-source software included in a product or service. To achieve this security at scale, Microsoft has built essential capabilities into engineering systems through Component Governance (CG), which automates open-source detection, legal requirement workflows, and alerting for vulnerable components. Automated CG tools scan builds at Microsoft for open-source components and associated security vulnerabilities or legal obligations. Discovered components are registered and submitted to the appropriate teams for business and security reviews. These reviews are designed to evaluate any legal obligations or security vulnerabilities associated with open-source components and resolve them before approving components for deployment.
Related external regulations & certifications
Microsoft's online services are regularly audited for compliance with external regulations and certifications. Refer to the following table for validation of controls related to security development and operation.
Azure and Dynamics 365
| External audits | Section | Latest report date |
|---|---|---|
| ISO 27001 Statement of Applicability Certificate |
A.12.1.2: Change management controls A.14.2: Security in development and support processes |
April 8, 2024 |
| ISO 27017 Statement of Applicability Certificate |
A.12.1.2: Change management controls A.14.2: Security in development and support processes |
April 8, 2024 |
| SOC 1 SOC 2 SOC 3 |
SDL-1: Security Development Lifecycle (SDL) methodology SDL-2: Security control requirements documented in releases SDL-4: Segregation of test and production environments SDL-6: Malware scans on source code builds SDL7: Semi-annual SDL review |
May 20, 2024 |
Microsoft 365
| External audits | Section | Latest report date |
|---|---|---|
| FedRAMP | SA-3: System Development Life Cycle | August 21, 2024 |
| ISO 27001/27017 Statement of Applicability Certification (27001) Certification (27017) |
A.12.1.2: Change management controls A.14.2: Security in development and support processes |
March 2024 |
| SOC 1 SOC 2 |
CA-03: Risk management CA-18: Change management CA-19: Change monitoring CA-21: Change testing CA-38: Baseline configurations CA-46: Security review |
August 1, 2024 |