负责应用安全某领域的负责人在某时某刻会遇到以下对话：
场景一：
CSO：今年干得如何？
小王：不错不错，兄弟们加班加点发现了N多的漏洞，我有数据。
CSO：那这有什么用？
小王：啊???...
场景二：
CSO：换下一话题，整体上我们的软件安全做得如何？
小王：稳步推动，近年来团队已经组建完毕，公司的软件安全状况逐渐越来越好。
CSO：有什么事实依据和标准？
小王：啊???...
场景三：
CSO：上次说现在随着安全建设已经收到了一定的成效？
小王：大概是处于国内一、二线吧。
CSO：那距离一线有啥不足，那我们应当在哪些方面继续加大投入？
小王：啊???...
这声“啊???...”是工作中经常遇到的情况。我们作为安全从业人员必须知道没有度量就没有运营，曾经知道我们的思路是Microsoft’s SDL和Synopsys’ Touchpoints，它们都是一种指导性的策略。前者SDL
这张图想必大家很熟悉了
目标为：“在设计、编码、实现阶段的安全漏洞最少化，在开发生命周期中尽早识别并降低此类安全问题。“。SDL的前提基于三个核心概念:培训教育、持续流程改进和责任划分。 对软件开发小组内部的人员进行不断的教育和培训有助于企业根据技术和威胁形势的变化做出反应。而SDL实施时倾向于重视了解安全漏洞的原因和影响。为了应对不断涌现出来的新技术和新威胁，有必要定期评估 SDL流程的有效性和进行必要的变更。应用安全负责收集三类数据：评估公司面向架构师、测试、开发、PM的培训效果（培训前后的产品缺陷数）；事中指标用来确认安全流程合规性（各部门合规应用数量、历史漏洞修复情况）；发布后数据（漏报数据、覆盖面数据）指导团队应对未来工作的重心变化。微软公司的实践认为将安全活动集合到软件开发流程可以提升安全工作的效果。
后者Touchpoints知道的人略少，但是我们都已经在做了，适用于未参与、不能关注软件设计和系统具体实现的场景。最早由McGraw（这位老哥的简介可以看破框和跨界：一个外国大牛离职后的活法）提出。认为软体安全是由三大支柱所构成的，分别是风险管理（Risk Management），知识（Knowledge）及软件安全的控制措施（Touchpoints），并将软体安全所有具体行为汇总成7个控制措施，包含：滥用案例（Abuse Cases），安全需求制定（Security Requirements），风险分析（Risk Analysis），基于风险分析的安全测试（Risk-Based Security Tests），代码审查（Code Review），渗透测试（Penetration Testing）和安全操作（Security Operations）;并将7个控制措施于适当时机点介入软件开发生命周期，从需求和使用案例（Requirements And Use Cases），设计与架构（Architecture And Design），测试计划（Test Plans），代码（code），测试及测试结果（Test And Test Results），到上线后系统使用的回馈（Feedback From The Field），让每一个发展阶段都与软件安全有着密切的关系。
思路同SDL不同，在多个迭代阶段均可使用
采用这样思路的较为轻量级，可以针对开发流程进行定制，主要产出的指标和数据在外部review、黑白盒测试、漏洞管理阶段。
上述两种是应用安全建设方面的方法论，并不提供一类、一组描述性的指标帮助企业评估、了解、对标软件安全计划和实践成果。CSO需要理解并被告知--1、哪里做得好、哪里做得不好；2、同一水平线哪里有缺失、距离高水平模型差距在哪；3、资源该如何投入。
概念介绍
本文介绍的BSIMM是一套实践模型评估工具，bsimm官方文档分为三个部分，每个部分各有侧重，第一部分是介绍bsimm的基础概念、科学研究的逻辑和方法；第二部分是系列术语和最小活动的详细解释；第三部分是记分卡表格和各项垂直行业的蛛网图，企业可以反复应用该理论框架进行多轮分析。组织的安全计划总是动态变化的。
，可以覆盖软件安全计划的方方面面，以可量化的业界数据为基准，通过一系列的指标权重来可视化地评估软件安全计划成熟度。好处是经过评估，企业可以横向发现同业界的差距用于持续改进、纵向评估安全计划实施一段时间后具备的成熟度，以重新分配资源、或者对外宣传。
样本数据来源方面，bsimm9由120家世界各地具备一定安全成熟度的企业（包括NVIDIA、联想、华为、Adobe、阿里巴巴、思科等）共同建立了116项活动指标，各项指标具备不同的权重。全部统称4个领域、12个实践模块，细化到各项的级别又从level1到3，1是基本要求。3是具备挑战性的。企业自评软件安全计划是否达到相应的level形成记分卡，通过记分卡直观看到企业的成熟度，达到评估和对标的效果。
如下图所示：BSIMM12个实践领域。
vBSIMM
我们会发现很多阶段需要供应商参与，适用于供应商的版本称为vBSIMM，现代企业都使用大量第三方软件，有定制的外采系统、有部署在公有云上的SaaS服务，有第三方组件。企业应当评估供应商的安全风险能力，而不仅仅是衡量某一刻特定软件的安全性。在供应商自测阶段要求：
- 有文档证明实施软件安全开发生命周期（SSDL）的证据。
- SSDL所描述的活动的使用证明（例如架构风险分析的结果或代码审查的结果）。
- 与软件安全团队领导的访谈，展示其对软件安全性的高度了解。
- 运作着一个软件安全团队
- 用于修复安全缺陷的过程记录。
- 第三方审查。
同BSIMM相比侧重黑体字部分
最终依照下面的表格确认签字。
同OpenSAMM的区别
都用来衡量软件安全成熟度，OpenSAMM（软件保证成熟度模型）是规范性的通用框架，由经验丰富的专家评估告诉合理的企业应当做到什么；BSIMM（软件安全构建成熟度模型）是描述性的实践积累，告诉企业一组数据说明世界上其他公司实际发生了什么。 前者是基于演绎推理的不证实推理，后者是基于证实推理的归纳推理。
如何操作
笔者适配了兼容bsimm9的版本放在github，https://github.com/nanolikeyou/BSIMM-Graphs-Data（虽说加入BSIMM社区是免费的，还是建议大家最终使用系统化的评估办法，由专业商业机构Synopsys实施评估流程和改进软件计划，开源项目只能用于科普和自评），依照ReadMe使用docker运行后填写调查表格，工具自动生成图表展示企业在12个大方面的蛛网图，通过分数和比例直观了解做的不足和领先点。
- docker运行，启动访问bsimm主界面：
- 新建team，点击table菜单，根据各项key，对比bsimm对各项级别的解释，自评yes or no，一路补全调查。
- 完成各项表格调查，save后选择redar，蛛网图绿色图即为企业的实际评估结果。通过比对下图的level1-3黄色图，可以看到企业在12个维度的长短。
- 点击observed或者observed（detailed），可以看到整体的状况，企业可以假设整体为主体建立一个project，以软件产品为主的公司可以划分单一产品线为独立project，评估不同产品之间的软件安全计划成熟度。
解读
以上面的示例数据team-a为例。可以看到全景图显示其在安全测试领域达到了较高水准（老外的单元测试写得多、因为需求没那么紧急，反观国内...）,在战略和目标方面偏弱，甚至未达到level1的水平，应当开展宣传教育、创建并公布相应的软件计划。其他方面就不再一一解读了（评估出来的结果总是我们隐隐知道的，但这是通过科学统计的方法，而不是以经验做“蒙古大夫”）。
当然评估结果并不一概而论，发现不足之处需理性对待，对于传统金融企业可能在治理合规性政策领先，新型技术驱动企业可能在攻击模型和安全性测试、渗透测试领先，云计算公司会在软件环境评估项占优。还记得我们的目标吗-观察评估软件安全计划的成熟度，有了相对准确的结果，才有理性数据支撑提升下一阶段的资源投入准确性、发现痛点持续改进、“追赶跨越”达到业界领先水平。
介绍
https://www.synopsys.com/content/dam/synopsys/china/software-integrity/datasheets/bsimm-cn.pdf
http://www.owasp.org.cn/OWASP_Conference/owasp-2017yzfh/4.pdf
https://www.aqniu.com/tools-tech/36164.html
https://www.bsimm.com/zh-cn/framework/software-security-development-lifecycle/architecture-analysis.html
https://zhuanlan.zhihu.com/p/53826418
案例：
https://www.huawei.com/cn/press-events/news/2018/6/bsimm-software-security-capabilities
https://blog.csdn.net/sch881226/article/details/81182615
目的：
https://www.synopsys.com/content/dam/synopsys/sig-assets/ebooks/how-to-get-the-most-lift-from-your-bsimm-results.pdf
