政策法规组|【SBOM政策文件研究】之《SBOM的最小元素》译文

2021年7月21日，根据《关于提升国家网络安全行政令》(14028号)指示，美国商务部与国家通信和信息管理局（NTIA）合作发布《SBOM的最小元素》。SBOM 是一份包含多个软件构建组件详情及供应链关系的正式记录。除了确定最小元素外，该文件还定义了如何考虑最小元素的范围，描述了为提高软件供应链透明度而采取的SBOM用例，为今后发展提供了备选方案。

SBOM 为生产、购买和操作软件的人员提供信息，有助于他们了解供应链，并从中获得多重好处，尤其是追踪已知的或新出现的漏洞和风险。SBOM虽然无法解决所有的软件安全问题，但它会形成一个基础数据层，为后续安全工具、实践和保证构建基础。本文所述“最小元素”是支持基础SBOM功能的必要部分，且将会成为软件透明度进一步发展的基础。

除了作为未来工作重要项目的最小元素外，本文还阐述SBOM的功能与发展趋势。比如 提高SBOM完整性或其追踪供应链数据的能力。SBOM的最小元素可分为以下三类，它们包含甚广且相互关联。

美国政府将SBOM视为推动软件质量保证和供应链风险管理的优先项。该文件发布后，下一步将按照行政令指示支持为软件购买方提供 SBOM，并继续开展公私营伙伴关系合作，以完善和落实SBOM工作。

2021年5月12日，美国总统发布了《关于提升国家网络安全行政令》（14028号）¹。该行政令聚焦于通过以下方式实现网络安全防护现代化：保护联邦网络，促进美国政府和私营部门就网络问题的信息共享，加强美国应对突发事件的能力。该行政令指示商务部协同通信和信息部、NTIA局长，在60天之内公布SBOM的最小元素。

该文件指出，NTIA从2018年起就关注SBOM事宜，当时就软件组件透明度召开了一个公开透明的多方利益相关者流程。NTIA作为流程发起方和中立方，集合了来自世界各地软件生态系统的专家。该流程的成果为这次活动提供了宝贵的思想见解和背景材料，并按照 《关于提升国家网络安全行政令》指示，提出了SBOM最小元素的相关建议。

该文件定义了SBOM的最小元素。这些最小元素建立SBOM内容的基线技术和实践办法之上，这对于实现14028条行政令所提到的目标是必要的。该文件回顾了如何扩展基础性内容，提供了如何平衡可预测的 SBOM格式和灵活性需求之间关系的指南，具体取决于所需技术和用户需求。

软件生态系统当前面临着多种软件供应链和软件保障方面的隐忧⁵，SBOM本身也无法消解。SBOM有助于更好更快地对漏洞进行响应。给定软件中已知漏洞的数量由其安装基数、研究社区和供应商披露流程以及产品安全团队决定。漏洞披露得越多，软件的使用风险可能就越低，因为这说明研究人员正在关注着软件，而供应商正在管理披露流程。

SBOM是基于已识别漏洞的起始点。在当前环境被视作可行的最小元素不会捕捉围绕软件源处理和使用的所有元数据。其中某些数据将被纳入SBOM数据的未来扩展中。同时，SBOM不会是供应链安全或软件保障的唯一资源或机制。对很多用例来说，其他数据也相当有价值，他们应被视作独立于SBOM且与它互补的部分。与其将SBOM作为所有软件保障和供应链数据的唯一模型，不如鼓励采用可连接、模块化的方法，使其应用灵活性和使用潜力发挥到最大。可连接性使SBOM数据更容易被映射到其它重要的供应链数据中，软件供应链的透明度和管理数据与工具逐渐成熟使得模块化架构支持能扩展至更多的用例中。

该文件并未讨论软件供应链的某些关键点，如监管问题和采购要求等。最小元素不应被解读为设立新的联邦要求。集中化或收集SBOM数据以便运营、为威胁情报服务或作研究之用的潜在好处尚未证实。“软件物料清单”的名称本身就将硬件排除在外。虽然在硬件和设备中嵌入的软件肯定在考虑范围之内，但与硬件相关的关键供应链和安全问题特殊且复杂，需要单独处理，该文件并未覆盖。

