本文提供了关于 BSIMM 的常见问答。在此下载 BSIMM 文件，获取完全未经发掘的模型。
常见问答
什么是 BSIMM？
BSIMM（读作“bee simm”）是内置安全成熟度模型 (Building Security In Maturity Model) 的缩写。BSIMM 研究在现实世界中组织的软件安全计划，帮助您确定您的软件安全计划进展情况，以及如何逐渐改善您的安全工作。
为什么需要软件安全？
软件安全是指构建即便遭受攻击仍然安全的软件。我们从审查网络安全漏洞的多年经验中得知，只要在构建软件时牢记安全，保护软件就会变得容易得多。而且，安全是财产而不是杂物，所以抵抗攻击的软件安全涉及的内容远远不止于简单地在软件中添加加密或密码等安全功能。
谁需要关注软件安全？
开发并依靠软件开展业务的组织（如今几乎所有人从事这些工作）需要的软件应当不会泄露数百万条身份记录，给选举结果带来质疑，导致承担巨大的法律责任，或者让秘密落入坏人之手。要想让软件值得信赖，唯一的办法就是置入安全。简言之，依靠软件的所有人都需要 BSIMM。
BSIMM 有什么特别之处？
构建 BSIMM 时，我们依据的是研究实际软件安全计划得出的观察结果。BSIMM 告诉您的不是应该怎么做；而是其他人实际上都怎么做。这种对软件安全科学的“观察并报告”方法与基于个人经验的说明性方法形成鲜明对比。
你们研究过谁？
开展当前评估时，平均有 122 家向 BSIMM10 提供数据的公司截至其最近一次评估时间，已实施了 4.53 年的软件安全（截至 2019 年 6 月，实施年限介于不足一年到 19 年之间）。122 家公司一致认为，他们的计划能够成功，都是因为有一个致力于软件安全的内部团队——软件安全团队。SSG 平均规模为 13.1 人（最少 1 人、最多 160 人、中位数为 6.0 人），其他人员（开发人员、架构人员和组织中直接从事和促进软件安全的人员）构成的卫星组织平均由 51.6 人组成（最少 0 人、最多 1,500 人、中位数为 0 人）。参与组织的平均开发人数为 3,804.2 人（最少 5 人，最多 100,000 人，中位数为 900 人），平均开发收益百分比为 1.37％（中位数为 0.61％）。
总而言之，BSIMM 描述了在 6,298 名卫星人员的配合下工作的 1,596 名 SSG 成员，旨在确保 468,500 名开发人员开发的软件（将近 175,000 个应用）具有安全保证。
这些企业内部由谁实际负责软件安全？
在我们的研究中，负责软件安全计划的高管担任各种各样的职务。例如，企业安全助理副总裁、应用安全总监、安全保障总监、信息安全副总裁、应用风险管理副总裁、共享服务高级总监、软件安全工程经理、企业软件高级总监、基础架构和安全高级总监、全球信息安全创新高级总监、全球安全测试主管、系统开发经理、安全架构师、产品运营执行总监、信息安全运营经理、信息系统经理以及嵌入式系统和网络安全主管。我们观察到 SSG 的的确确存在于相当广泛的领域。具体而言，122 家参与研究的公司中，有 71 家拥有由 CISO 作为直属高管运作或领导的 SSG。17 家公司通过 CTO，6 家通过 CIO、7 家通过 CSO、4 家通过 COO、2 家通过 CRO、1 家通过 CAO，作为直属高管领导 SSG 工作。14 个 SSG 通过某些技术或产品组织汇报工作。
BSIMM 包含什么？
BSIMM 的主要组织功能是其软件安全框架。该框架包含四个域（治理、情报、SSDL 接触点、部署），负责 12 种实践活动：
- 管辖范围：策略与指标、合规与政策、培训
- 情报：攻击模型、安全功能与设计、标准和要求
- SSDL 接触点：架构分析、代码审查、安全测试
- 部署：渗透测试、软件环境、配置管理和漏洞管理
每项实践都有其相关活动，BSIMM10 中共有 119 项活动。研究期间，我们坚持追踪观察到的各项活动的次数。以下是得出的数据（如需单独解读各项活动，请下载一份 BSIMM 文件，其中逐个详细描述了这 119 项活动）。
对于每项活动，我们给出一段描述和一个或多个实例，用以说明组织是如何实现这项活动的。这些实例从来不是开展特定活动的唯一方式，但我们认为它们有助于理解软件安全实情。
噢，119 项安全活动似乎很多！
别怕！BSIMM 是一个观察模型，也就是我们会把多个参与组织从事的真实活动添加到模型中。因此这个模型是累积性的，而且没有组织会执行所有活动。多年来，我们在金融服务机构、独立软件供应商 (ISV) 和我们研究的 IoT 公司之间找到了相当多的共同点，但是他们的计划并不相同，而且每个组织都至少有少许不同。您不会直接复制朋友的财务计划，因而也不要指望搭乘别人软件安全计划的便车。使用 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”）。第二幅图表展示了一个企业样本按照 AllFirms 绘制的数据。
保险、医疗保健和金融这三个加入 BSIMM 的行业接受严格的行业监管。根据我们的经验，大型金融服务公司于 20 世纪 90 年代到 21 世纪初，首先对监管变更作出反应并发起 SSI 的时间远远早于保险和医疗保健公司。尽管金融服务公司在过去五年中的数量翻了一番，它们大量涌入 BSIMM 数据池新启动的计划，但金融服务业 SSG 的平均评估年限仍为 5.4 年，而保险业为 3.2 年，医疗保健业为 3.1 年。在并排对比中发现，金融服务业投入较多时间，提高集中 SSI 的成熟度。虽然保险行业包括一些成熟度异常值，但这三个受监管的行业的数据显示，保险业在软件安全方面表现普遍落后。我们发现医疗保健业与之形成鲜明对比，几乎没有异常值。
参与这项研究的每个人都很擅长软件安全吗？
通过计算研究的每家公司的得分进行排名，我们也可以看看一家公司的相对成熟度和平均成熟度。当前数据池的得分跨度为 [5, 83]。
我们很高兴地发现 BSIMM 研究正在逐年增长。我们报告的总体数据集比最初发布的规模增加了将近 38 倍。请注意，一旦样本规模超过 30 家公司，我们就开始应用统计分析，产生统计效果显著的结果。
BSIMM 是一套标准吗？
BSIMM 不是 ISO 27001 或乒乓球官方规则那样的标准。相反，BSIMM 描述的是世界上多数成功的软件安全计划执行的一系列活动。从这个意义上讲，这是一套事实上的标准，因为这是各个组织的实际操作。可以说它是我们发现的，而不是空想出来的。
怎样使用 BSIMM？
如果还没有软件安全计划，您就需要一个，可以首先尝试 BSIMM。BSIMM 可以帮助您确定您的软件安全团队需要多少人，这些人应该先做些什么，以及几年后他们可能要考虑什么事情。如果您已经有一个软件安全计划，那么您可以使用 BSIMM 来了解您的进展，并为将来制定计划。
什么是软件安全团队？ 我有吗？
所有 BSIMM 参与者 均有专门负责软件安全的内部团队——软件安全团队 (SSG)。我们从来没有观察到一个组织在没有 SSG 的情况下成功开展了 BSIMM 的活动。我们注意到，在我们研究的所有 122 个组织中，SSG 与开发人员的平均比率为 1.37%。这表示当我们平均计算每个参评公司的比率时，每 73 位开发人员就有一位 SSG 成员。SSG 比例最高达到 20%，最低则为 0.02%。关于这些实体机构，要提醒您的细节是，122 家公司平均 SSG 规模为 13.1 人（最少 1 人，最多 160 人，中位数为 6.0 人）。
我懂了，可是我老板还不懂。软件安全计划如何取得进展？
经过多年的 BSIMM 研究，我们发现有必要阐述软件安全的合理性，就像当初 IT 安全成为主流之前需要阐述其合理性一样必要。当时有些高管根本不理解为什么需要防火墙，或者入侵检测如何帮助防止小问题成为大问题，或者为什么只需教会人们如何思考安全问题即可切实改变企业文化。早先的时候，即便是那些机智地理解了这个问题的经理，有时也非常想知道自己的公司要等多久才会成为受害者。
在 BSIMM 数据池中，我们已经看到软件安全团队在以下显著的情况下获得租约和资金：
- 执行管理层对正在进行的事件做出了反应，说：“我们将制造安全软件”，并提供实施资金（例如，比尔·盖茨在 2002 年发布的微软安全备忘录，其中将安全作为首要考虑因素）。
- 一个负责某种形式的合规性的高管团队确定（很可能是在遭受惨痛的损失之后），软件安全是公司治理过程中的一项必要开支。
- IT 安全职员证明某项违约不是他们的过错，而是公司应用程序的安全漏洞导致的。
- 一位有影响力的软件安全企业家（例如，在 CIO、CTO、法律或治理团队中）负责启动该系统，然后充分利用前期获得的成就，为实际项目募集资金。
- 一个开发小组在进入 DevOps 的过程中有组织地开发了各种“安全”角色（例如，云安全、构建安全、容器安全），并且一位高管将这些工作标准化为一项计划，以将知识和流程推广到所有开发小组。
看来现在最困难的部分并不一定是说服高级管理层接受这一问题，而是让他们相信您是领导实施解决方案的合适人选，而且您确实胸有成竹。如果您是软件安全负责人（即便是，如果发生重大软件安全故障，您就会被解雇），而您无法为一项计划获得资源以解决问题，那么请立即辞职。人生太短暂，不可做无用功，而且有许多雇主愿意充分利用您的实力。
最新的 BSIMM 研究突出了几个关键主题？
DevOps 对于软件安全的影响。BSIMM 数据表明，DevOps 的发展以及 CI/CD 工具和数字转换的增长，正在影响各家公司为其软件组合构建软件安全的方式。
工程领域推动涌现了一股新的安全文化浪潮。BSIMM10 是我们的第一项正式反映 SSI 文化变化的研究，这一变化体现在工程领域主导的软件安全工作新浪潮中，此类工作能够形成自下而上的开发和运营团队，而不是从集中的 SSG 开始自上而下地形成。事实证明，以工程部门为主导的安全文化已成为一种在某些组织中建立和发展实用软件安全措施的手段，而即使在几年前，它也一直在努力做到这一点。
BSIMM 能够引导您完善自己的 SSI。BSIMM 数据显示，长此以往，组织就会实现显著改善。许多组织专注于研究自身现有活动的深度、广度和范围，而不再增加新活动，因而达到了更高的成熟度。
