2.2　常见的SDL模型和框架

接下来将介绍几种常见的SDL模型和框架，并根据它们的应用情况和发展情况进行对比分析。

2.2.1　政府组织——NIST SSDF

前面指出，欧美国家在开发安全领域的研究起步早、积累优势大。美国更是长期处于领先地位。举例来说，美国的NIST很早就关注到了软件供应链安全和SDLC安全，并持续跟踪研究了多年，多次发布相关文件以指导软件安全开发。其中比较有代表性的有：2004年6月和2008年10月，NIST陆续发布了Security Considerations in the Information System Development Life Cycle的第1版（即SP800-64 Rev1）和第2版（即SP800-64 Rev2），指出了在软件开发过程中构建安全开发体系的重要性和成本效益，并着重介绍了SDLC中涉及的信息安全组件。（注：相关文件已于2019年5月废止。）

2020年4月，NIST发布了白皮书Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework，正式提出Secure Software Development Framework V1.0（SSDF V1.0，其中SSDF通常译为软件安全开发框架），并在2022年2月正式推出它的更新版本SSDF V1.1。NIST SSDF相对清晰地描述了一套基于已有标准、指南和安全软件开发实践的高层次最佳实践，重点考虑了软件供应链安全包括的软件自身及相关生产要素的安全。具体来说，SSDF的最佳实践被分为4组，每一组包括相应的安全实践活动 ，如表2-1所示。

注：此内容为SSDF V1.1的新增内容。

NIST并非监管机构，作为一个鼓励和促进创新的标准化组织，出台的一些文件并不具备强制属性，所以SSDF的安全实践活动只是建议并非强制项，但这些实践活动都是非常值得尝试的。此外，SSDF并不是另起炉灶，而是在实践项目中引用并整合了大量其他框架的最佳实践。SSDF中的安全实践能够为企业提供借鉴价值，帮助企业较为清晰地进行决策，选择适合自身的软件开发框架，以及及时确定需要改进的地方，而不必花费过多精力在问题收集和评估工作上。

2.2.2　企业实践——微软SDL模型

2002年，微软启动了可信计划，以保证旗下产品的安全性、可用性、可靠性和完整性。具体来说，微软重新定义了设计安全、默认安全、部署安全等，以确保软件开发体系的安全和隐私，在传统的瀑布式开发模型基础上发展出了安全开发生命周期模型，这就是微软SDL的雏形。2004年，经过一系列应用实践和持续优化，微软决定将SDL作为公司的强制策略，以此减少软件产品的安全漏洞数量，防止应用“带病”上线。随后，在相继发布的Security Development Lifecycle、Write Security Code中，微软的安全专家们详细描述了安全开发生命周期方法论（即SDL，这里的SDL第一次作为一种软件安全开发方法论被讨论）以及安全工程团队对SDL（作为一种方法论）的见解和最佳实践，并对如何在组织中实施SDL提供了指导，包括指导开发人员从设计安全的软件升级到编写能够承受攻击的代码，以及开发阶段软件漏洞的测试实践 。在SDL发展过程中，Steve Lipner（微软SDL之父）和Michael Howard对推动SDL建设起到了至关重要的作用。

微软SDL主要包括培训、需求、设计、实施、验证、发布、响应7个软件开发阶段和相应安全活动（见图2-1），将安全活动集成到软件开发生命周期的目的不是要彻底改革整个开发过程，而是要添加定义良好的安全检查点和安全可交付成果。从图2-1可知，微软SDL中的每一步都将安全属性引入软件产品，并且每个阶段的安全活动都是独立的，保障软件开发安全。但据微软实践经验总结，把这些安全活动作为一个可重复的整体过程实施比独立实施于某个阶段具有更好的效果。

面对云原生、大数据、人工智能等新场景，微软SDL模型也针对性地进行了更新。更新后的微软SDL模型如图2-2所示。

2.2.3　开放组织——OWASP CLASP模型

和微软SDL一样，CLASP也是由规范的一系列安全活动组成的模型。其突出特点是强调安全开发过程中各角色的职责，将安全活动与角色相互关联起来。此外，CLASP是一种针对Web安全提出的轻量级SDL模型。