最后，该文件不应被视作对 SBOM的使用或对软件生态系统中创新和探索的限制。最小元素只是起始点。从更广范围来说，该文件只是说明了SBOM过程中关键的初始步骤，它将会随时间改进而成熟。

SBOM的最小组成部分，即“元素”，是三个宽泛又相互关联的方面。最小元素包括的三个类别是：数据字段、自动化支持和实践和过程。这些元素使软件透明度不断发展，涵盖技术捕获和功能操作。后续将重点纳入更多细节或技术上的提升。如上所述，这些目前只是最小元素；组织机构可能需要更多信息，而软件供应链中的透明度可能会随时间变化而得到改进和演变。

软件可表示为由多个可拥有子组件的组件组成的层级树。组件通常是其它来源的 “第三方”，但可能也是 “第一方” ，即来自同一个供应商，但可被唯一识别为独立可追踪的软件单元。每个组件都应当拥有列出自身组件的SBOM，以构建层级树。数据字段适用于每个组件，这些组件按照定义的实践和流程，由自动化支持的工具和格式进行编码。

SBOM是一个连续的、统一的结构，捕获并展示用于理解软件组件的信息。数据字段包括每个应被追踪和维护的组件的基线信息。这些字段的目标是要充分识别这些组件，以便在软件供应链中进行追踪，并将其映射到其它的有用数据源，如漏洞数据库或许可证数据库。该基线组件信息包括：

大部分字段能协助识别组件，直接使其映射到其它数据源。软件缺少唯一的、便于理解并广泛使用的名称空间这一缺点为软件管理带来很大挑战⁶。最佳实践是尽可能使用现有标识符，如不存在标识符，则使用现有组件识别系统。

“供应商”是指软件组件的创始人或制造商。“组件名称”由供应商决定。如有可能，应支持对供应商和组件名称注记多个名称或别名的能力。 “供应商名称”和“组件名称”是支持识别的人类可读字符串，尽管软件生态系统的某些特性（如企业并购和开源分叉）使得很难做出普遍且永久性解决方案。

软件版本所带来的复杂性再次说明，软件生态系统中的多样性需要建立灵活的组件识别方法。不同类型的软件或软件供应商追踪版本和分发的方式也不同。这个问题的解决方法超出了本次SBOM的初始讨论范围⁷。最小元素由供应商提供，因为供应商对追踪与维护软件负最终责任。期望版本字符串的功能是识别指定的代码。虽然存在版本控制的最佳实践（如语义版本⁸），但它目前尚未普遍流行。

“其它唯一标识符”支持自动化将数据映射到数据使用和生态系统中，且可增强不确定性实例中的确定性。常用唯一标识符的例子有：通用平台枚举（CPE）⁹、软件识别标签（SWID）¹⁰和包统一资源定位器（PURL）¹¹。

“依赖关系”反映软件包含中的指向问题，它能够表示软件到组件再到其潜在子组件的传递性。最后，SBOM特有元数据会有助于追踪SBOM本身。

“作者”反映元数据的来源，元数据可能源自上游组件供应商、SBOM描述的软件创始人或某些第三方分析工具。需要注意的是，这里的作者并非软件本身的作者，而只是描述性数据的来源。

“时间戳”记录了数据集成的时间，即SBOM的创建时间，时间戳有助于识别SBOM的更新版本。数据字段则向SBOM数据源提供了环境，且可能被用于做信任判断。

自动化支持包括自动化生成和机器可读性，可以使SBOM的能力扩展至软件生态系统，尤其是可以到组织边界。利用SBOM数据要求工具可预测实现和数据格式。例如，某些机构可能希望将该能力融入到现有的漏洞管理实践中；有些机构可能要求对安全策略的合规性进行实时审计。自动化是这两者的关键点，因此需要通用且机器可读的数据格式。

虽然单一标准意味着简约高效，但生态系统中存在多种数据格式，而且它们正在被用于生成和使用SBOM。这些数据格式规范已经通过开放流程和国际力量制定形成。除了机器可读外，这些数据格式也能使人类可读，可以更好地支持故障排除和创新。更重要的是，这些标准对于核心数据字段而言具有互操作性，而且使用了常见的数据语法表示。

