软件安全构建成熟度模型演变与分析

[[207537]]

前言

软件安全开发主要是从生命周期的角度，对安全设计原则、安全开发方法、***实践和安全专家经验等进行总结，通过采取各种安全活动来保证尽可能得到安全的软件。但是，能否将安全开发的概念整合到企业原有的开发过程中，通常取决于企业规模、资源(时间、人才和预算)，以及管理层支持等各种因素。如果方式不当，很可能造成高昂的成本甚至整合失败。

建立软件安全构建成熟度模型能够帮助企业理解安全开发举措的关键要素，根据开发团队的成熟度水平确定各种安全举措的优先级，从而控制上述因素的影响。

本文介绍了BSIMM、SAMM、SDL优化模型、CMMI+SAFE等四款软件安全构建成熟度模型，分析了这些模型近年来的演变及其产生的原因。

软件安全构建成熟度模型概述

该部分介绍各软件安全构建成熟度模型的由来、概念和基本组成。

1、内建安全成熟度模型BSIMM

内建安全成熟度模型(Building Security In Maturity Model，简称BSIMM)，是2009年3月正式提出的。BSIMM的核心目的就是对组织所实施的“软件安全举措”进行量化。

软件安全框架(Software Security Framework，以下简称为SSF) 是BSIMM赖以成型的基本结构，如上图所示，它为各种安全活动提供了一个通用的词汇表，来解释”软件安全举措”中的主要要素。

从2013年开始，BSIMM经历了3个版本的变动：2013年10月的BSIMM 5、2015年10月的BSIMM 6和2016年8月的BSIMM 7。在这三个版本的变动中，其基础的SSF框架并没有任何的变动。

2、软件保障成熟度模型SAMM

软件保障成熟度模型(Software Assurance Maturity Model，简称SAMM) 是一个开放式的框架，用于帮助组织制定并实施所面临来自软件安全的特定风险的策略。在2009年3月发布正式版之后，它成为OWASP 的项目之一。

SAMM的框架顶层定义了四种关键业务功能，而每种关键业务功能下又包含了三类安全措施，共计12种安全措施，如上图所示。

自2009年SAMM 1.0发布之后，SAMM共更新过两次，分别是2016年3月的SAMM 1.1和2017年4月的SAMM 1.5。

3、安全开发生命周期SDL优化模型

SDL 优化模型围绕5个功能领域构建，这些领域大致与软件开发生命周期的各个阶段相对应：培训以及政策、组织功能、要求和设计、实施、验证、发布和响应。针对这些领域中的实践和功能，SDL 优化模型还定义了四个成熟度水平——基本、标准、高级和动态。其结构如下图所示。

从SDL优化模型2008年发布以来，它的内容未更新过。而且现在微软的官方网站上也找不到相关材料，只是在“安全自评估”的页面中提到：“使用SDL优化模型能够帮助组织评估产品在开发过程中的安全状态，随后组织可以利用SDL 优化模型为渐进地、经济地创建更安全、可靠的软件提供愿景和实施路线”。

4、CMMI+SAFE

+SAFE模型是由澳大利亚国防部和美国卡内基梅隆大学共同研制开发的，并且针对CMMI 开发模型(CMMI-DEV)增加了两个额外的过程域，涵盖安全管理和安全工程的内容。

+SAFE旨在识别安全关键产品的安全性强项和弱项，并且意图在产品采购过程的早期识别出的安全漏洞。

从2007年3月发布以来，+SAFE的内容也未更新过。

软件安全构建成熟度模型的演变

本节，我们对近年来模型的演变情况进行分析，因为只有BSIMM和SAMM存在内容的更新，所以主要聚焦在这两个模型上。

1、BSIMM的演变

(1)模型演变

BSIMM模型基础框架SSF近年来并没有变化，而只是对各种安全活动的变更。具体情况如下表：

其中，紫色框表示该活动为该版本BSIMM新增加内容;绿色框表示该活动的成熟度级别进行了上调，即考虑的优先级有较明显的降低;橙色框表示该活动的成熟度级别进行了下调，即考虑的优先级有较明显提升。

安全活动增加

从上表中可以看到，在BSIMM 5和BSIMM 7中分别新增了一项安全活动，为“运营漏洞奖励计划”和“使用应用程序容器”。“运营漏洞奖励计划”是为了借助更多的外部技术力量来保障软件安全，而“使用应用程序容器”则明显是顺应了目前大量使用Docker等容器进行开发的趋势。

安全活动级别调整

另外，在版本演变的过程中，对部分安全活动的成熟度级别进行了调整。在3次版本更新的所有13项变化中，只有3项的成熟度级别进行了下调，也就是说这3项活动的应用趋势有较明显的增加，分别是：“使用自动化工具检测自定义规则”、“将安全测试包括在QA自动化中”和“执行为应用程序API定制的模糊测试”。

