​大家好，这里是安势信息。11月底，由美国ODN、NSA CCC、CISA、CSCC等多个政府机构部门联合发布了《保障软件供应链安全：SBOM实践应用相关指南》（后续简称为《SBOM应用指南》），《SBOM应用指南》主要由ESF（Enduring Security Framework长期安全框架）小组编撰，该文件根据行业内对于SBOM的最佳实践和原则提供了一些指导意见，并且鼓励软件开发商和软件供应商们参考，以维护和提高对软件安全性的认识。PS：本文涉及到的相关英文名词缩写及术语表见文末附录、英文原文件见文末链接该文件主要从软件供应链安全为出发点，详细阐述了SBOM对于软件供应链安全的重要性，为我们提供了整个SBOM 生命周期中实际使用的有效建议。本文为下半部分，主要内容为第Q12-Q23，同样的每个问题后会附上原文出处，如果您没有观看上半，可点击我们的主页进行查看。

Q12：SBOM的使用可以为我带来什么直接的收益？

SBOM最直观的价值可以体现在为采购某款软件产品的采购风险提供相关信息，尤其是当实际的采购行为发生在对某产品的SBOM进行过评估后，但这并不代表有了某产品的SBOM就能实现“一劳永逸”，SBOM并不能直接体现“零日漏洞”的存在，类似于“零日漏洞”的相关信息企业应该可以通过媒体、供应商、漏洞库等信息源获取。

原文出处：见P14 —第3.2节

Q13：SBOM的的内在价值是什么？

SBOM 提高了对企业或组织正在评估、部署或已经在其环境中运行的软件的构成的可视性，简单来说，即提升了软件供应链透明度。

换句话说，如果某供应商对其产品的软件供应链透明度很差，那么客户对于该供应商的采购行为就应该持谨慎态度，因为尽管当下没有暴露出风险或重大漏洞，但是供应商无法保证今后可能出现的软件供应链风险。

原文出处：见P14 —第3.2.1小节

Q14：SBOM中显示有漏洞是否就代表着一定有风险？

不是。SBOM如果显示某个组件有漏洞，并不代表着一定有对应的风险。具体的原因正如前文所提到过的一个概念——VEX。

VEX文件是一种机器可读的安全建议，可用于明确漏洞风险，因为在软件中包含某漏洞并不代表着该漏洞会被调用，即有可能该漏洞的存在不会带来相关风险。从技术上讲，VEX 并非 SBOM 的一部分，两者可以独立存在，但同时使用两者将最大限度地提高 SBOM 的使用效率和安全效益。VEX可以标明漏洞的状态如下：

• 未受影响—无需修复该漏洞

• 受影响—建议修复该漏洞

• 已修复—该版本已经修复了该漏洞

• 正在调查—尚不清楚某版产品是否受到该漏洞影响

VEX工具或能力集成到现有安全工具中的情况在2023年才开始兴起，但不可否认VEX的运用对SBOM的使用及发展起到了重要的推动作用。

原文出处：见P16—第3.2.2.1小节

Q15：我通过SBOM了解到漏洞信息后接下来应该怎么做？立即修复漏洞吗？

从软件漏洞的生命周期来看，可以采取的软件漏洞风险应对方法有：接受、缓解、转移和避免。有的时候通过SBOM对漏洞进行了风险评估以后确实会出现将风险评估为可接受，即无需采取额外行动的情况。但是如果需要对该漏洞进行处理，那么通常有以下方式：

• 卸载易受攻击的软件

• 使存在漏洞的资产退役

• 在不影响软件整体功能的前提下禁用该漏洞组件

打补丁修复漏洞并不总是一个立竿见影的选择。修复漏洞意味着系统要停止运行，而这一决策可能对组织带来重大损失，尤其是在一些工业操作类的领域，所以需要慎重。但总的来说，风险管理更多是一个前置性的动作，这要求企业对威胁情报要及时的进行收集和评估以避免事故出现时“措手不及”，也可以向一些安全服务提供商购置第三方服务。

原文出处：见P17—第3.2.4节

Q16：SBOM需要更新吗，如何更新现有的SBOM？

SBOM的更新主要是由于现有软件的更新或升级而产生的，也存在一种情况是为了让现有的SBOM更加完整全面而单独的更新SBOM，新SBOM的获取、验证等流程与前面所述的基本相同，不过需要注意的是新的SBOM需要与之前的SBOM进行比较，找出自上一版本以来引入或删除的新组件及依赖关系，并根据当前的威胁信息对这些变更进行验证。

原文出处：见P18—第3.3节

Q17：可否就SBOM实际落地运用的流程以举例的形式梳理并进行讲解？

在企业的风险和漏洞管理流程中充分利用SBOM 内容，可以有效减少特定漏洞的暴露窗口，并且加快修复流程，以下将通过一个实例进行举例：

使用SBOM的相关流程和最佳实践，如上图所示：

1. XYZ软件已被收购并部署到A企业。在购置时，A企业接收、验证并处理了该产品的SBOM。SBOM 内容被加载到企业资产管理库中，并与企业漏洞和威胁管理系统和流程相连接。

2. 在未来的某一天，CVE发布了一个针对常用开源实用程序的能被主动利用的漏洞。

3. 企业的风险管理系统基于CVE数据对资产管理库进行查询，以确定企业中是否包含或依赖于含有该漏洞的开源软件。

