深度解读|关于SBOM最基础元素，你需要知道的 Part III

在短期内，建议云服务提供商有一个内部的 SBOM。该 SBOM 必须保持与上述最基础要素大致相同的功能，尽管格式和架构可能因提供商的内部系统而异。云服务提供商还必须有能力针对这些信息采取及时的行动。我们相信，随着时间的推移，SBOM 数据将会被整合到第三方风险管理和供应链风险管理工具和流程中的最佳实践中。

将漏洞数据放在与 SBOM 不同的数据结构中进行追踪。随着这两类数据的发展和技术的成熟，运营层面应着重于两类数据之间的映射和联系。如果漏洞数据是跨组织共享的，那么漏洞数据和 SBOM 都可以使用类似的模型进行分发、访问控制和使用。

1、SBOM 提供者必须做出一些可靠性判断，即一个漏洞是否不影响特定的软件。这其中原因有很多：编译器可能从组件中删除受影响的代码，漏洞可能在执行路径中无法到达，内联保护的存在，或者其他一系列的原因。如今，产品安全事件响应小组（product security incident response teams, PSIRTs）应该可以做出这些判断，由他们跟踪内部的依赖和风险。

二进制分析工具可以用来更好地了解有关系统中的组件和依赖关系。二进制分析也可用于验证 SBOM 内容，或帮助了解 SBOM 数据中的空白。

所有建立在最基础要素的要求应借鉴两个关键概念。首先，所有的安全，特别是 SBOM，是一个漫长的过程，而不是一个单一的目标。第二，SBOM 的基本原则是提高软件供应链的透明度。

• 不同生态系统之间软件身份与 SBOM 的分发。使用单一的命名空间看似可以解决这个问题，但是过于理想化，因为其中涉及扩展性、多样性等诸多障碍。

  
  

• 版本管理方法和系统的多样性问题亟待解决。这需要进一步的协调工作。

  
  

• SBOM 数据的中心化。这种方式的优点是：当 SBOMs 集中存储在一个可以被其他应用程序和系统轻松查询的存储库中时，会获得更大的价值，比如可以用来获得对组织、甚至生态系统或国家层面所面临的系统风险的更多信息。它可以通过让协调者了解哪些组织或供应商有潜在风险，从而促进漏洞披露。也可以了解哪些组件使用最广泛，或在最关键的部门，并优先考虑安全研究或加固方法。然而，有些人担心这些关键信息会被利用进行新的攻击。我们有必要进一步研究如何共享、保护和使用 SBOM数据。

• 制造商描述符（Manufacturer Usage Descriptor）：一种允许设备在网络上交换自身的重要信息，包括网络功能，特别是本文件中的SBOMs的机制。

  
  

• 数字材料清单（Digital Bill of Materials）：是一种提供包括SBOM在内的开放式供应链数据的多种证明，以及围绕这些证明的共享和访问策略有关执行的解决方案。

  
  

• OpenC2：是一种标准化语言，用于提供或支持网络防御的技术的指挥和控制；现阶段，OpenC2已经被利用来处理、加工SBOM数据并据此采取行动。