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

在上一篇文章中，我们为大家介绍了 SBOM 最基础元素涉及的数据字段、自动化支持与最佳实践和流程。在本篇文章中，我们会为大家介绍 SBOM 最基础元素指导意见的最后一个部分内容，在了解上述最基础元素之后, SBOM 应该具有哪些信息和特点来适应更广泛的应用场景，并为大家介绍本指导意见对 SBOM 今后发展的展望。

文章关键词：SBOM；SBOM 最基础元素；数据字段；漏洞

推荐的数据字段

除了之前我们介绍的必要数据字段之外，本指导意见也推荐有能力的厂商通过添加以下数据字段的方式来更好地管理开源组件的使用。

基于云的软件和 SaaS 类软件

许多现代的软件应用程序都是作为一种服务提供的。这给生成 SBOM 数据带来了特别的挑战。由于软件不是在客户的基础设施上运行，也不在客户的控制之下，所以风险管理的角色也不同。用户不负责维护，也不能控制任何环境因素。了解漏洞或风险信息并采取行动的责任在于服务的提供商。此外，现代网络应用程序往往有更快的发布和更新周期，使得直接提供 SBOM 数据变得不太现实。

同时，在云计算的大背景下，捕捉软件供应链的风险也有很大挑战。服务提供商不仅要跟踪他们负责生产的软件供应链中的元数据，还要跟踪支持应用程序的基础设施栈中的元数据，不管是在提供商的直接控制下还是来自某个外部服务提供商。许多应用程序还利用第三方服务，通过 API 向其他组织发送数据和请求。

捕获关于整个应用栈和第三方服务的有意义的元数据是我们正在进行的一些工作，但还没有标准化或足够成熟，无法跨组织实施。

NIST 对 "EO-关键软件 "的定义适用于基于云的软件，但 NIST 建议最初的实施阶段应侧重于 "内部软件"。

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

SBOM 的完整性和真实性

SBOM 的使用者会非常关注 SBOM 数据的来源的可验证性，确认它没有被改变。在软件领域，完整性和真实性最常通过签名和公钥来实现。随着 SBOM 的实施，会有一些现有的软件和元数据的完整性和真实性的措施可以被利用。

上面描述的一些 SBOM 数据格式可以明确地支持这些安全措施的采用，一些开源领域正在进行的工作正在优先解决来自开发环境的元数据的签名问题。这种机制应允许对某一软件的每个组件进行签名，并允许用户确定签名是否合法。完整性和真实性是许多政府机构的首要任务，特别是在国家安全领域。

漏洞与 SBOM

针对代码安全，SBOM 最主要的用例是识别软件供应链中的已知漏洞和风险。一些开发者可能会选择在 SBOM 中存储漏洞数据，并且几种 SBOM 数据格式都支持这种做法。

