微软 SDL 安全研发生命周期详解

1. SDL概览

开发安全软件时，安全和隐私从来都不应是事后才考虑的，必须制定一个正式的过程，以确保在产品生命周期的所有时间点都考虑安全和隐私。 Microsoft 的安全开发生命周期 (SDL) 将全面的安全要求、特定于技术的工具和必需流程嵌入到所有软件产品的开发和运营中。

微软 SDL 由上图七个部分组成（可简称 5 + 2 ），包括五个核心阶段（蓝色圆圈标注的中间5个阶段）和两个支持安全活动（黑色圆圈标注的两个端点）：

• 5个核心阶段：分别是要求、设计、实现、验证和发布。 每个阶段都包含强制性的检查和审批，以确保所有安全和隐私要求以及最佳做法得到妥善解决。
• 2个支持活动：即培训和响应。分别在核心阶段之前和之后进行，以确保它们得到正确实现，并且软件在部署后保持安全。

2. SDL的安全目标

• 降低产品或服务的安全漏洞率
• 降低可能发生的安全漏洞的严重程度
• 在产品研发阶段就消除潜在的安全风险
• 建立企业整体安全开发规范和流程
• 将安全开发规范固化在开发工具中
• 建立安全能力中心，快速响应安全事件

3. SDL安全能力提升路线图

3.1. PPDR安全自适应过程

PPDR是Prepare、Protect、Detect及Response的简称，具体如下：

• Prepare（评估）：现状调研
• Protect（保护）：保护体系建设
• Detect（检测）：检测和监控体系建设
• Response（响应）：应用响应体系建设

3.2. SDL能力提升路线

3.2.1. 第一阶段：研发安全现状调研及差距分析

SDL 评估旨在确定企业在开发过程中的安全和隐私需求, 分析任何差距, 并向企业提供建议。评估23项功能, 涵盖 SDL 中的17种实践。

3.2.2. 第二阶段：安全研发流程落地实施

微软的安全研发流程落地实施主要涉及如下五个关键点：

1. 根据企业安全能力差距分析，进行安全培训体系建设、知识库建设、合规支撑工具建设，安全团队建设
2. 应用安全架构评估、威胁建模：比如建立威胁消减知识库，帮忙安全SE做安全架构设计。
3. 自动化的安全功能点检查工具、自动化的发布过程，和安全工具自适应：比如CodeQL静态代码检查工具，可以自动检测开发者提交的PR，及时发现安全问题。
4. 自动化的Web漏洞设，检查工具引入和建Fuzz工具引入，内网渗透和KALI的引入
5. 建立快速应急响应团队、明确响应人员角色职责

若要详细了解以上五个关键落地指导，可参阅附件《微软SDL安全研发生命周期介绍》（访问密码：6277）

4. SDL具体内容

4.1. 培训

所有 Microsoft 员工都必须完成一般安全意识培训和适合其角色的特定培训。 初始安全意识培训在员工时提供给新员工，在 Microsoft 的整个工作期间都需要进行年度刷新培训。

开发人员和工程师还必须参与特定于角色的培训，让他们了解安全基础知识以及安全开发的最新趋势。 还鼓励和提供所有全职员工、实习生、特遣队工作人员、分包商和第三方的机会，以寻求高级安全和隐私培训。

涉及的培训内容主要如下图所示：

4.2. 要求

Microsoft 开发的每个产品、服务和功能都从明确定义的安全和隐私要求开始;它们是安全应用程序的基础，并告知其设计。 开发团队根据产品将处理的数据类型、已知威胁、最佳做法、法规和行业要求，以及从以前的事件中吸取的经验教训等因素来定义这些要求。 定义后，将明确定义、记录和跟踪要求。

软件开发是一个持续的过程，这意味着关联的安全和隐私要求在整个产品的生命周期中发生变化，以反映功能和威胁环境的变化。

4.3. 设计

定义安全性、隐私和功能要求后，软件的设计就可以开始。 作为设计过程的一部分，将创建威胁模型，以帮助根据风险识别、分类和对潜在威胁进行评分。 对软件进行更改时，必须在每个产品的生命周期内维护和更新威胁模型。

威胁建模过程首先定义产品的不同组件，以及它们如何在关键功能方案（如身份验证）中相互交互。 数据流图 (DFD) 创建，以直观地表示所用的关键数据流交互、数据类型、端口和协议。 DFD 用于识别和确定添加到产品安全要求的缓解威胁的优先级。

开发人员需要对所有威胁模型使用 Microsoft 的Threat Modeling Tool，这使团队能够：

• 沟通其系统的安全设计
• 使用经过验证的方法分析安全设计的潜在安全问题
• 建议和管理安全问题的缓解措施

在发布任何产品之前，将检查所有威胁模型的准确性和完整性，包括缓解不可接受的风险。

4.4. 实现

实现从开发人员根据前两个阶段创建的计划编写代码开始。 Microsoft 为开发人员提供了一套安全开发工具，以有效实现他们设计的软件的所有安全性、隐私性和功能要求。 这些工具包括编译器、安全开发环境和内置安全检查。

4.5. 验证

在发布任何书面代码之前，需要进行多次检查和批准，以验证代码是否符合 SDL、符合设计要求且没有编码错误。 SDL 要求手动评审由独立于开发代码的人员的审阅者进行。 职责分离是此步骤中的重要控制措施，可确保同一人无法编写和发布任何代码，从而导致潜在的意外或恶意伤害。

还需要进行各种自动检查，并内置于提交管道中，以便在签入期间和编译生成时分析代码。 Microsoft 使用的安全检查分为以下类别：

• 静态代码分析：分析源代码是否存在潜在的安全缺陷，包括代码中存在凭据。
• 二进制分析：在二进制代码级别评估漏洞，确认代码已准备就绪。
• 凭据和机密扫描程序：标识源代码和配置文件中可能的凭据和机密公开实例。
• 加密扫描：验证源代码和代码执行中的加密最佳做法。
• Fuzz测试：使用格式错误和意外数据来练习 API 和分析器，以检查漏洞并验证错误处理。
• 配置验证：根据安全标准和最佳做法分析生产系统的配置。
• 开源治理 ：开源软件检测和检查版本、漏洞和法律义务。

如果手动审阅者或自动化工具在代码中发现任何问题，则会通知提交者，并且在再次提交以供审阅之前，需要对其进行必要的更改。此外，内部和外部提供商定期对 Microsoft 联机服务进行渗透测试。

4.6. 发布

通过所有必需的安全测试和评审后，生成不会立即发布给所有客户。 在安全部署过程（ Safe Deployment Process，SDP）中，生成会系统地逐步发布到更大和更大的环。 SDP 环的定义如下：

• Ring 0：负责服务的开发团队
• Ring 1：所有 Microsoft 员工
• Ring 2：Microsoft 外部的用户已将其组织或特定用户配置为位于目标发布频道
• Ring 3：分阶段的全球标准版本

每个环中的内部版本保留在负载周期较高的适当天数内，但除Ring 3 外，因为已对早期环中的稳定性进行了适当的测试。

4.7. 响应

发布后会广泛记录和监视所有 Microsoft 服务，并使用集中专有近实时监视系统识别潜在的安全事件。

5. 参考

[1] Microsoft Security Development Lifecycle (SDL)
[2] Introduction to Microsoft Online Services security development and operation