用于生成和使用SBOM的数据格式包括：软件包数据交换（Software Package Data eXchange（SPDX））¹²、CycloneDX¹³和软件识别 (Software Identification (SWID)) 标签¹⁴。

SBOM必须以一种可互操作格式¹⁵在组织间传递。如果出现可与其它数据格式兼容的新规范，那么它就应当被包含进SBOM最小元素的自动化支持中。同样，如果某种数据格式被广泛认为不再交叉兼容，或者不再被SBOM用例主动维护和支持，那么应当将这种数据格式从SBOM最小元素自动化要求中删除。使用专有数据格式的标准也不应当包含在内。这样就能实现基于现有工具的易采用、可演变和可扩展。

SBOM不止是结构化的数据集，要将其集成到安全开发生命周期中，组织机构应当遵循某些侧重SBOM使用机制的实践和流程。在任何要求提供或主动提供SBOM的政策、合同或约定中，都应当明确处理若干元素。越来越多的实践正处于开发过程中，因此某些合同或约定具有最小元素要求。

如果软件组件发布了新构件或有更新版本，那么必须创建新的SBOM 来反映该软件的新版本。其中包括集成更新组件或依赖的软件构件。同样地，如果供应商获悉关于底层组件的新细节，或者希望修正现有SBOM数据中的错误，那么供应商应当发布一个新的、经过修订的SBOM。

SBOM应当包含所有主要（顶层）组件，并列出其中包括的所有传递依赖。至少，必须要列出足够多所有顶层依赖的细节，以便以递归方式查找传递依赖。

随着组织开始建立SBOM，除主要组件以外的深度可能无法轻易获得。而最终采用SBOM流程，能使在子组件层面上通过更深层次的透明度进行更深度访问。应当注意的是，某些用例要求完整的或基本完整的SBOM图，比如 “举反证”，证明某既定组件不存在于某机构网络中。

SBOM消费者可通过传递步骤的数量来指定深度要求，或者在操作方面指定深度要求。可以包括软件属性，如“所有非开源软件”，或者某个函数或复杂度的所有组件。组织机构还可以通过对SBOM所列组件中漏洞的报告和补救提出不同要求，以此激发报告更高的深度和完整性。这类规范不在最小元素范围内。

对于在SBOM中未枚举出完整依赖表的实例，SBOM作者必须明确识别出“已知的未知”。也就是说，依赖数据能在不含其它依赖项的组件和依赖项未知且不完整的组件之间进行明确区分。该数据必须集成到自动化数据中。为了避免错误假设，数据的默认解释应该是数据是不完整的；SBOM 数据的作者应当明确声明组件的直接依赖项是否已被完全枚举，或组件是否不含其它依赖项。目前，这已在依赖关系数据字段中得到应用。

SBOM应当及时提供给需要它们的人，而且必须设置恰当的访问权限和职责范围。SBOM数据可搭配每个软件实例，或者只能访问并直接映射到所指软件的特定版本（例如，通过特定版本的URL）。在软件供应链中共享SBOM 数据可分为两个部分：如何获悉SBOM的存在和可用性（宣传或发现）和SBOM如何被具有适当权限访问的人员检索或传递给他们的。SBOM交付也可以反映软件的性质：位于端点上的可执行文件可通过编译代码将SBOM数据存储在磁盘上，而嵌入式系统或在线服务则可以存有指向在线存储的SBOM数据指针。

很多供应商，包括开源维护人员和拥有广泛可用软件的供应商，可能会认为将SBOM数据公开是最符合自身利益的。不过其它一些组织机构，尤其是刚开始，他们可能会希望SBOM数据保密，并限制特定用户访问。如果需要访问控制，则必须指定相关条款规定，包括将SBOM数据集成到用户安全工具中的费用和空间。这类规范可通过许可、合约或其它现有机制来确定软件本身的使用和权益。鉴于软件许可和合约不尽相同，该规范的性质不在该文件讨论范围内。

