本文提供了关于 BSIMM 的常见问答。想要了解 BSIMM 完整模型，在此下载 BSIMM 报告文档。
常见问答
什么是 BSIMM？
BSIMM（读作“bee simm”）是内置安全成熟度模型 (Building Security In Maturity Model) 的缩写。BSIMM 研究在现实世界中组织的软件安全方案，帮助企业确定其软件安全方案进展情况，以及如何逐步改善企业的安全工作。
谁需要关注软件安全？
开发并依靠软件来开展业务的组织（如今几乎所有企业都从事这些工作）要确保软件不存在以下问题：泄露数百万条用户身份记录；给选举结果带来质疑，从而承担巨大的法律责任；或者让机密信息落入坏人之手。要想让软件值得信赖，唯一的办法就是内置安全（build security in）。简言之，依赖软件的所有企业都需要 BSIMM。
BSIMM 有什么特别之处？
构建 BSIMM 时，我们依据的是研究实际软件安全方案得出的观察结果。BSIMM 不是告诉您应该怎么做；而是其他人实际上是怎么做的。这种对软件安全科学的“观察并报告”的方法与基于个人经验的描述性方法形成了鲜明对比。
BSIMM 评估过哪些企业？
BSIMM11 纳入了 130 家公司。在评估的当下，他们平均已实施了 4.3 年的软件安全工作（截至 2020 年 7 月，企业实施软件安全年限介于不足一年和 15 年之间）。130 家公司一致认为，他们的方案能够成功，都是因为有一个致力于软件安全的内部团队：软件安全团队 (SSG)。SSG 的平均人数为 13.9 人（最少为 1 人，最多为 160 人，中位数为 7.0 人）。有些企业会有一个由其他人员（开发人员、架构人员或组织中直接从事和促进软件安全的人员）构成的外围团队，该团队平均由 51.2 人组成（最少 0 人、最多 1,500 人、中位数为 0 人）。参与 BSIMM 评估组织的平均开发人员为 3,770.5 人（最少为 5 人，最多为 100,000 人，中位数为 1,000 人)，得出 SSG 与开发团队的平均人数比为 2.01%（中位数为 0.63%）。
总而言之，BSIMM 描述的是在 6,656 名外围人员的配合下工作的 1,801 名 SSG 成员，确保 490,167 名开发人员开发的软件（将近 176,269 个应用）的安全性。
这些企业内部由谁实际负责软件安全？
在我们的研究中，负责软件安全方案的高管同时担任各种各样的职务。包括：
- 公司安全助理副总裁
- 应用安全总监
- 安全保证总监
- 信息安全副总裁
- 应用风险管理副总裁
- 共享服务高级总监
- 软件安全工程经理
- 企业软件高级总监
- 架构和安全高级总监
- 全球信息安全创新高级总监
- 全球安全测试负责人
- 系统开发经理
- 安全架构师
- 产品运维执行董事
- 信息安全运维经理
- 信息系统经理
- 嵌入式系统网络安全领导者
我们观察到 SSG 在企业中的组织架构位置有所不同。具体而言，130 家参与研究的公司中，有 67 家的 SSG 是由公司 CISO 或者直接汇报给 CISO 的高管来领导的。有 21 家公司 SSG 汇报的直属高管为 CTO、6 家为 CIO、8 家为 CSO、4 家为 COO、2 家为 CRO，还有 1 家为 CAO。20 个 SSG 通过工程技术或产品组织的架构汇报工作。
BSIMM 包含什么？
BSIMM 的主要组织功能是其软件安全框架。该框架包含四个领域（管理、情报、SSDL 触点、部署），包含 12 种实践活动：
每项实践都包含其相关活动，BSIMM11 中共发现 121 项活动。研究期间，我们统计了观察到的各项活动的次数。下表显示了得到的数据。（如需各项活动的具体解读， 请下载 BSIMM 文档，其中详细描述了 121 项活动）。
对于每项活动，我们均给出一段描述和实例（1 个或多个），用以说明组织是如何实现这项活动的。这些实例不是开展特定活动的唯一方式，但我们认为它们有助于帮助读者理解软件安全的现实情况。
为什么会有这么多项活动（121 项）？
别担心，BSIMM 是一个观察模型，也就是说当我们看到多个组织开展某项活动时，会把该活动添加到模型中。这个模型是累积性的，没有组织会执行所有活动。多年来，我们在金融服务机构、独立软件开发商 (ISV) 和我们研究的 IoT 公司之间找到了相当多的共同点，但是他们的安全方案并不相同，而且每个组织都有少许不同。就像我们不会直接复制朋友的财务计划，所以也不要指望搭乘别人软件安全方案的“便车”。读者使用 BSIMM 作为想法来源和一般的指南，把 BSIMM 作为指导而不是食谱。
为什么 BSIMM 计分卡中对部分活动予以着重强调？
12 项被强调的活动是 在各项实践中最常被观察到的活动。
十二项常见活动
| 活动 | 描述 |
| [SM1.4] | 实施生命周期管理 |
| [CP1.2] | 确定个人身份信息 (PII) 责任 |
| [T1.1] | 开展意识培训 |
| [AM1.2] | 制定数据分类方案和数据清单 |
| [SFD1.1] | 集成并交付安全性功能 |
| [SR1.3] | 将合规约束条件转化为要求 |
| [AA1.1] | 开展安全性功能审查 |
| [CR1.4] | 并行采用自动化工具和人工审查 |
| [ST1.1] | 确保 QA 执行边缘/边界值条件测试 |
| [PT1.1] | 聘请外部渗透测试人员来查找问题 |
| [SE1.2] | 确保主机和网络安全基础功能就位 |
| [CMVM1.1] | 创建事件响应机制或者与事件响应团队交流 |
我是个偏爱直观的人。如何用图形化表述这项研究
为了让您对 BSIMM 提供的分析功能有一个概念，下面的蛛形图表显示了 12 项实践在一些组织中的平均成熟度水平。第一幅图表展示了所有 参与 BSIMM 评估公司的数据（我们称之为“AllFirms”）。第二幅图表展示了一个企业样本跟 BSIMM 所有公司对比的数据。
在 BSIMM 研究中，保险、医疗保健和金融三个行业接受严格的行业监管。根据我们的经验，大型金融服务公司于 20 世纪 90 年代到 21 世纪初，首先对监管变更作出反应，他们发起 SSI 的时间远远早于保险和医疗保健公司。尽管 BSIMM 中金融服务公司在过去五年中的数量翻了一番（它们大量增加了 BSIMM 数据集新启动的方案数目），但金融服务业 SSG 的平均评估年限仍为 4.9 年，而保险业为 3.8 年，医疗保健业为 3.7 年。
在并列对比中明显发现，金融服务业投入了较多时间，从而提高了 SSI 的成熟度。虽然保险行业包括一些成熟度异常值，但这三个受监管的行业的数据显示，保险业在软件安全方面表现普遍落后。我们发现医疗保健业与之形成鲜明对比，几乎没有异常值。
参与这项研究的每个企业在软件安全上都做的很好吗？
不。通过计算研究中各家公司的评分，我们还可以查看一家公司相对其于他公司的相对成熟度和平均成熟度。 BSIMM11 参与者的大多数评分在 16 至 45 的范围内，SSG 平均时间为 2.5 至 4.2 年。
我们很高兴地发现 参与 BSIMM 的企业 持续逐年增长。BSIMM11 的总体数据集比最初发布的规模增加了将近 38 倍。请注意，一旦样本规模超过 30 家公司，我们就开始应用统计分析，统计产生了非常重要的数据结果。
BSIMM 是一套标准吗？
BSIMM 不是 ISO 27001 或乒乓球官方规则那样的标准。相反，BSIMM 描述的是世界上多数成功的软件安全方案执行的一系列活动。从这个意义上讲，这是一套事实上的标准，因为这是各个组织的实际上的操作。可以说它是我们发现的，而不是发明的。
怎样使用 BSIMM？
如果您的企业还没有软件安全方案，那么您可能需要一个。您可以从使用 BSIMM 来开始：它可以帮助您确定您的软件安全团队需要多少人，这些人应该先做些什么，以及几年后他们可能要考虑什么事情。如果您已经有一个软件安全方案，那么您可以使用 BSIMM 来了解您的进展，并为将来制定计划。
如何定义软件安全团队？ 我所在组织有这个团队吗？
所有 BSIMM 参与者均有专门负责软件安全的内部团队——软件安全团队 (SSG)。我们从来没有观察到任何组织在没有 SSG 的情况下成功开展了 BSIMM 的活动。我们注意到，在我们研究的所有 130 个组织中，SSG 与开发人员的平均比率为 2.01%。这表示当我们平均计算每个参评公司的比率时，每 50 位开发人员就有一位 SSG 成员。对于有 500 位及以下开发人员的组织，观察到的最大比例为 51.4%，最小比例为 0.4%。对于拥有超过 500 位开发人员的组织，观察到的最大比例为 3.0%，最小比例为 0.1%。关于这些实体机构，要提醒您的细节是，130 家公司平均 SSG 规模为 13.9 人（最少 1 人，最多 160 人，中位数为 7.0 人）。
我懂了，可是我老板还不懂。软件安全方案如何起步？
经过多年的 BSIMM，我们发现有必要阐述软件安全的合理性，就像当初 IT 安全成为主流之前需要阐述其合理性一样必要。当时有些高管根本不理解为什么需要防火墙，或者入侵检测是如何预防小问题成为大问题，或者为什么只要教会人们如何思考安全问题即可切实改变企业文化。早些时候，即便是那些机智地理解了这个问题的经理，有时也非常想知道自己的公司要等多久才会成为受害者。
在 BSIMM 数据集中，我们已经看到软件安全团队在以下显著的情况下获得特许和资金：
- 执行管理层对进行中的事件做出了反应，并下达命令，他们将开发安全软件并为其提供资金支持（例如，比尔·盖茨在 2002 年发布的微软安全备忘录，其中将安全作为首要考虑因素）。
- 一个负责某种的合规性的高管团队确定（很可能是在遭受惨痛的损失之后）：软件安全是公司管理过程中的一项必要开支。
- IT 安全团队证明某项违约不是他们的过错，而是公司应用程序的安全漏洞导致的。
- 一位有影响力的软件安全企业家（例如，在 CIO、CTO、法律或管理团队中）负责启动该系统，然后充分利用前期获得的成就，为实际项目募集资金。
- 一个开发小组在进入 DevOps 的过程中有组织地发展了各种“安全”角色（例如，云安全、构建安全、容器安全），并且一位高管将这些工作标准化为一项计划，从而将知识和流程推广到所有开发小组。
看来现在最困难的部分并不一定是说服高级管理层接受这一问题，而是让他们相信您是领导实施解决方案的合适人选，而且您确实已经有了一套方案。如果您是软件安全负责人（即使从某种意义上说，就是在重大软件安全故障后将被解雇的人），但您无法为一项安全计划获得资源来解决问题，那么请立即辞职。人生太短暂，无需做没有意义的事件，而且有许多雇主愿意真正利用您的能力。
最新的 BSIMM 研究突出了几个关键主题？
“左移”变得“无处不移”
BSIMM 数据显示，“左移”变得“无处不移”，并且企业越来越倾向于在整个价值流中执行持续、基于事件的安全遥测，而不是单一的时间点分析。
工程技术部门还是 SSG 领导软件安全工作
在整个 BSIMM11 过程中，对工程技术部门领导的活动的依赖度加重已成为一个主题，其中弹性（而非简单地追求安全或品质）成为软件的首要目标。
DevSecOps
BSIMM 数据显示，越来越多的组织采用 DevSecOPS 原则，将安全活动纳入整个 CI/CD 流水线，并专注于快速部署安全而有弹性的软件。
大企业都是如何应对应用安全问题的？
BSIMM11 描述了数据集中的 130 家公司的活动趋势，并说明了在新兴、成熟和优化阶段的 SSI 中观察到的活动。BSIMM 数据显示，高成熟度方案在模型描述的所有 12 种实践中都开展了许多活动。
