01 前言
为了降低安全漏洞修复成本，应该尽量在软件开发早期发现软件安全缺陷，因此越来越多的企业开始从传统的安全运营领域，进行安全“左移” (Shift Left)，在软件开发生命周期早期进行安全要素的嵌入，进行SDL/DevSecOps的落地实践。
但是在软件开发全生命周期安全管理过程中，无法避免会遇到安全度量的问题：
当前的安全管控做的是否全面？
和业界领先的差距有多大？
安全投入有限，优先应该投入到哪儿？
每年如何对安全工作成效进行量化？
"If you can"t measure it, you can"t manage it." 因此，需要引入软件安全能力成熟度模型，对当前的安全水位进行度量和对比，即可以纵向量化安全的成果，也可以横向发现和业界领先的差距。
02 软件安全成熟度发展史
20世纪70年代初，由于软件系统的规模和复杂度的增加，软件的可靠性问题变得越发突出。软件研究人员开始关注软件系统的质量属性，陆续制定了一系列质量控制相关的国际标准，如CMM/CMMI、ISO/IEC9000、ISO/IEC15504、ISO/IEC12207等。出发点是将软件开发视为一个过程，从而对软件开发和维护进行过程监控，保障软件产品的质量。但并没有将软件的安全性做为软件产品的质量标准之一，标准中也没有包含相应的安全性目标和活动。因此，一个软件企业即使达到了很高的软件成熟度（比如，通过了CMMI5级评估）也无法证明其开发的软件具有足够的安全性。
20世纪90年代中后期，随着互联网的发展，软件系统互联与开放性增强，由于软件漏洞导致的安全事件以及造成的资产和服务功能损失急剧增加。软件安全从传统的计算机安全和网络安全中分离出来，成为一门独立的学科开始发展。各种软件安全开发理论、实践和标准相继推出，包括：BSIMM、Microsoft SDL、ISO/IEC 27034、Cisco NIST 800-64、信息系统等级保护。同时，也形成了多个侧重于评估组织安全开发能力和保障能力的理论和标准，软件或软件系统安全成熟度模型，如：BSIMM，OWASP OpenSAMM, SSE-CMM (Systems Secure Engineering Capability Maturity Model)等。
运用上述这些安全成熟度模型，可以达到以下目标：
评估组织在软件系统安全保障能力上的现状和水平，分析与组织业务目标期望和业界平均安全水平的差距。
根据组织的业务目标，综合考虑资源情况和信息系统开发成熟度等限制因素，规划合理、可以实现的努力方向和演进路线。
以统一的标准，定期评估组织的安全能力，向管理层展示各方面的实质性进步，并证明安全投入的实际成效。争取管理层对信息安全的长期支持。
定义并持续改进组织所采取的安全措施，形成可以执行的安全项目计划。
03 软件安全成熟度评估方法
3.1 BSIMM
软件安全构建成熟度模型（BSIMM，Building Security In Maturity Model）是一种描述性的模型，由Synopsys（原Cigital）公司研究与维护。通过量化多家不同企业的实际做法，发现共同点和不同点，帮助其它组织规划、实施和衡量其软件安全计划。
2008年发布了BSIMM第1版，对9家公司开展了调研和常见安全活动的识别，并基于软件安全框架对这些活动进行了组织和分类。
2020年发布了最新版BSIMM 11，采集了130家企业的实际软件安全实践的定量数据，这些企业分布在金融服务、金融科技、独立软件供应商、科技、医疗、云等领域，非常具有代表性。
BSIMM采用软件安全框架（SSF）和活动描述，来提供一种共同语言以解释软件安全中的关键点，并在此基础上对不同规则、不同领域、采用不同术语的软件计划进行比较。
BSIMM的软件安全框架分为4个领域（domain）:包括治理、情报、SSDL（安全软件开发生命周期）触点和部署，每个领域又各分三项实践（practice），共形成12项安全实践。
对于每个实践，会根据统计数据给出多数公司都在从事的主要安全活动，且根据被调查公司参与安全活动的占比量排名，将安全活动分成1，2，3级。如下图所示的为SSDL触点的安全活动和分级。
BSIMM中的活动并不是静态的，会根据不同时期安全关注点的新变化进行相应变更，BSIMM11中包括了121项活动，对每一项活动，BSIMM也给出了指导性解释。
进行评估时，按活动打分，并以某实践为单位进行合并和正规化，形成0-3.0的得分区间，做为某实践的最终成熟度指标，并以蜘蛛图的方式与行业做横向差距对比或进行自身纵向对比。但是，BISMM公开文档中并没有提供具体的评分过程和打分标准，而是以商业服务形式提供。
3.2 OpenSAMM
OpenSAMM是一种专门度量软件安全成熟度的开放式、规定性参考模型。由OWASP组织开发和维护，2009年发布1.0版，2016年发布1.1版，2017年发布了1.5版，2020年发布了最新的2.0版本(https://owaspsamm.org/)。
SAMM2.0模型与开发范例无关,支持瀑布，迭代，敏捷和DevOps开发。该模型足够灵活，可以让组织根据其风险承受能力以及其构建和使用软件的方式采取措施。
SAMM成熟度分为3级：1级-初始实施，2级-结构化实现，3级-优化操作。
OpenSAMM将软件开发分解成5种通用的核心活动（称为“业务功能”）：治理、设计、开发、验证和运营。对每一个核心活动定义3个安全实践。这些安全实践覆盖了软件安全保障所有相关领域。在每个安全实践下，定义了三个连续的目标，描述了组织如何按时间顺序来提升安全实践。
每一实践都有对应的三个成熟度级别：
0 : 默认的起点，表示实践没有开展。
1级：对实践有基本的理解，以自由的方式开展实践。
2级：提升了实践的效率和/或有效性。
3级：大范围全面掌控实践。
对于每个安全实践，SAMM定义了两个活动流。这些流将不同成熟度级别的实践中的活动对齐并链接起来，每个流都有一个目标，可以提高成熟度。对于每种安全实践，SAMM定义了三个成熟度级别。每个级别都有一个逐步完善的目标，包括特定的活动和更严格的成功指标。
据公开报道，截止2017年4月，只有13家公司(包括：Dell，HP，Fortify宣称采用了OpenSAMM方法。而OWASP官方站点上并没有提供全球视角的、各行业平均成熟度水平报告。这样，就对横向比较带来的困难。
3.3 SSE-CMM
1994年4月，美国发起，约60个厂家参与，启动了称为“系统安全工程能力成熟度模型”(Systems Security Engineering Capability Maturity Model)的项目，通过对安全工作过程进行管理的途径，将系统安全工程转变为一个完好定义的、成熟的、可测量的学科。1996年10月，第一版正式推出。1999年4月发布第二版，后成为国际标准（ISO/IEC 21827）至今。
SSE-CMM描述的是，为确保实施较好的安全工程，一个组织的安全工程过程必须具备的特征。其描述的对象不是具体的过程或结果，而是过程中的一般实施。主要涵盖以下内容：
SSE-CMM强调的是分布于整个安全工程生命周期中各个环节的安全工程活动。包括概念定义、需求分析、设计、开发、集成、安装、运行、维护和更新。
SSE-CMM应用于安全产品开发者、安全系统开发者及集成者，还包括提供安全服务与安全工程的组织。
SSE-CMM适用于各种类型、规模的安全工程组织。
SSE-CMM模型中大约含60个基础实施，分11个过程域，这些过程域覆盖了安全工程的所有主要领域。
与CMM相似，SSE-CMM模型也有五个能力水平，从低到高排列如下：
级别1： “非正式执行级”。这一级别将焦点集中于一个组织是否将一个过程所含的所有基础实施都执行了。
级别2：“计划并跟踪级”。主要集中于项目级别的定义、计划与实施问题。
级别3：“良好定义级”。集中于在组织的层次上有原则地将对已定义过程进行筛选。
级别4：定量控制级”。焦点在于与组织的业务目标相合的度量方法。
级别5：“持续改善级”。强调必须对组织文化进行适当调整以支撑所获得的成果。
SSM-CMM模型及其评价方法可以达到以下目的：
1. 将投资主要集中于安全工程工具开发、人员培训、过程定义、管理活动及改善等方面。
2. 基于能力的保证，也就是说这种可信性建立在对一个工程组织的安全实施与过程的成熟性的信任之上的。
3. 通过比较竞标者的能力水平及相关风险，可有效地选择合格的安全工程实施者。
虽然关注SSE-CCM的组织大多是提供安全产品或安全服务的专业信息安全公司，但SSE-CMM标准的思想，对于一般软件的研发和运维各阶段的安全活动，同样具有指导意义。另外，对于如金融行业大量采用的外购系统或供应商定制的软件产品，往往没有强制性的软件安全测评标准和结果，而通过运用SSE-CMM标准对供应厂家或供应商的安全能力比较，也可以间接完成对具体产品的安全性对比。
04 软件安全能力成熟度评估实践
相对于国际及国内先进软件开发组织而言，笔者所在行业软件质量和研发成熟度水平普遍较低。多数公司在信息安全领域中仍然重点投入于传统的主机安全和网络安全方面，而对于软件安全方面的关注度普遍低，投入少，缺乏战略规划。在此状况下，进行软件安全能力成熟度评估工作的主要目的包括：
从公认的软件安全领域维度评估自身软件安全现状。
分析与先进组织在软件安全实践中的差距。
制定提升计划和演进路线，争取信息技术部门的认同和公司管理层支持，形成公司级应用安全战略规划。
定期评估，以衡量提升度，并制定下一轮的软件安全建设计划。
在初始阶段，首先进行了软件安全成熟度评估，并以此为基础，与国际金融行业平均水平做了定性的比较，在综合考虑公司业务目标、软件开发水平、人员能力等因素后，确定提升目标，分解行动计划，并以项目的形式执行迭代。
每年持续进行成熟度评估，展示取得的成效，分析差距，确定下一轮迭代目标和行动方案。
4.1 评估方法
与软件安全，特别是软件开发安全相关度比较高的评估方法是上节中介绍的BSIMM和OpenSAMM，相对而言，BSIMM的社区活跃度高、参与的公司多、数据更新较快、评估结果认同度高及说服力强。
因此，我们采用BSIMM模型进行软件安全能力成熟度评估。
4.2 活动分解
BSIMM11 共有121项活动(Activity)，但关于每一项活动的描述抽象度仍然较高，对此活动直接进行评价仍然有比较大的不确定和模糊性。
为此，我们根据自己的现状和关注点，进一步划分了三个、可清晰确定完成度的子活动。如上图的SM2.6 要求签发安全性证明，制定三个子活动如下：
子活动是评估的最小单位，既可以是活动目标达成的阶段性步骤，也可以是衡量目标是否达成的控制措施，可以参照国际/国内的通行做法、相关标准规范要求或者企业自身实践进行制定，作为活动的评价依据。
下面给出标准和要求(SR)、架构分析(AA)及代码审查(CR)的子活动分解示例。
4.3 评分方法
根据BSIMM官方文档描述，BSIMM采用高水位标记方法绘制蛛网图，进行不同企公司间对比，来评估大致的SSI成熟度。分配高水位线的标记方法比较简单, 如果实践活动中观察到一个3级活动, 就给此模块分配3分, 而不去考虑是否也观察到了任何2级或1级的活动。
BSIMM公开文档中并有没提供可操作的活动评分标准。我们参考了OpenSAMM的活动和实践评分规则，在考虑活动执行的完整度同时，加入了对活动完成质量的度量，如下是详细的评分细则。
总共是12个实践(Practice)，每个实践包含Level1、Level2、Level3共3级，每级满分1分，实践得分为3级得分总和，满分为3分。
实践得分 = Level 1 ~ Level 3 得分总和
每一级(Level)包含多个活动(Activity)，每一级得分为活动得分的平均分(每个活动满分为1分)。
Level x得分 = Level x活动得分平均值
每个活动拆分为3个子活动(Sub Activity)，活动得分为子活动得分的平均分。
活动得分 = 3个子活动得分平均值
为了更加客观、量化的进行评价，子活动按照两个纬度评价：
完整度（Completeness）：该活动进行的完整程度。
质量（Quality）：该活动的质量评价。
每个纬度评价分为3级：0、0.5、1，具体含义如下：
子活动得分 = 完整度得分 * 质量得分
子活动存在4个评价分：0、0.25、0.5、1。
4.4 评分过程
应用安全团队成员现场进行集体评估，对于每一个活动的控制措施即子活动逐项打分。每个子活动，根据当年度是否在完整度及质量方面有改进进行客观评估。
下图为代码审查（CR）Level 2的评分示例。
依据上述的评分方法，对121项活动共计300多个子活动进行评分，最终得出4个领域12个实践的评分。
采取蜘蛛图方式进行实践得分的直观展示，既可以与往年纵向比较，量化各个实践安全 能力成熟度的提升，也可以横向比较发现和业界领先的差距。
4.5 差距分析
根据评分结果，分析当前软件安全能力成熟度现状，历史纵向比较的改进，分析与业界领先存在的差距点，发现自身的不足。
可以针对差距较大的实践，详细分析当前差距点和缺失的控制措施等，列出可以改进的方向。
4.6 成熟度行动计划（MAP）
软件安全能力的建设是一个持续并不断优化的过程，涉及到各方面的资源投入和平衡，根据差距分析的结果，参考业界领先的实践，结合实施的成本和收益，规划需要实现的首要活动，确定下一年度可行的改进方向和行动计划。
BSIMM会根据企业的调研数据，列出参与度最高的实践活动，企业在制定改进计划时可以作为参考。
如下为行动计划示例。
05 后记
相比BSIMM的高水位标记的评分方法，本文的评分标准更为严格，得分会相对低一些。但是BSIMM的评分具有参考价值，我们应该逐步拉近和平均值的差距。
BSIMM的实践活动每个版本都会有少许变化，因此每年在做差距分析时，需要对最新版本进行解读，同步更新活动。
通过软件安全能力成熟度评估，以评促建，并参考框架标准的指导，结合自身实际情况，可以逐步形成适合自身的软件安全开发生命周期管理框架，通过迭代反馈，持续进行优化，逐步提升软件安全风险管理能力。
文章参考来源
BSIMM11
OpenSAMM
SSE-CMM
声明：本文来自DevSecOps联盟，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