CLASP模型中包含视图和一些最佳实践，如图2-3所示。其中，视图包括概念视图、基于角色的视图、活动评估视图、活动实施视图以及漏洞视图。对于基于角色的视图，CLASP为了阐明安全活动步骤的重要性采用了“灵魂拷问”模式：安全活动什么时候实施，如何实施？采用安全活动可以避免多大的安全风险？实施这项安全活动预计需要多少成本？简而言之，就是考量安全活动的3个核心问题：做的时机、不做的风险、做的成本。可见，CLASP是一种合乎人性特点的安全开发模型。

CLASP模型相较于其他安全开发模型体现出明显的“轻量”特点，具有一定的灵活性。其要实施的安全活动及其安全活动的执行顺序是可选择的，即不同企业针对不同开发项目可以自行选择实施的安全活动及其执行顺序，以适应待开发项目的实际情况。

2.2.4　个人贡献——McGraw BSI模型

BSI模型的提出者Gary McGraw博士是一位致力于软件安全研究的专家。在Gary McGraw博士的社交媒体上置顶了下面的文字：

软件安全是将安全实践集成到我们构建软件的方式中，而不是将安全功能集成到我们的代码中。

Gary McGraw博士同时也是一位笔耕不辍的作者，编写过多本关于IT安全的书籍。早在2001年，Gary McGraw就与John Viega合著了Building Secure Software，在2006年出版的Software Security:Building Security In中正式提出了Building Security In（缩写为BSI），主张要在软件开发过程中实现安全能力内建。

具体来说，BSI模型的目的是为开发人员和安全从业者提供工具、方法等。因此，BSI模型不强调流程，而是将风险管理框架、7个安全接触点、安全知识作为软件安全的三大支柱。

BSI模型对7个安全接触点的重要程度进行了排序，以帮助企业确定优先推进顺序。7个安全接触点按照重要程度排序为代码审查、风险分析、渗透测试、基于风险的安全测试、滥用案例、安全需求分析、安全操作。

7个安全接触点作用于整个软件安全开发生命周期。从图2-4中可以看出，需求用例、架构设计和测试部分均涉及风险分析。2013年，Gary McGraw博士又发表文章Cyber War is Inevitable（Unless We Build Security In），再次提到内建安全能力，并将内建安全能力的重要意义从软件安全和网络安全保护上升到关键信息基础设施安全保护的层次。

2.2.5　安全开发模型和框架对比分析

需要指出的是，对于大多数开发者来说，前面几种软件安全开发模型和框架中的任何一种应用到日常软件开发中，都可以帮助开发者及时发现并修复安全漏洞，降低软件上线运营后被攻击的可能性和攻击后造成的影响，进而提高软件的安全性。

当然，前面介绍的软件安全开发模型和框架各有特性。为了便于开发者选择，这里对它们做进一步对比分析。

1）微软SDL具有的特性如下。

·具有很好的通用性，能够与各种软件开发模型，例如瀑布式模型、敏捷开发模型等相结合。

·并不只是针对Windows应用程序提出的，也为Web应用程序提供了很好的隐私安全保护，适用于不同的平台。

·具有详细的文档，且能够提供具体的安全活动，这也是它长期被企业推崇、学习和优化的原因。

·具有充分的工具支持，是唯一支持使用工具进行威胁建模的软件安全开发模型。

2）CLASP具有的特性如下。

·其不仅可以为新项目提供支持，还可以集成到现有的、处于维护状态的系统中。

·安全活动的定义基于角色，为每个角色分配相应的安全活动，以保证安全活动的完成程度与质量。

·定义了多种角色，但是在落地实践中企业无法将安全活动与相关人员进行很好的对应。

·由于安全活动没有明确的映射，可能无法与敏捷开发等较为新颖的开发模式相结合。

3）BSI模型具有的特性如下。

·基于安全接触点理念，对代码审查有利，更偏向描述型。

·具有较好的通用性，能够和不同的软件开发模型相结合。

·具有较好的灵活性，企业可以根据自身情况优先选择较为重要的安全活动。

4）SSDF具体的特性如下。

正因为SSDF的发布时间相对较晚，所以设计得也比较全面，从安全实践活动基线来看也比较完备。其在某种程度上可以理解为是对前面几种软件安全开发模型的融合。 k8wSPSj5WLcis5Nc4xCqc3yAqN0FPKOaiYsfqqpo4MyVhLjlV77OEICpHi5uCPIM