转载

软件安全构建成熟度实践尝试

软件安全构建通过在软件开发生命周期（SDL）中增加安全的控制点，保障软件架构安全性，减少脆弱性和软件安全漏洞的出现，实现软件缺省安全（Security By Default）。各个企业或组织在实践软件安全构建的控制节点或安全措施各有不同，成效也各有差异。但整体上均参照微软软件开发生命周期的流程思路进行落地。软件安全构建成熟度的评估，通过构建一套评估框架，在不同的域内对安全控制点的执行程度进行比较，一方面在各企业组织间横向比较软件安全构建的水平，同时也在纵向上为企业提升软件安全构建水平提供了方向和坐标。本文以微软SDL为基础，结合行业常见的软件安全构建成熟度模型，综合形成一个成熟度评估框架，便于横向对比，也便于整体落地。

由于翻译水平、见识理解均有限，材料内容供各位参考，欢迎提出宝贵建议。

一、微软SDL

要想评估软件安全构建成熟度水平，就是要知道在软件构建生命周期是什么样的，也要了解在这个生命周期中安全都承担了那些角色，要做那些事情。微软在这方面给我们提供了思路和实践经验。

安全开发生命周期（SDL）即SecurityDevelopment Lifecycle，是一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。自2004年起，微软将SDL作为全公司的计划和强制政策，SDL的核心理念就是将安全考虑集成在软件开发的每一个阶段:需求分析、设计、编码、测试和维护。从需求、设计到发布产品的每一个阶段每都增加了相应的安全活动，以减少软件中漏洞的数量并将安全缺陷降低到最小程度。安全开发生命周期 (SDL)是侧重于软件开发的安全保证过程，旨在开发出安全的软件应用。

软件安全构建成熟度实践尝试

上图是在微软提供的SDL流程，虽然现在业内都在强调DevSecOps，微软的方法论在朝着这个方向调整（详见 https://www.microsoft.com/en-us/securityengineering/devsecops ），但我认为其本质原理还是工程化、流程化的，思路框架还是值得参考学习的。基于微软SDL的方法论，《软件安全开发生命周期》（华德、李普纳）提供了一些具体的可操作性实践，其大致内容框架如下。

微软SDL阶段任务
阶段0	教育和意识
阶段1	项目启动
阶段2	定义并遵从设计最佳实践
阶段3	产品风险评估
阶段4	风险分析
阶段5	创建安全文档、工具以及客户最佳实践
阶段6	安全编码策略
阶段7	安全测试策略
阶段8	安全推进活动
阶段9	最终安全评审
阶段10	安全响应规划
阶段11	产品发布
阶段12	安全响应执行

软件安全构建成熟度实践尝试

二、参考熟度模型

1. BSIMM

BSIMM模型（BuildingSecurity In Maturity Model）是通过收集统计多家不同企业的安全实践，总结出来的一套评估内容和评估标准，并以此来标注企业软件安全构建的演进方式。BSIMM的框架内容在下表中进行展示，主要表现为治理、智能、SSDL触点、部署4个主要领域，每个领域有具体细分为3个模块，每个模块具体控制措施数量不一，在顺序上整体上是呈现自然过渡的关系，但并不是按照顺序执行才是最佳的成熟度演进方式。

在成熟度评分方面，BSIMM更像是一个统计坐标，将统计得出的最常见的安全控制措施作为一级，相对困难的作为二级，非常复杂的作为三级。另外BSIMM按照不同的行业也提供了参考的成熟度标准，方便不同行业进行参考。

软件安全构建成熟度实践尝试

在评估内容方面，BSIMM的领域和框架更加贴近企业实务，而在评分方式上，由于缺乏行业内的数据统计，因此难以每一项都与行业水平进行比较。

BSIMM评估框架
领域	模块
治理	战略和测量
治理	合规和策略
治理	培训
智能	攻击模型
智能	安全功能和设计
智能	标准和要求
SSDL触点	架构分析
SSDL触点	代码检查
SSDL触点	安全测试
部署	渗透测试
部署	软件环境
部署	配置管理与漏洞管理

2.SAMM

软件保障成熟度模型(SoftwareAssurance Maturity Model，简称SAMM)是OWASP的一个开放式的框架，用于帮助组织制定并实施所面临来自软件安全的特定风险的策略。在顶层设计上，SAMM设置了四种关键域（Business Functions 业务功能），分别是监管（Governance 我还是习惯叫治理）、构造（Construction）、验证（Verification）、部署（Deployment）；对于每一个域，SAMM设置了三个安全措施（ Security Practices ）；对于每一个安全措施，SAMM设置了三个成熟度等级，以及一个隐含的起始级别即0级。

软件安全构建成熟度实践尝试

