聚焦源代码安全，网罗国内外最新资讯！

编译：代码卫士

美国总统在2021年5月份发布第14028号行政令，要求美国商务部在60天内协同美国国家通信和信息管理局 (NTIA)发布软件物料清单 (SBOM) 的“最小元素”。

如上概述了组成了软件供应链中SBOM 创建、维护和使用的“最小元素”特征。如所提到的那样，这是支持最基本用例所需的初始步骤和要求。扩展软件供应链中的透明度并支持软件保护的可见性需要做更多的工作。本节主要说明的是可支持更广泛 SBOM 用例的其它情况。

这些用例并未纳入最小元素集中，但并不意味着它们可被忽略；确实，其中一些元素对于成功有效地执行SBOM用例很重要，很多用例目前仍在生产中或者不久将进行一些改进或测试。寻求SBOM的组织机构应当坦然向供应商获取这些用例，在如下所列元素中，提出了一些具体建议。

推荐的数据字段

除了如上最小元素中提到的数据字段外，还推荐考虑如下数据字段，尤其是有着多年规划或要求更高安全要求的情况。在很多案例和上下文中，这些字段定义明确且已被执行；其它字段要求给出更多细则详情和清晰度。由于已被纳入最小元素中，尚未包含如下字段的数据格式必须将其包含进去，否则将面临降级风险。

组件的哈希。健壮的标识符对于将组件的存在映射到相关数据来源如漏洞数据来源而言起着重要作用。加密哈希将为协助这种映射提供根本元素，并有助于重命名和白名单实例。同时，哈希还可证明使用了某个特定组件。

虽然哈希可提高保证，但潜在目标的多样性使得实现在某种程度上是复杂的，可通过为客户提供足够多的详情来复刻原始哈希或为少数潜在实现复刻多个哈希。

组织机构可要求获得哈希用于SBOM中，尤其是关注于高保证用例的组织机构。建议这些机构指定要求提供应如何生成哈希的进一步详情。进一步定义并改进哈希生成和使用的最佳实践和标准细则应当成为 SBOM 社区的优先级任务。

生命周期阶段。关于软件组件的数据可在软件生命周期的不同阶段进行收集，如通过二进制分析工具在软件源、build 时间或build之后的阶段收集。由于每个阶段都具有唯一特性，因此根据创建数据的时间和位置不同，SBOM可能具有一些不同之处。因此可以通过某些方法说明SBOM数据记录的位置、时间和方法。正如下一章节“SBOM的未来”中提到的，这将最终记录更多的供应链数据。从短期来看，单单提到数据是如何捕获的（如“源”、“build”或”build 后“）将有助于使用和管理数据。

其它组件关系。SBOM 的最小元素通过一种关系连接：依赖。这种关系在SBOM 表结构中有所体现。也可以捕获其它依赖关系类型且它们已在某些SBOM标准中实现。目前可捕获的除了直接依赖之外是“派生“，这说明虽然一个组件类似于一些其它已知组件，但已做出了一些变更。它有助于追踪其共享的来源和内容。其它类型的依赖如下所述。

许可证信息。许可证管理是SBOM的早期用例，有助于使用大型复杂的软件产品的组织机构追踪多种软件组件尤其是开源软件的许可证和条款。SBOM可为每个组件传递许可证数据。这种数据也可使用户或需求方了解组件是否可在不触发法律风险的情况下用作其它应用程序的组件。

基于云的软件和软件即服务

很多现代软件应用程序都以服务的方式提供。对于SBOM数据而言它带来独特的挑战。由于软件并未在客户基础设施或在其控制下运行，因此风险管理角色是不同的。用户并不负责维护工作，也并不控制任何环境因素。了解和就漏洞或风险信息采取行动的责任在于服务提供商。此外，现代 web 应用程序的发布和更新周期通常更快，使得SBOM的直接提供不具实践性。

同时，捕获云上下文中的软件供应链风险的过程中也存在挑战。服务提供商不仅追踪所负责生产的软件供应链元数据，而且还负责追踪支持该应用程序的基础设施栈的元数据，不管它们是否受服务提供商控制或者源自某些外部服务提供商。很多应用程序还使用第三方服务，通过应用程序编程接口发送数据和请求。捕获关于完整应用程序栈和第三方服务有意义数据的工作虽然正在进行，但尚未被标准化或已足够成熟到可在不同组织机构实现。

虽然NIST 对“行政令-重要软件”的定义适用于基于云的软件，但NIST建议初始执行阶段应该关注“本地软件”。类似方法对于SBOM也是有价值的。

在短期，建议云服务提供商确认拥有内部SBOM，该SBOM 必须以与最小元素功能的等价体进行维护，尽管确切的格式和架构可能因提供商内部系统的不同而不同。组织机构也必须能够根据该信息采取行动并拥有及时处理的流程。随着时间的变化，将出现最佳实践，将SBOM数据集成到第三方风险管理和供应链风险管理的工具和流程中。与政府机构相关的一个用例是取证 SBOM 分析：云提供商是否能够判断某个特定组件是否为过去在某个时间所部署系统的一部分。