4. 在本例中，被A企业收购的XYZ软件包含这个易受攻击的开源软件。

5. A企业的安全团队现在可以通过SBOM了解组织内包含该开源软件的产品，并可以评估软件产品存在新报告漏洞的风险、制定风险应对措施，并开始准备和采取降低风险的措施。

6. 所有这些都可以在 CVE 发布后近乎实时地完成。而在没有 SBOM 内容的情况下，A企业应等待软件的供应商或开发商验证漏洞，然后才能收到通知。这种通知通常要等到供应商或开发商开发出补丁后才会发出。

此外，将企业的软件的 SBOM 内容关联起来，还可以为事件响应团队、取证团队、风险管理和采购部门提供强大的洞察力。

原文出处：见P19—第3.4节

Q18：什么是风险评分？

风险评分是一种用于预测软件或其组件当前和未来风险的指标。该指标是利用 SBOM、VEX等信息以及支持 SCRM 的其他信息和内容制定的。

原文出处：见P20—第4.3节

Q19：如何使用SBOM进行风险评分，为什么要进行风险评分？

SBOM就是进行风险评分的重要信息依据，SBOM不仅能跟踪明确的已知风险（如对照已知漏洞列表进行检查），还是针对具体情况进行风险分析的起点。通过SBOM 可以了解组件来源的详细信息，尽管一些信息无法在 SBOM 中直接获得，但 SBOM 数据可用作此类信息的起点，为更深入的风险分析提供信息。

在软件供应链中，缺乏向客户传达软件风险的统一方法，尤其是目前许多方法都存在不足，这也是因为开源组件的使用呈指数级增长但是透明度却极低，同时软件内部极其复杂的依赖关系以及涉及的法律合规问题，所以建立风险评分的机制来帮助企业更好的了解软件当前和未来可能面临的威胁及其产生的影响。

原文出处：见P20—第4.1、4.2节

Q20：影响SBOM风险评分的主要因素有哪些？

脆弱性、许可证合规、社区和依赖性这四个因素被确定为风险评分主要维度。这些因素的完整性和覆盖面将直接影响SBOM风险评分。

下表列出了相关的衡量标准及信息来源，可供大家实施风险评分参考

原文出处：P21-—第4.4节

Q21：风险评分模型的局限性是什么?

将风险归结为一个单一的分值，从管理模型的角度来看是很好的选择，但从以行动为导向的角度来看，就有待商榷了。并且这种自定义的风险评分机制从宏观层面来看，比较缺乏公信力，难以被证明，写入合同中并由市场中的其他人验证。

所以企业最好能够从多个权威的安全风险信息源及时获取信息，同时充分运用各类工具和服务为自己建立供应链风险管理的各种能力，或者与第三方供应商签约来支持风险管理。

原文出处：见P22—第4.4.6节

Q22：企业如何高效利用SBOM风险评分去降低风险？

利用SBOM风险评分的基础是使SBOM的使用流程化，标准化，这样才能让SBOM的自动化程度提升从而进行风险评分的计算，下图提供一种理想状态下的SBOM风险评分应用流程供参考：

1. 将SBOM纳入到产品信息库

2. 验证SBOM

3. 储存SBOM并将SBOM信息与软件资产完成映射对应

4. 充分利用SBOM、VEX、CVE等信息进行连通及评分

5. 计算得出风险评分是否可接受

与此同时，使用SBOM风险评分来为企业的采购流程提供供应链风险的信息支持，以及通过SBOM风险评分带来的组件级的细粒度去揭示新漏洞带来的潜在威胁而进行企业威胁管理，也是SBOM风险评分的重要运用之一。

原文出处：见P25—第4.5、第4.5.1节

Q23：什么是四象限方法，四象限方法如何与SBOM联系起来？

四象限方法是评估COTS（商用成品软件—Commercial Off-The-Shelf）软件中发现的开源漏洞的一种有效方法。例如，对于存在某些漏洞的软件（这些漏洞被认为影响较小且不太可能被利用），这类软件风险程度低，就可以批准其购买、续订。但是风险程度的高低如和评定？这就需要使用到SBOM上的一些信息，下图描述了在获得 SBOM 结果后的四象限方法决策流程：

原文出处：见P26—第5节

在2023年，SBOM的实际运用仍然没有大规模的普及，但可预见的是SBOM的使用将在未来不断发展和普及。以SCA为首的各类新兴工具的使用将有助于实现SBOM的自动化和规模化。与此同时，不同的企业会关注不同的风险，而SBOM可以帮助他们提升软件透明度从而更好地管理这些风险。

随着 SBOM 的日益普及，业界仍在挖掘更多的使用案例，并期待出现更多的使用案例。所以提供 SBOM，以及保留 SBOM 数据以应对紧急情况对于大部分企业来说仍然是最稳妥的选择。安势信息愿与业界同仁共同为软件供应链的安全共同努力与进步，让SBOM及其相关工具在今后发挥更大价值！

英文原文下载链接如下：https://media.defense.gov/2023/Nov/09/2003338086/-1/-1/0/SECURING%2520THE%2520SOFTWARE%2520SUPPLY%2520CHAIN%2520RECOMMENDED%2520PRACTICES%2520FOR%2520SOFTWARE%2520BILL%2520OF%2520MATERIALS%2520CONSUMPTION.PDF附录：