SAMM的评估方法分为简便评估和详细评估两种。简便评估通过回答已经设置好的问题进行判断；详细评估则需要执行额外的审计后再逐一评分。由于企业实际的执行情况往往并非非此即彼、非1即2的成熟度水平，因此框架提供了“+”表示介于两个级别之间。最终级别为：0、0+、1、1+、2、2+、3、3+，共8个。

软件安全构建成熟度实践尝试

（SAMM评估框架）

Business Functions	Security Practices
监管	策略与指标（Strategy & Metrics）
监管	政策与遵守（Policy p & Com liance）
监管	教育与指导（Education & Guidance）
构造	威胁评估（Threat Assessment）
构造	安全需求（Security q Re uirements）
构造	安全架构（Secure Architecture）
验证	设计审核（Design Review）
验证	代码审核（Code Review）
验证	安全测试（Security g Testing）
部署	漏洞管理（Vulnerability g Mana ement）
部署	环境强化（Environment Hardening）
部署	操作实现（Operational Enablement）

（SAMM级别描述）

级别	描述
0	起点，表示该项活动没有实际完成
1	能够初步理解该项安全实践，并能针对特定场景实现
2	能够提高该项安全实践的效率和（或）有效性
3	在一定规模上综合掌握了该安全实践

3.其他参考

个人理解，由于身处网络安全行业，因此考虑软件的安全常常从网络安全角度出发，实际上软件安全保障也要从业务角度进行分析和判断，例如软件是面向金融、或医疗、或工控，则软件不仅需要安全（security），也需要安全（Safety）。因此可以通过可以从国标GB/T 30998-2014 信息技术软件安全保障规范中寻找一些思路。

一般分析	人员、组织及职责
一般分析	软件安全计划
一般分析	人员认证及培训
一般分析	资源
一般分析	软件生存周期
一般分析	文档要求
一般分析	可追踪性
一般分析	差异核问题的报告、追踪
一般分析	软件配置管理活动
一般分析	工具支持及批准
一般分析	现货软件
一般分析	外包管理
一般分析	认证过程
一般分析	偏离及豁免
一般分析	安全保密性
软件开发的安全保障	软件安全需求分析
软件开发的安全保障	软件设计的安全保障分析
软件开发的安全保障	软件实现的安全保障分析
软件开发的安全保障	软件测试的安全保障分析
软件运行使用的安全保障分析

三、软件安全构建成熟度模型

1.框架内容

结合上述几家之言，合并同类项，重新组织形成一套软件安全构建的成熟度模型。模型依然分为四个域，分别是战略与测量、建设与实现、验证与测试、部署与响应。每个域分为三个评估子域，再进一步将每个子域细分为若干评估项。

成熟度评估框架
战略与测量	策略制度	战略
		合规
			策略
			流程检查点控制
		与领导层/相关方沟通
		人员组织	安全培训与意识教育(人员认证及安全培训)
			角色&职责
	人员配备
	测量与改进	绩效评价
	建设与实现	安全需求	软件安全需求内容
		安全需求	软件安全需求分析
软件设计		攻击模型
		架构安全评审
		安全功能和设计
软件实现		标准和要求
软件实现		开源组件管理
验证与测试	设计验证	设计分析
	安全测试	代码检查
		应用系统动态扫描
		移动APP静态扫描
		交互性测试
	上线审查	最终安全审查
部署与响应	渗透测试	渗透测试
	运营支持	配置管理与环境加固
	运营支持	漏洞管理
	事件响应	应急响应

2.评分标准

由于缺少统计对象，评分标准不能采用BSIMM统计分析式的；SAMM评分方式较为可行，但一方面在原有0、1、2、3四个级别上增加出4个“+”级别，操作起来相对繁琐，另一方面8个级别的成熟度，与IT行业熟知的CMMI5个级别的成熟度，在认知上有些偏差。因此，还是采用了1、2、3、4、5，5个级别的成熟度评估方式。说明如下。

成熟度级别	说明
1	初始的
组织以一种混乱的方式处置软件开发过程中的安全风险；在软件构建过程中实现安全控制措施或相关的安全活动，但都是应激式的。
2	可重复的
认识到安全在软件开发过程中的重要性和必要性；有风险评估方法，但不成熟；能够在软件构建过程中例行实现一部分安全控制措施或安全活动。
3	已定义的
组织定义了如何实现控制措施和风险控制；能够在软件构建过程中可重复的、主动地执行相应的控制措施。
4	可管理的和可测量的
组织有评估和测量安全控制措施的标准；能够在软件构建过程中对安全控制措施的有效性、效率、收益情况进行管理和评估。
5	可优化的
组织可以规律地、有效地执行一个结构化的、组织范围内的改进程序，对安全控制措施进行改进和优化；