SBOM 的完整性和真实性

SBOM 客户可能会考虑验证SBOM数据的来源并确认数据未被修改。软件的完整性和真实性通常通过签名和公钥基础设施支持。随着 SBOM 实践的执行，可使用软件和元数据完整性和真实性的某些已有措施。如上所述的某些 SBOM 数据格式可直接支持目前的安全措施，而开源工作正在解决开发环境中签名元数据的优先级问题。同样，已有的软件签名基础设施可用于加密物料如公钥基础设施的工具和管理。

这些供应和请求SBOM的行为有助于探索签名SBOM和验证篡改检测的选择。这类机制应允许签名既定软件的每个组件并允许用户判断签名是否合法。完整性和真实性是很多政府机构的优先任务，尤其是在国家安全领域更是如此。某些SBOM数据用户可能坚持要求获取SBOM的数字化签名。

漏洞和SBOM

当前SBOM的主要安全用例是识别软件供应链中的已知漏洞和风险。某些开发人员可能选择将漏洞数据存储在SBOM中，且多种SBOM数据格式支持这一做法。这种方法对开发人员具有清晰的价值。然而，SBOM 数据主要是静态数据。也就是说，它反映的是某个节点所构建的特定软件的属性。同时，漏洞数据是动态数据并随着时间变化而变化。随着新漏洞的发现，之前认为不易受攻击的软件可能“变得”易受攻击。

SBOM 中的漏洞数据不应被视作是完整且最新，除非存在特定的条件和流程但在组织边界中不可能发生。SBOM数据最有可能和漏洞数据来源相关联（然而，这不会限制对软件客户提供的漏洞、软件弱点和风险信息价值）。

建议以不同于SBOM的单独数据结构追踪漏洞数据。随着这两种数据类型的发展以及技术的成熟，相关操作应当关注于这两种数据类型之间的映射和关联。如果在组织机构中共享了漏洞数据，那么漏洞数据和SBOMs 可使用类似的分发、访问控制和吸收模型。

依赖中的漏洞和可利用性

虽然软件漏洞是理解风险的一个关键组件，但并非所有漏洞都会置用户和组织机构于风险之中。在处理传递依赖时更是如此。并非组件中的所有漏洞都会对依赖它们的软件造成风险。某些厂商数据表明，比例较小的易受攻击组件会对软件所在环境造成安全影响。在SBOM上下文中，关注被认为不会对下游软件造成影响的上游易受攻击组件是对时间和资源的浪费，并不会带来立竿见影的安全好处。

解决这一问题分两个步骤。第一，供应商必须做出一些可靠判断，漏洞是否影响某特定软件。这么做的原因在于：编译器可能会删除组件中的受影响代码，该漏洞可能无法在执行路径中触及，存在直接插入的防护措施等等。这些判断可通过追踪内部依赖的产品安全事件响应团队 (PSIRTs) 执行。

第二个步骤要求向下沟通，和SBOM数据的下一个用户进行沟通，确认漏洞不会给组织机构带来风险。过程很直接，将与所讨论漏洞相关的软件和漏洞状态相关联。安全社区将其称为“漏洞可利用性沟通 (VEX)”。VEX的核心在于沟通既定软件是否受某漏洞影响。在这种情况下，如果认为不需要采取任何措施，则状态为“不受影响”。VEX 当前作为配置在常见安全公告框架中执行。该框架可提供关于软件是否受某漏洞影响的信息并链接到特定的SBOM数据。也可采取其它实现。建议分析用于客户build 的SBOM 数据的工具自动集成VEX数据。

遗留软件和二进制分析

从效率和效用角度来看，SBOM 数据应由供应商提供。然而，并不一定总能实现这一点且也并非最佳选项。在某些情况下，可能甚至无法获取来源，而只能获取用于生成 SBOM 的对象代码。未被维护的软件存在被利用的风险。老旧软件存在不被维护的风险。遗留软件就是更老旧的代码库，且常用于关键基础设施的重要部分，使得透明度尤为重要，尤其是对于评估已知漏洞的风险而言而是如此。在这些案例中，二进制分析工具可更好地理解系统中的组件和依赖。二进制分析也可用于验证 SBOM 内容或有助于弥合 SBOM 数据中的差距。

尽管如此，构建软件时与已构建软件后如何从源代码库中生成 SBOM存在关键区别。虽然存在很多独特的情景，但请求SBOM 数据的组织机构应当尝试从build 实例获取该数据，因为build 实例捕获已构建软件的详情，包括反映编译器或其它工具做出的变更。

实现的灵活性和统一性

