摘要： 本文介绍可信赖计算安全开发生命周期(或 SDL)，即 Microsoft 在开发需要抵御恶意攻击的软件时采用的一套流程。 该流程在 Microsoft 软件开发流程的每个阶段添加了一系列关注安全性的活动和交付结果。 这些活动和交付结果包括在软件设计过程中开发威胁模型、在实施过程中使用静态分析代码扫描工具以及在集中进行的“安全推动”过程中进行代码审核和安全测试。 应用 SDL 的软件在发布之前，必须由独立于开发小组的另一个小组执行最终安全审核。 与未应用 SDL 的软件相比，应用了 SDL 的软件从外部发现其安全漏洞的机率显著降低。 本文介绍 SDL 并讨论了在 Microsoft 软件开发过程中实施该流程的经验。

　　1. 简介

　　所有软件供应商都有必要解决安全威胁方面的问题。 对软件供应商来说，安全性是其核心要求，这是由市场力量所驱动，也是由保护关键基础结构及建立和保持计算的广泛信任的需要所决定的。 所有软件供应商面对的一个主要挑战就是创建更加安全的软件，使其不需要频繁地通过修补程序进行更新，且需要进行的安全管理工作也更少。

　　对于软件行业来说，要满足当今提升安全性的需要，关键在于实施可重复的流程，通过这些流程可靠地实现可测量的安全性提升。 因此，软件供应商必须转为采用一种更严格的、更加关注安全性的软件开发流程。 这种流程旨在尽量减少设计、编码和文档编写过程中存在的漏洞，并在开发生命周期中尽可能早地检测到并消除这些漏洞。 用于处理来自 Internet 的输入、控制可能被攻击的关键系统或处理个人身份信息的企业和消费者软件最需要实施这种流程。

　　构建更安全的软件可从三个方面着手：可重复的流程、工程师教育以及度量标准和可测量性。 本文档重点介绍 SDL 的可重复流程方面，虽然也讨论了工程师教育并提供了反映目前部分应用 SDL 的影响的一些总体指标。

　　如果参照 Microsoft 的经验，其他组织采用 SDL 应该不会为软件开发增加不合理的成本。 根据 Microsoft 的经验，提供更安全的软件的益处(例如，更少的补丁和更加满意的用户)超过付出的代价。

　　SDL 会集成一些有助于提升软件安全性的措施，在此过程中可能需要对软件开发组织的流程进行调整。 本文档概述了这些措施，并说明了将其集成到典型的软件开发生命周期中的方法。 进行这些调整的目的不是要完全改变开发流程，而是在开发流程中加入一些精心定义的安全检查点和安全性交付结果。

　　本文假定公司(或软件开发组织)中存在一个中央小组，该小组致力于推动最佳安全做法的制订与改进和流程优化，为整个组织提供专家意见，并在软件发布前对其进行审核(最终安全审核或 FSR)。 根据 Microsoft 的经验，设立这样一个组织对成功实施 SDL 和提升软件安全性十分重要。 可能有些组织会考虑由承包商或顾问担任“中央安全小组”角色。 本文介绍如何将旨在提升软件安全性的一系列步骤集成到大型软件开发组织通常使用的软件开发流程中。 Microsoft 设计并实施了这些步骤，作为其可信赖计算计划的一部分。 这些流程改进的目标是减少用户使用的软件中安全漏洞的数量并降低安全漏洞的严重程度。 在本文中，这种经过调整的软件开发流程，即当前在 Microsoft 实施的流程被称为可信赖计算软件开发生命周期(或简称为 SDL)。

　　Microsoft 的经验是在软件设计和开发过程中必须经常与安全小组进行互动，并必须与其共享敏感的技术和商业信息。 由于以上原因，最好的解决方案是在软件开发组织内部建立一个安全小组(虽然可能有必要请顾问人员帮助建立小组和培训小组的成员)。

　　1.1 基本流程

　　在 Microsoft 普遍采用的软件开发流程大致如图 1 所示。 从更高层面上看，这也是行业内的典型流程。

　　尽管图 1 显示了五个里程碑，看起来开发流程好像是“瀑布式”的，实际上该流程是螺旋形的。 为了对市场需求的变化和软件实施中遇到的实际情况做出反应，在实施阶段可能经常需要重新考虑需求和设计问题。 并且，该开发流程强调在几乎每个点都要提供运行代码，这样每个主要里程碑实际上分解为交付一系列构件，从而可以不断向前地测试和操作使用这些构件(由开发小组进行)。

　　1.2 安全开发生命周期概述

　　现实世界中的软件安全性方面的经验已经为构建更安全的软件建立了一套高标准的原则。 Microsoft 将这些原则称作 SD3+C – 设计安全、默认安全、部署安全和通信。 这些原则的简要定义如下：