容错空间应当建立在SBOM的初始实施阶段，指允许遗漏和错误。虽然供应链数据内部管理可能是一种最佳实践，但这种管理尚处于发展当中。拜登政府已经将SBOM列为推动软件保障和供应链风险管理的优先事项，目前SBOM模型并不完美，消费者应该对偶然出现的的遗漏和错误持有宽容态度，这样有助于工具的不断改进：供应商在发现之前的SBOM出现问题时，应当及时更新数据，消费者应当鼓励这些更新，并欢迎补充和修正，而不是实施处罚。但有意混淆或装作无知不应得到容忍。

前几章内容介绍了软件供应链中组成SBOM创建、维护和使用的“最小元素”特征。这些是支持最基本用例所需的初始步骤和要求。扩展软件供应链的透明度，以及支持软件安全可见性方面，仍需要做更多的工作。本章主要介绍可支持更广泛 SBOM用例的其它情况。

这些用例未纳入最小元素集中并不意味着它们可以被忽略。事实上，一些用例对成功有效地执行SBOM用例很重要，还有很多用例目前仍在生产中，不久后将进行改进或测试。寻求SBOM的组织机构应当坦然向供应商获取这些用例。

除了最小元素中提到的数据字段外，还推荐考虑以下数据字段，尤其是有更高安全需求的情况。在很多案例和情境中，这些字段定义明确且已被执行；由于这些字段已经被添加到了最小元素中，因此尚未包含如下字段的数据格式必须将其包含进去，否则将面临降级风险。

当提到某款软件时，可靠的标识符对于将组件存在映射到相关数据来源（如漏洞数据来源）来说很重要。加密哈希将提供一个根本元素来协助这种映射，并在重命名和白名单的实例中提供帮助。

同时，哈希还可证明使用了某个特定组件。消费者能对组件哈希和一个已知且可信的版本进行比较，这能帮助验证“受批准的”组件版本的使用，对于识别组件是否以未正式授权的方式被更改也很有必要。另外哈希是使用SBOM在软件供应链中产生信任的关键基础，在某些情况下，哈希可能无法传递值，或传递的值相对较少。如果组件信息是从一个没有直接访问底层组件( 例如二进制分析工具 )的工具中获取的，那么组件作者可能无法可信地确定所使用的精确位，从而无法生成哈希。

虽然哈希可提高可信度，但潜在目标的多样性使得执行实施在某种程度上是复杂的。一个文件是简单易懂的，但是一个可执行文件与源包相比，会有一些不同，不同的哈希算法当然会产生不同值。为解决这一问题，可以为消费者复制原始哈希提供足够多细节，或者为少量潜在性实施提供大量哈希值。 

组织机构可以要求获得哈希以用于SBOM中，尤其是关注高保障用例的组织机构。建议这些机构详细说明更多如何生成哈希的细节。进一步定义并改进哈希生成和使用的最佳实践和规范应当成为 SBOM社区的优先任务。

可以在软件生命周期的不同阶段收集软件组件数据，包括从软件源、构建时或构建后的阶段通过二进制分析工具进行收集。由于每个阶段都具有唯一特性，因此SBOM可能会因创建数据的时间和位置而存在一定差异。例如，编译器可能会拉入一个与原版预期略有不同的组件版本。出于这个原因，如果有一些方法可以便捷地传递记录SBOM数据的位置、时间和方式，那就很有帮助了。正如下一章节“SBOM的未来”中提到的，这可使更多的供应链数据得以记录。从短期来看，单单说明这个数据是如何捕获的（例如，“源码级”、“构建时”或“构建后”），就有助于使用和管理数据。

SBOM的最小元素通过一种单一的关系连接：依赖关系。即X包含于Y。这种关系隐含在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中，关注不会对下游软件造成影响的上游易受攻击组件，是浪费时间和资源的体现，并不会带来立竿见影的安全性好处。

解决这一问题分两个步骤。第一步，供应商必须做出一些可靠判断，即漏洞是否影响某特定软件。原因在于编译器可能会删除组件中已受影响的代码、漏洞可能在执行路径中无法触及，或者内嵌防护措施的存在等。这些判定目前已经由产品安全事件响应团队（PSIRT）通过追踪内部依赖关系圆满执行。