一方面，这三项活动分别属于“代码审计”和“安全测试”这两项安全实践，且都属于“SSDL接触点”这个领域;另一方面，前两项都与自动化相关，可见安全测试的自动化趋势愈加明显。安全测试自动化的需求应主要来自于DevOps;而对应用API进行模糊测试的需求可能来源于大量Web API的使用。

(2)数据演变

由于BSIMM是一种观察模型，所以BSIMM中也包含了观察到的各种数据。而这些数据的变化，也揭示了一些安全开发的趋势。

加入BSIMM社区(参与BSIMM评估)厂商的详细分布数据如下表所示：

从数据中可以看到，越来越多的垂直行业开始参与到BSIMM的评估中，从最开始的金融服务、软件开发，到医疗和物联网，再到云厂商和保险厂商。

加入BSIMM社区的安全人员和开发人员对比的详细数据如下表所示：

从上表中可以看出，安全人员与开发人员的比例呈现逐步上升的趋势(从BSIMM 4到BSIMM 5的数据下降，是因为BSIMM 5引入了数据新鲜度的概念，数据的计算方式有所变化)。

2、SAMM演变

与BSIMM类似，SAMM的整体框架(业务功能、安全实践)并没有变化。但是在形式和内容上，进行了大量的丰富和完善。

SAMM 1.1的改进

如上图所示，在SAMM 1.1中，原有的SAMM 1.0模型被划分成了两部分：操作指南和核心模型。并新增了快速入门指南、工具箱、OWASP资源和SAMM基准。

SAMM 1.5的改进

SAMM 1.5通过细化评分模型提升了评估的粒度，并在成熟度基准的评估中允许部分评分。现在，组织将获得在安全实践中完成的所有相关工作的评分，而不是将分数保持在***的成熟度水平。

同时，SAMM 1.5通过工作表和指南中的典型案例，帮助组织在理解自身安全状况定位的同时，也知道类似情况下哪些工作对于别人是有效的。

从两次SAMM的演变情况中，可以看出SAMM对于评估的可操作性和实用性进行了较大的改进。不难看出，在企业对软件安全构建成熟度模型一无所知的情况下，如果想对开发安全状况进行自评估、了解下一步的改进方向，那么SAMM无疑是成本最小、最便捷的方式。

分析及展望

通过上述分析可以得出以下结论：

软件安全成熟度模型，仍然以大量安全实践和统计数据为基础。本文中分析的软件安全成熟度模型，近年来并没有发生大的变动。自2013年来，这四个模型的基础框架都未发生变化，仍然是以安全实践和安全活动为主，并未引入新的理论依据。

安全构建成熟度模型会根据软件开发技术的发展而演变。BSIMM新增的安全活动“使用应用程序容器”，以及对“使用自动化工具检测自定义规则”、“将安全测试包括在QA自动化中”和“执行为应用程序API而定制的模糊测试”的级别调整，都揭示了容器、DevOps、Web API等对成熟度模型的影响。

安全测试的工具化、自动化，是未来的发展趋势。为了顺应现代软件开发部署的快节奏，软件安全测试的工具化、自动化将势不可挡。例如SAMM的工具化、实用化演变，SDL威胁建模工具、静态分析工具、二进制验证工具的持续更新，BSIMM中“使用自动化工具检测自定义规则”、“将安全测试包括在QA自动化中”这种自动化安全活动的兴起，都证实了这一点。

软件安全将受到越来越多的关注与重视。从BSIMM的数据演变中可以发现，无论是加入软件评估的企业数目，还是各企业内专业从事软件安全的人员比例，都呈现逐步上升的趋势。

对于软件开发安全的未来趋势，我们认为：随着DevOps、微服务等软件开发技术的发展，传统软件安全的形态不断发生着演变。很多测试、评估的技术路线都在持续地演进，但是自动化、高速、与传统开发流程进行融合的趋势将愈发明显。工具化、自动化的安全测试将会成为各家公司保障软件安全的基础举措，而安全从业人员能够将更多精力投入到过程的改进与管理中。根据目前各软件安全构建成熟度模型的情况，我们也给出如下建议：

对于依托互联网、云服务等技术演变迅速的高科技公司，应尽可能避免使用SDL优化模型、CMMI+SAFE模型，因为其内容已经较长时间没有更新，可能有些细节已经无法与现阶段的开发过程或技术相匹配;

对于资源相对充足、安全关键的大型机构，可以采用BSIMM模型来指导安全开发体系的建设，同时引入专业的安全开发咨询服务，来尽可能保证企业始终处于较高的安全水平;

对于资源有限的中小型公司或创业公司，可以考虑引入SAMM模型，从而在控制成本的同时，尽快提升整体的软件安全水平。