　　•设计安全：在架构、设计和实现软件时，应使它在运行时能保护自身及其处理的信息，并能抵御攻击。

　　•默认安全：在现实世界中，软件达不到绝对安全，所以设计者应假定其存在安全缺陷。 为了使攻击者针对这些缺陷发起攻击时造成的损失最小，软件在默认状态下应具有较高的安全性。 例如，软件应在最低的必要权限下运行，非广泛需要的服务和功能在默认情况下应被禁用或仅可由少数用户访问。

　　•部署安全：软件应该随附工具和指导以帮助最终用户和/或管理员安全地使用它。 此外，更新应该易于部署。

　　•通信：软件开发者应为产品漏洞的发现做好准备并坦诚负责地与最终用户和/或管理员进行通信，以帮助他们采取保护措施(如打补丁或部署变通办法)。

　　尽管 SD3+C 的每个要素均对开发流程提出了要求，但前两个要素(设计安全和默认安全)对提升安全性的作用最大。 设计安全改进流程以防止在第一阶段引入漏洞，默认安全则要求软件默认状态下暴露的地方，即“攻击面”达到最小。

　　在现有开发流程中引入旨在集成 SD3+C 方法的安全措施后形成的总体流程结构如图2 所示。

　　本文的第 2 节从更高层面介绍了 SDL 的各个组件。 第 3 节简要概述了 Microsoft 实施 SDL 的特定情况。 本文第 4 节提供了一些说明性的数据，展示了在 Microsoft Windows Server 2003 和其他软件开发过程中对 SDL 的早期应用在减少安全漏洞数和严重性等级方面(与之前的软件版本相比)起到的作用。 第 5 节根据 Microsoft 应用 SDL 的经验对流程各要素进行了定性讨论。 最后，第 6 节进行了总结。

　　2. 安全开发生命周期流程

　　如前所述，工程师教育已超出本文的讨论范围。 但是必须认识到教育计划对 SDL 的成功实施至关重要。 计算机科学和相关专业的大学应届毕业生一般缺乏必要的培训，不能立即加入工作队伍从事安全软件的设计、开发或测试工作。 即使是学了安全课程的人员，他们可能对加密算法或访问控制模型接触较多，但是对缓冲区溢出或规范化缺陷可能了解不多。 一般情况下，行业内的软件设计者、工程师和测试人员也缺乏适当的安全技术知识。

　　在这些情况下，准备开发安全软件的组织必须负责对其工程人员进行适当教育。 根据组织的规模和可用的资源，应付这种挑战的方法可能会有所不同。 拥有大批工程人员的组织可建立一个内部计划对其工程师进行在职安全培训，而小型组织则可能需要依赖外部培训。 在 Microsoft，所有从事软件开发的人员必须参加一年一次的“安全进修课程”培训。

　　2.1 需求阶段

　　安全系统开发的一个基本原则就是需要“自下而上”地考虑安全问题。 尽管很多开发项目开发出的“后续版本”是建立在先前发布的版本基础上，但是新的发行版或版本的需求阶段和初始规划仍然为构建安全软件提供了极好的机会。

　　在需求阶段中，产品小组与中央安全小组联系，请求指派安全顾问(在 Microsoft 实施 SDL 时称为“安全员”)，该安全顾问在进行规划时充当联络点，并提供资源和指导。 安全顾问通过审核计划、提出建议和确保安全小组规划适当的资源来支持产品小组的日程，为产品小组提供协助。 安全顾问在安全里程碑和出口标准方面向产品小组提出建议，这些安全里程碑和出口标准是由项目的规模、复杂程度和风险决定的。 从项目开始到完成最终安全审核和软件发布，安全顾问始终充当产品小组与安全小组之间的联系点。 安全顾问还充当安全小组和产品小组管理人员之间的联系人，向小组管理人员提供关于项目的安全要素是否正常工作的意见，以避免在流程的晚期出现安全方面的问题。

　　在需求阶段中，产品小组应考虑如何在开发流程中集成安全性，找出关键的安全性对象，以及在尽量提升软件安全性的同时尽量减少对计划和日程的影响。 在此过程中，产品小组需要考虑如何使软件的安全功能和保证措施与其他可能与该软件配合使用的软件相互集成。 (要满足用户将各个产品集成到安全系统的需要，考虑与其他软件的接口非常关键。)产品小组关于安全目标、挑战和计划的整体构想必须反映到需求阶段中制作的规划文档中。 虽然计划可能会随着项目的进行而变化，但是较早地明确制订这些计划将有助于确保不会忽视任何需求或不会直到最后一刻才发现它们。

　　每个产品小组都应将安全性要求视为此阶段的重要组成部分。 尽管有些安全性要求将在威胁建模过程中确定，但是用户需求可能要求根据客户的要求来考虑一些安全性。 符合行业标准或认证。