通过设计了解安全和隐私
Microsoft SDL 从设计入手，强调安全和隐私的重要性。 安全和隐私功能不应是附加组件，而应是我们产品和服务的核心组件。 我们通过在功能生命周期的早期定义安全要求、为所有主要服务组件和功能维护最新威胁模型，以及要求对所有源代码进行手动代码审查，在我们的产品中构建安全性。
安全和隐私要求
安全和隐私要求应提供所有高安全性应用程序和系统的设计信息。 在 Microsoft，我们在开发每个产品、服务和功能时，都从明确定义的安全和隐私要求开始。 由于软件开发是一个持续的过程，因此我们会在产品的整个生命周期中不断更新这些要求，以反映所需功能和威胁形势的变化。 影响安全和隐私要求的因素包括正在开发的软件的性质、已知的安全威胁、从安全事件中吸取的教训、法律和行业要求以及内部标准和编码实践。
定义安全和隐私要求的最佳时间是在产品或功能的初始设计和规划阶段。 这样，开发团队就可以将安全功能集成到产品的核心功能中。 例如，我们会在每个产品的设计阶段询问一个问题：该产品是否会处理客户数据等敏感信息？ Microsoft 的 SDL 包括安全和隐私要求，可帮助开发人员实施敏感数据处理的最佳实践，并确保我们的软件按照相关要求安全地收集、处理和存储敏感数据。 SDL 对敏感数据处理的要求包括加密、日志记录和事件响应准备，以保护敏感数据，并为 Microsoft 安全响应团队提供调查和响应潜在安全事件所需的审核功能。
威胁模型和数据流图 (DFD)
一旦产品的设计包含明确定义的安全和隐私要求，开发团队就会构建威胁模型来可视化最有可能影响产品的安全和隐私威胁。 威胁建模有助于根据风险识别、分类和评估潜在威胁，使开发人员可以提出和实施适当的缓解措施。 SDL 要求 Microsoft 的开发团队维护最新的威胁模型和数据流关系图， (DFD) 所有主要服务组件和功能。
威胁建模首先要定义产品或功能的组件，并针对关键功能场景（例如身份验证或敏感数据处理）绘制它们之间的关系。 威胁建模图包括相关的数据流、功能和流程，以帮助可视化对服务的威胁。 作为威胁建模流程的一部分，服务团队会创建和维护 DFD，即记录服务组件或功能使用的所有数据流、端口和协议。
使用完整的图表来识别对系统的威胁并确定缓解威胁的优先级。 开发团队针对其威胁模型暴露的风险提出并实施缓解措施。 新的缓解措施被添加到产品的安全要求中，在手动代码审查和自动测试期间在代码中验证，并作为发布前审批流程的一部分进行审查。
由于使用敏捷功能的新式软件开发注重向客户快速交付功能，因此威胁建模是一个持续的过程。 为确保开发团队之间的一致性并帮助保持威胁模型的最新状态，Microsoft 要求其开发人员对所有威胁模型使用 Microsoft 的威胁建模工具。 威胁建模工具使 Microsoft 的任何开发人员或软件架构师能够：
- 就系统的安全设计进行沟通。
- 使用经过验证的方法分析针对潜在安全问题的安全设计。
- 建议和管理安全问题的缓解措施。
在发布前的安全审查期间，将对所有威胁模型的准确性和完整性（包括对不可接受风险的缓解措施）进行审查。 这些审查维护问责制并鼓励面向安全的设计。
手动代码审查
我们的开发团队使用 Azure DevOps Git 对所有新代码存储库进行版本控制。 为了验证在 Microsoft 开发的所有代码均符合 SDL 和设计要求，SDL 需要由单独的审查人员手动审查代码，然后才能将代码更改签入版本分支。 代码审查员会检查编码错误并验证代码更改是否满足 SDL 和设计要求、通过功能和安全测试并可靠地执行。 他们还会审查相关的文档、配置和依赖项，以确保正确记录代码更改并且不会导致意外的副作用。
如果审查者在代码审查期间发现问题，他们可以要求提交者在进行建议更改和额外测试后重新提交代码。 代码审查者也可能决定完全阻止不符合要求的代码签入。 对提交以供发布的代码的所有更改都必须明确归因于单个开发人员，并由单独的审查员审查以便问责。 此外，必须记录对发布代码的所有更改并保留至少 18 个月，以提供所有代码更改的可审计记录，以及更改的创建者、业务理由、测试结果和批准更改的审阅者。