微软发布安全开发周期流程能否拥抱敏捷？

近日，微软发布了《安全开发周期（Security Development Lifecycle，下文简称 SDL）流程指南 4.1a 》， 以指导开发团队将安全需求无缝地引入到软件开发过程之中。SDL 是微软内部全公司软件项目强制使用的安全流程，并在众多旗舰级产品得到应用。鉴于敏捷方法 在社区和微软内部的广泛应用，此次发布的指南专门列出了一章讲解如何将 SDL 与敏捷方法集成。由于 SDL 一贯应用在微软内部的传统瀑布式开发方法之上，所 以此次发布引发了社区的激烈讨论。

为了响应对软件安全性的要求，微软根据微软内部的软件开发流程定义了安全开发周期流程（SDL），以指导开发团队将安全需求无缝地引入到软件开发过程之中，其目标是：

使设计、代码和文档中与安全相关的漏洞减到最少，在软件开发的生命周期中尽可能早地清除漏洞。

SDL 针对整个软件开发流程——从软件开发的开始阶段到整个开发周期结束——定义了每个开发阶段的安全需求和实施措施，来达到最终软件的安全性和保密性。SDL 的完整生命周期分为五个阶段——需求定义、设计、实现、验证和发布，再加上前期的团队培训和后期的响应。SDL 在每个阶段都定义了相应的安全任务，指明了团队需要分别关注的安全问题，比如在设计阶段对安全威胁进行建模（Threat Modeling）。团队通过在软件开发过程中相应地采纳这些改进，最终减少软件中的缺陷漏洞，改善软件安全特性。经典的 SDL 流程如下图所示：

图 1 SDL 与传统瀑布开发方法的结合

自从 2004 年起，SDL 就是微软内部全公司软件项目强制使用的安全流程，并且在众多旗舰级产品，比如 Vista 和 SQL Server 等软件的开发过程中，都得到了广泛的应用。随着敏捷方法在软件开发社区以及微软内部广泛受到拥蹙，SDL 4.1a 专门列出了一章分析如何裁剪 SDL，使之能与轻量的敏捷软件开发方法结合在一起使用，其出发点是：

以一种同时保障敏捷方法和 SDL 流程原则的方法，把经受考验的微软安全性开发周期（SDL）方法与敏捷方法学结合在一起。

为了能在敏捷方法中顺利采纳 SDL 流程，SDL 指出了两个必要的调整：

1. 纳入敏捷开发流程的 SDL 必须足够精益。这意味着对于每个特性，开发团队只是完成足够的 SDL 工作即可。
2. 与传统瀑布型开发方法吻合很好的 SDL 中各个阶段（设计、实现、验证和发布）与敏捷方法并不吻合，必须采用更敏捷的方式。

对于 SDL 与敏捷方法结合，最大的问题是敏捷发布周期可能短到一周，团队在每次发布之中实施完整的 SDL 需求显然时间不够。但是，它也不是“不可能完成的任务”：

• SDL 定义了一系列的安全任务，这些任务可以很好地嵌入到敏捷开发流程里面
• 相对而言，SDL 文档量很少，除了安全威胁模型可能产生一定的文档

接下来，SDL 以敏捷方法族中的 Scrum 为例，介绍了如何将 SDL 定义的任务与 Scrum 中的 Sprint 结合在一起。开发团队可以将 SDL 任务划为不同的特征，然后作为非功能性需求添加到 Sprint backlog 里面。结合 Scrum 和 SDL 的各自特点，SDL 将包含的任务划分为三类：

1. 每次 Sprint 都必须执行的需求
   最关键的一部分安全性需求，必须在每次 Sprint 里面都执行检查，比如不要使用被禁止的 API 等等
2. 桶内需求（bucket ）
   这些需求仍然需要定期地执行，但不需要每次 Sprint 里面都执行
3. 一次性需求
   这些需求只需要在整个项目开发过程执行一次即可

如此之后，SDL 任务在整个 Scrum 流程中的分布示意图如下：

图 2 SDL-Scrum 结合后的示意图

随后，SDL-Agile 介绍了将 SDL 任务应用到每个 Sprint 里面的具体实践：其中包括对团队成员安全知识培训，引入并熟悉工具等等。特别指出的是，因为安全威胁建模（threat modeling）在传统的 SDL 中是主要的产出物来源，同时又是每个项目必须采取的安全性检查，SDL 专门介绍了如何将敏捷开发方法与安全威胁建模流程结合在一起。最后，SDL-Agile 通过一个小例子介绍了在 Scrum 项目 Sprint 的具体开发里面，开发团队如何计划、完成 SDL 任务，以及 SDL 如何帮助团队改善产品的安全特性。

在 SDL 4.2 指南发布之后，社区里面也是传来不少声音。如 Jon Oltsik 认为：这次发布非常重要，因为：

1. 敏捷开发方法被广泛应用。微软也在内部使用，因此将敏捷与 SDL 结合起来是一项非常重要的企业目标。
2. 软件安全性普遍很差 —— 特别是一些 web 应用系统。
3. 软件安全性在很多网络安全改进计划中，比如由 SAIC 和 SAFECode.org 研究并提出的 Cyber Supply Chain Assurance Model 等都是处于核心位置。

虽然指南中给出了一个 Scrum 团队拥抱 SDL 的例子，但也有一些人士对该指南仍然抱有一些疑虑， David West 就指出：

这里要解决的问题还包括谁来负责（SDL 与敏捷方法结合的）工作。…该工作的复杂性会导致一些任务被分解成一部分使用敏捷开发，一部分使用传统方法进行开发。这样，专家需要既驱动传统开发和测试，同时又指导团队进行敏捷方法的开发和测试。

Rex Black 也提出：

SDL 里面的一些实践，比如使风险文档流线化和风险分析流程等等对 SDL 进入“真实的敏捷世界”可能会挑战重重…这些出现在 SDL 实践实施到敏捷开发方法过程中的挑战对于最终的采纳会是一个显著的障碍。

当然，有人也从 4.2 指南之中闻出了不同的味道， Sean Michael Kerner 指出：

对我而言，如果说微软没有敏捷开发方法的安全实践，那实在是有些奇怪。同时也说明，大型项目，如 windows 或者 office 办公软件等并没有采用敏捷方法。
……微软看上去现在前进得越来越快，这样他们能拥抱开源社区开发者们一直所知道的一切。快速编码迭代可以引向更好的软件。而且，没错，它也能同样安全。

亲爱的读者，您可以从这里下载该《安全性开发周期（SDL）流程指南 4.1a》。您是如何看 SDL-Agile 呢？您觉得敏捷和安全特性是冲突的吗？如果不是，您在实际项目上又是如何做到两者结合的呢？留下您的意见，跟大家一起分享吧。