第二个步骤要求和SBOM数据的下游用户进行沟通，确认漏洞不会给组织机构带来风险。这个过程很简单，连接软件（相关漏洞）和漏洞状态即可。社区将此称为“漏洞可利用性交换(VEX)”。VEX的核心是：沟通给定软件是否受到给定漏洞的影响。在这种情况下，如果认为不需要采取任何措施，则状态为“不受影响”。目前VEX 作为通用安全咨询框架¹⁹中的配置文件来实施。该框架能使机器读取有关软件是否受某漏洞影响的信息，并可以链接到特定SBOM数据。也可以采用其他实施方法，建议为客户分析 SBOM数据的工具内置自动合并 VEX 数据的功能。

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

尽管如此，在构建软件时从源码库生成SBOM的方法与为已构建软件生成SBOM的方法之间依然存在关键区别。构建实例捕获了所构建软件的细节，请求SBOM数据的组织机构应当尝试从构建实例获取该数据，包括反映出编译器或其它工具做出的任何改变。

在许多涵盖多种软件和环境的安全领域，在灵活性和统一性的需求之间存在根本的对立关系。这种情况并非 SBOM独有，单是软件生态系统的范围和规模就导致一系列独特的考虑事项，不仅包括软件使用方面的重大差异（传统软件、嵌入系统、容器化软件），还包括不同语言和工具的独特性。同时还需要一些融合性和统一性。任何组织需要高额成本来处理大量不易兼容的 SBOM实践。联邦政府和机构也不例外。要实现上述发展趋势，SBOM需要具有一定的可预见性和协调性。

在整个生态系统中成功实行SBOM，既需要广泛的规则和政策，也需要明确承认某些灵活的特定领域。对于美国政府而言，这些领域的选择应当反映出社区和机构利益相关者的反馈。特定领域包括遗留技术和更高保证的软件，其中持续活跃的威胁可能需要更详细的供应链信息和更严格的要求。

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

该文件中始终在强调SBOM是一种新生技术和实践。组织机构目前正在实行SBOM， 但未来还有很多工作需要开展。以下建议并不是要限制未来的工作或完全列举SBOM的潜力。相反，这些建议是行业和政府专家关注的重点所在。

有必要强调的是，SBOM无法解决所有安全问题或供应链攻击问题。最近发生的一些重大供应链攻击并未针对软件组件，针对的反而是用于管理软件开发和构建流程的工具和系统。因此，应当讨论应对这些威胁的防御措施，甚至在生态系统某些地方展开部署防御措施。

确保软件供应链安全的更完整的方法的基础是用加密保证安全地捕获整个软件生命周期的细节。SBOM的最小元素开启了这一流程，但还有更多的工作要做。单纯捕获更多元数据是有帮助的，但要想实现有效地使用这些数据需要实现自动化，而自动化需要自动化用例和执行策略。这不仅需要机器可读性，还需要语义解释，这反过来又需要在数据规范和标准化方面进一步努力。

某些数据会自然而然地适合SBOM方法，这包括单个组件的出处和谱系数据，追踪各个组件来源，以及它们在软件生命周期中的监管链。其它类型的数据（比如14028号行政令中提到的一些其它安全开发和供应链安全步骤）可能和软件开发相关，但通过关联SBOM能更好地进行单独追踪。

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

值得注意的是，为了这个目标付我们做出了一些努力，目前有几项这方面的努力正在开发中，还有几项在过去已经尝试过，取得了不同程度的成功和长久的发展。如第三章“范围”所述，模块化架构最能支持多样化的创新和适应。

文件中讨论的很多问题都需要进一步的完善，包括软件标识和 SBOM分发等。软件标识仍然是一个难题，尤其是跨生态系统的标识。尽管理想情况下希望实现一个单一且广泛使用的命名空间，但诸如扩展、多样化，以及供应商的不断演进的格局等问题使得实现这种理想情况还很有难度。多样化版本方法和系统也阻碍了SBOM可扩展自动化，并带来了一些安全数据相关的问题。进一步的协调工作能帮助每个供应商识别并管理其标识命名空间，也可以协调不兼容的标准和实践。