这种方法对开发者有明显的价值。然而，我们要知道 SBOM 数据主要是静态的。也就是说，它反映了某个时间点上的特定软件的属性。同时，漏洞数据是动态的，并随着时间的推移而不断变化。以前不被认为有漏洞的软件，随着新漏洞的发现，可能会“变得”有漏洞。除非有非常具体的条件和程序，否则不能认为 SBOM 中的漏洞数据是完整和最新的。SBOM 的数据很可能最终一定要与漏洞数据源相联。(然而这并不会限制向软件使用者提供漏洞、软件缺陷和风险信息的价值）。

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

依赖关系中的脆弱性和可利用性

该指导意见认为，软件供应链中有一些漏洞并不会使组织和机构面临风险，在 SBOM 中关注那些被认为不会对下游软件产生影响的上游有漏洞的组件，将浪费时间和资源，而且不能提供直接的安全利益。

建议

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

2、向此 SBOM 数据的下游用户做沟通，保证该漏洞不会使组织处于风险之中。这会把一个软件（有关的漏洞）和该漏洞的状态联系起来。社区将此称为“漏洞可利用性数据交换”，或 VEX（Vulnerability Exploitability eXchange）。VEX 的核心是交换某个软件是否受到某个漏洞的“影响”。在这种情况下，如果认为没有必要采取行动，那么状态就是“未受影响”。目前，VEX 正在作为通用安全咨询框架（Common Security Advisory Framework）中的一个配置文件来实施，它能够提供关于软件是否受漏洞影响的机器可读信息，并能链接到具体的 SBOM 数据中。其他实现方式也是可行的。建议 SBOM 数据分析工具应具备自动纳入 VEX 数据的能力。

系统遗留软件和二进制分析

从效率和效用的角度来看，SBOM 数据应该由供应商提供。然而，有时候这并不实际，也不是最好的选择。在某些情况下，甚至可能无法获得源代码，只有目标代码（object code）可用于生成 SBOM。实际上，这些没有被维护的软件可被利用的风险最大。老旧的软件面临着更大的不被维护的风险。遗留软件的代码库较老，而且经常被用于关键基础设施的重要部分，往往使透明度变得更加重要，特别是对于评估已知漏洞的风险。

从源码库中生成 SBOM，或者在构建软件的时候生成 SBOM，或者从已经构建好的软件中生成 SBOM，这些方式具有明显的区别。虽然有许多特殊情况，但要求 SBOM 数据的人应尽量从构建过程中获取，因为构建的实例捕获了软件构建的细节，包括反映编译器或其他工具的变化。

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

实施中的灵活性与统一性

在许多涵盖各种软件的安全领域，在灵活性和统一性的需求之间存在着基本的矛盾。这并不是 SBOM 所独有的。软件生态系统巨大的范围和规模导致了一系列特殊的考虑。这不仅包括软件用途之间的区别（例如：传统企业软件、嵌入式系统、容器化软件），还包括不同语言和工具的独特功能。同时，显然也需要一些融合和统一。任何组织机构都会因为处理各种不兼容的 SBOM 而产生巨大的花费。要想获得上述 SBOM 用例的种种优点，需要一些可预测性和统一性。

在整个生态系统中成功实施 SBOM，既需要广泛的规则和政策，也需要明确哪些领域是可以有灵活性存在的。这些领域的选择应考虑社区和机构的反馈意见。具体领域包括遗留技术和更高保障要求的软件，在这些领域，活跃和持续的安全威胁可能需要更详细的供应链信息和更严格的要求。

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

未来展望

鉴于 SBOM 是一种新兴的技术和实践，因此还有大量的工作要做，该指导意见给出了对于未来 SBOM 的新亮点的展望。SBOM 不会解决所有的安全或供应链攻击。比如最近在供应链上发生的几起很严重的攻击，其目标不是软件组件，而是用于管理软件开发和构建过程的工具和系统。针对这些威胁的相关的防御措施已经受到了重视并被部署到生态系统中。除了最基础元素中所规定的三个方面外，本指导意见对于如下几个方面做了展望。

1. 企业和组织要尽可能多的捕获整个软件生命周期的细节，并有加密做保证，以防被篡改。
2. 融入自动化的工具和流程很重要，同时也需要具备消化这些自动化流程的能力。
3. 提高 SBOM 的机器可读性，这其中涉及了专业的语义解读能力和数据的标准化和规范化。
4. EO 14028 中要求了其他与安全开发和软件供应链相关的安全步骤，这些步骤可能与软件开发有关，但最佳的方式是单独记录，并与 SBOMs 相关联。
5. 由于现代应用开发和云原生架构的独特性质，对于动态的依赖关系、第三方服务的调用和其他没有直接包含在软件构建中的依赖关系都需要纳入 SBOM 的范畴之中，确保不会因为误操作而引入漏洞。
6. SBOM 一定会不断创新，模块化结构可以最好地支持多样化的创新和适应性。
7. SBOM 不应独立于软件领域，也应与硬件数据联系起来。同时，硬件供应链的风险也具有自身的挑战，应考虑硬件特定的元数据，并与 SBOM 数据一起整合到整个供应链风险管理中。

该指导意见也列举了一些 SBOM 发展过程中所遇到的难题，比如：

• 不同生态系统之间软件身份与 SBOM 的分发。使用单一的命名空间看似可以解决这个问题，但是过于理想化，因为其中涉及扩展性、多样性等诸多障碍。
• 版本管理方法和系统的多样性问题亟待解决。这需要进一步的协调工作。
• SBOM 数据的中心化。这种方式的优点是：当 SBOMs 集中存储在一个可以被其他应用程序和系统轻松查询的存储库中时，会获得更大的价值，比如可以用来获得对组织、甚至生态系统或国家层面所面临的系统风险的更多信息。它可以通过让协调者了解哪些组织或供应商有潜在风险，从而促进漏洞披露。也可以了解哪些组件使用最广泛，或在最关键的部门，并优先考虑安全研究或加固方法。然而，有些人担心这些关键信息会被利用进行新的攻击。我们有必要进一步研究如何共享、保护和使用 SBOM 数据。

近期出现了一些针对更有效实现 SBOM 数据的发现、访问和自动获取的技术：

• 制造商描述符（Manufacturer Usage Descriptor）：一种允许设备在网络上交换自身的重要信息，包括网络功能，特别是本文件中的 SBOMs 的机制。
• 数字材料清单（Digital Bill of Materials）：是一种提供包括 SBOM 在内的开放式供应链数据的多种证明，以及围绕这些证明的共享和访问策略有关执行的解决方案。
• OpenC2：是一种标准化语言，用于提供或支持网络防御的技术的指挥和控制；现阶段，OpenC2 已经被利用来处理、加工 SBOM 数据并据此采取行动。

SBOM 要达成的目标还远远没有实现，需要通过不断地创新与迭代来完善，是一个长期的反复的过程。这就需要跨组织的探索来证明其可行性和可扩展性，最终由各部门和标准专家将技术和实践编入国际标准。本报告应被看作是一个起点，而不是最后的结论。

以上是我们深度解读《 SBOM 的最基础元素》的完结篇，如果您对我们的解读有任何建议或想法，欢迎交流讨论。

关于安势信息

上海安势信息技术有限公司致力于解决软件供应链中的安全和合规问题。作为中国市场领先的软件供应链安全治理工具提供商，安势信息以 SCA（软件组成分析）产品作为切入点，围绕 DevSecOps 流程，着力于从工具到流程再到组织，坚持持续创新，打造独具特色的端到端开源治理最佳实践。

清源(CleanSource) SCA，是安势信息研发的一款拥有完全自主知识产权的软件成分分析工具，能够帮助企业降低和管理其应用或容器中因使用开源软件和其他第三方代码（软件）引入的安全、质量与许可证合规性风险。目前安势信息已与国内多家高科技头部企业建立了深厚的合作关系。欢迎访问安势信息官网http://www.sectrend.com.cn或发送邮件至 info@sectrend.com.cn 垂询。

文章未经授权请勿转载。如有转载需求，请事先联系：marketing@sectrend.com.cn