在涵盖多种软件和上下文范围的安全领域，灵活性和统一性之间存在根本的对立关系。这种情况并非 SBOM 独有。单是软件生态系统的范围和规模就导致一系列独特的需要考虑的地方，不仅包括软件使用方面的重大差异，还包括不同语言和工具的唯一特性。同时还需要一些融合性和统一性。处理不易兼容的大量 SBOM 实现会造成大量成本。拥抱SBOM 用例好处时要具有某种可预见性和和谐性。

在生态系统中成功执行SBOM 要求具有广泛的规则和策略，也要求明确证实的某些特定的灵活性领域。对于美国政府而言，这些领域应该反映社区和机构利益相关者的反馈。特定领域包括遗留技术和更高保证的软件，其中活跃的和正在发生的威胁或许要求更详细的供应链信息和更严格的要求。

最后，构建于最小元素之上的所有要求都应当从两个关键概念中得到一些启发。首先，所有安全尤其是SBOM是一个过程而非唯一目标。第二 ，SBOM 背后的根本原则是透明度的力量，任何规则或指南都应关注本文档及其它地方所描述的用例。

正如本文档中想要强调的那样，SBOM是一种新技术和实践。虽然组织机构目前正在执行 SBOM 但更多的工作需要做。如下建议并非对未来SBOM工作的限制或对其潜力的完全枚举。这些建议是行业和政府专家所关注的。

尤其有必要强调的一点是，SBOM 将不会解决所有的安全或供应链攻击问题。最近发生的重大供应链攻击虽然并未针对软件组件，但针对的是用于管理软件开发和build 流程的工具和系统。应当讨论甚至在生态系统的某些地方部署应对这些威胁的防御措施。

保护软件供应链安全的更全面的基础是，通过加密保证，安全捕获软件生命周期中的详情。虽然SBOM的最小元素启动了这一流程，但需要做的还有很多。虽然捕获更多元数据是有用的，但对数据的有效使用要求自动化，而自动化要求自动化使用和策略执行的潜力。它不仅要求机器可读性，还要求语义解释，而这将要求在数据细则和标准方面采取进一步行动。

某些数据将自然适合SBOM方法，包括关于个体组件的起源和来源，追踪组件来源及其在软件生命周期中的监管链。其它类型的数据包括美国总统行政令14028中提到的其它安全开发和供应链安全步骤，可能和软件开发相关，但通过SBOM 能够更好地单独进行追踪和关联。

现代应用开发和云原生架构的独特性质也值得对软件透明度进行考虑。某些现代软件执行涉及动态依赖、对第三方服务的调用以及软件构建中未直接包含的其它依赖。依赖包含确保软件按计划运营，漏洞并非因滥用而引入。未来需要完全描述这种数据并协助自动化解释和使用。

文档中讨论的很多问题都值得进一步提炼，包括软件身份和 SBOM 分发等。由于SBOM是一种新型技术，供应商仍然在学习如何和客户分享该数据。好在很多供应商已经拥有和下游用户沟通的可信渠道，包括软件更新和支持等，虽然并未所有都已自动化或具有灵活性。目前已经出现了或正在开发一些信技术，比如“制造商使用描述符 (Manufacturer Usage Descriptor)”机制、数字化物料清单解决方案、OpenC2 标准语言等。SBOM 也可由一些可信第三方处理，不过这种方法存在集中化的优劣势。

SBOM 不应被视作独特的安全现象，而是可支持供应链保护的更广范围的一种实践。除了可将该数据链接到软件领域的更多供应链数据外，该数据也可关联硬件数据。

最后，随着SBOM技术、工具和实践变得成熟，标准组织机构应当考虑将它们集成到自愿的、共识性标准中。正如在最小元素讨论中所提到的，SBOM 覆盖特定数据和组织机构实践。不断迭代以证实是否起作用以及促进快速创新。鉴于SBOM的跨组织性质，有必要在锁定为正式标准前展示可行性和扩展性。然而，行业和标准专家应当在广泛实现的基础上将该技术和实践整理为国际标准。

本报告仔细思考了政府、私营行业和学术界利益相关者的内容后编写而成。SBOM 的最小元素是一个起点。判断SBOM最小元素的构成工作不应止步于此。随着“最小元素之外” 和 “未来的SBOM工作“章节中提到的其它元素变得可行、经过验证并被构建于工具中，它们也应当被增加到最小元素中。

这些最小元素将成为联邦政府改进软件供应链安全性和完整性的关键输入，尤其对于关键软件而言更是如此。行政令14028中定义了余下步骤，尤其呼吁制定特定指南，包括“标准、程序或准则”。为支持并补充这项工作，联邦政府应当鼓励或开发关于如何执行 SBOM尤其是牵涉行业特定或技术特定详情的资源。构建并扩展已有的、关注于定义并运营SBOM相关供应链工作的公私合作伙伴关系将发挥重要作用。

最后，定义SBOM的最小元素是一个迭代过程。某些元素未列入其中只是因为它们对于大多数利益相关者而言尚不可行。然而，在不远的未来，这些元素也将变得可行。本报告应当被视为一个起点而非定论。

（完）