由于SBOM是一种新型技术，供应商仍在学习如何和用户共享数据。很多供应商已经拥有和下游用户沟通的可信任渠道，包括软件更新和支持等，但并未实现完全自动化或具备理想灵活性。目前已经出现了或正在开发一些很有前景的信息技术，可能会赋能发现、访问和自动化提取。还有一些技术值得注意，比如“制造商使用描述符 (Manufacturer Usage Descriptor)”机制、数字化物料清单解决方案、OpenC2 标准语言等。其中，制造商使用描述符可允许设备在网络上通传其自身的重要信息包括网络功能²⁰。尤其是对于该文件²¹，“数字化物料清单”是一种解决方案，它支持开放式供应链数据的多重认证（包括SBOM），也支持围绕这种认证²²执行共享和访问策略。OpenC2是一种用于命令和控制技术的标准语言，用于提供或支持网络防御。目前已经在使用它来处理施行SBOM的数据²³。

SBOM也可以由一些受信任的第三方来处理，这会带来很多因为依赖于中心化而产生的优缺点。与之相关的挑战包括信任和资金来源。有人提出中心化的一个附加好处是“当SBOM被集中储存在一个易被其他程序和系统获取的储存库中时，它就能发挥更大价值²⁴。”这可以用于更深入地了解组织、甚至生态系统或国家本身面临的系统性风险。SBOM通过告诉协调者哪些组织或供应商正处在风险当中以便于披露漏洞。集中的数据可以帮助参与者了解哪些组件得到最广泛使用，或者是哪些组件在最关键的部门，从而优先考虑安全研究或强化实践。然而，有人担心竞争者可能会利用这些关键组件进行新式攻击。深入研究并了解共享、保护和使用SBOM数据的最优结构和激励机制是很有必要的。

SBOM不应被视作一种独特的安全现象，而应将其看作是支持更广泛供应链保障的另一种实践。除了将这些数据与软件领域的更多供应链数据联系起来外，这些数据还可以和硬件数据关联。硬件提供了硬件信任根的特点和更大的端到端保证。同时，硬件供应链的风险也给自身带来了挑战，应考虑硬件特定的元数据，并将其与SBOM数据一起集成到整个供应链风险管理中。

最后，随着SBOM技术、工具和实践的成熟，标准组织机构应当考虑将其集成到自愿的基于共识的标准中。正如在最小元素讨论中所提到的，SBOM覆盖了特定数据和组织实践，这些都是以不断迭代的方式开发以证实什么是有效的，从而促进快速创新。鉴于SBOM的跨组织性质，有必要在将其锁定为正式标准之前证明其可行性和扩展性。然而，随着其广泛成功实施的证据逐渐积累，各部门和标准专家应将该技术和实践编入国际标准。

该文件是由美国联邦政府、私营部门和学术界各利益相关者经过仔细考虑之后编写而成。基于目前可以想象到的情况，SBOM的最小元素只是一个起点，确定SBOM最小元素的构成工作不应止步于此。随着上文中“最小元素之外” 和 “SBOM的未来”章节中确定的其它元素也变得可实行，且经过验证并被纳入工具中，它们也应当被添加到最小元素中。

这些最小元素将成为联邦政府改进软件供应链安全性和完整性的关键投入，对于关键软件而言更是如此。14028号行政令中规定了下一步工作，特别是要号召制定具体的指导，包括“标准、程序或准则”²⁵ 。为了支持并补充这项工作，联邦政府应当鼓励或开发关于如何执行 SBOM，可能会涉及特定行业或特定技术的细节。重要的是，要在已有的公私伙伴关系的基础上，建立并潜在地扩大这种伙伴关系，这种关系的重点是界定和运营SBOM相关供应链工作。

最后，定义SBOM的最小元素是一个迭代过程。清单中略去某些元素，只是因为它们对于大多数利益相关者而言不具实操性。然而，在不远的未来，这些元素很可能具有可行性。该文件应当被视为一个起点，而不是最后的定论。

END