专栏·供应链安全

数字化时代，软件无处不在。软件如同社会中的“虚拟人”，已经成为支撑社会正常运转的最基本元素之一，软件的安全性问题也正在成为当今社会的根本性、基础性问题。

随着软件产业的快速发展，软件供应链也越发复杂多元，复杂的软件供应链会引入一系列的安全问题，导致信息系统的整体安全防护难度越来越大。近年来，针对软件供应链的安全攻击事件一直呈快速增长态势，造成的危害也越来越严重。

为此，我们推出“供应链安全”栏目。本栏目汇聚供应链安全资讯，分析供应链安全风险，提供缓解建议，为供应链安全保驾护航。

注：以往发布的部分供应链安全相关内容，请见文末“推荐阅读”部分。

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

一、概要

SBOM 是包含多个软件构建组件详情及供应链关系的正式记录。除了设置这些最小元素外，本报告还定义了如何思考最小元素的范围，描述了SBOM用例以便提高软件供应链中的透明度，另外提供了未来的SBOM发展。

SBOM 为生产、购买和运营软件的人员提供信息，有助于他们了解供应链并从中获得多重好处，其中最值得注意的好处就是追踪已知的和新出现的漏洞和风险。SBOM 虽然无法解决所有的软件安全问题，但将形成基础的数据层，是后续安全工具、实践和保证的构建基础。本文档中所述“最小元素“是指支持基础SBOM功能的重要信息且将成为实现更高软件透明度的基础。这些最小元素组成了三大宽泛且相互关联的分类。

本文档识别将赋能基本用例的最小元素，如漏洞管理、软件清单和许可。同时，除了最小元素外，本文档还推荐一些可作为未来工作重点的 SBOM 特性和发展，包括关键的安全特性如 SBOM 完整性，并追踪更详细的供应链数据。随着更多 SBOM 元素变得可行、经过测试并构建到工具中，它们将赋能更广范围的用例。其中一些令人鼓舞的元素正在实现或者已经展示出巨大潜力。

美国政府将 SBOM 视为推动软件质量保证和供应链风险管理的优先任务。本报告发布后，下一步即是按照行政令要求为软件购买方提供 SBOM 的开发指南以及公私营合作，重新定义并投入SBOM工作。

二、背景

文档指出，NTIA 从2018年起就关注 SBOM 事宜，非常重视软件组件的透明度。使供应链的组件和连接透明化对于发现并解决薄弱链条问题起着重要作用。SBOM 是保护软件供应链的重要一步。否则，系统贡献者、成分和功能缺乏透明度，将造成重大网络安全风险并增加开发、采购和维护成本。

达成透明度的最佳方法是使用行业支持的可理解模型。SBOM 模型通过追踪组件元数据、映射至其它信息来源，以及在元数据转移至供应链并部署时和软件捆绑的方式达成这种系统化分享。为将这一模型扩展到全球，就有必要解决全面识别并定义某些软件组件，使数据能被下游用户有效使用。

识别软件组件是SBOM 的核心所在。SBOM 数据适用于各种简单或复杂的目标，如映射到漏洞数据库、通过关联并分析多个数据来源的方式监控所包含开源软件包中的特定威胁等。在这两种情况中，可能仍然需要外部数据。SBOM 是使相关外部数据映射到软件产品中的必要粘合剂。

SBOM 对于软件厂商、需求方和运营方而言起着重要作用。它可使用户理解软件生态系统并为用户带来好处。例如软件厂商和运营方可将SBOM用于清单、漏洞和许可管理中，而需求方可将其用于风险评估（许可证和漏洞分析）中。

SBOM给软件厂商带来的好处包括，确保组件是最新版本并使其快速响应新漏洞。除此以外，SBOM 还提供除安全性以外的其它好处，如通过可见性提高效率、提升效果，从而赋能优先级处理和更好的管理。例如，SBOM 可协助软件厂商知晓并遵循许可义务。

在漏洞管理方面，SBOM 数据通过提供软件生态系统内依赖透明度，帮助软件厂商和运营方更快更准确地评估与和新漏洞相关的风险。因此，SBOM 提高了漏洞识别能力和响应速度。

了解软件供应链、获取软件组件中的综合 SBOM 数据、并将其用于识别和分析已知漏洞和潜在缓解措施对于管理风险而言至关重要。而只有通过机器可读的、支持自动化和工具一体化的 SBOM以及应用程序查询和处理该数据的能力才能实现上述目标。

三、范围

本文档设立了SBOM的“最小元素“。这些最小元素将建立SBOM内容的基础技术和实践，对于实现总统行政令中提到的目标而言是必要的。本文档还审查了如何扩展这些基础并为平衡可预见的 SBOM 格式和灵活性需求提供了一些指南，具体取决于所需技术和客户需求。

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。通过开放流程和国际力量，已形成这样一些数据格式细则。除了机器可读外，这些数据格式也是人类可读的，能更好地支持故障排除和创新。更重要的是，这些标准对于核心数据字段而言具有互操作性，而且使用常见的数据句法表示。

用于生成并使用 SBOMs 的数据格式为：

• 软件包数据交换（Software Package Data eXchange (SPDX)）

• CycloneDX

• 软件识别 (Software Identification (SWID)) 标记

SBOM 必须以其中一种可互操作格式在组织边界中传达。如果出现新的可与其它数据格式兼容的标准细则，那么就应当在SBOM最小元素上下文，把这些标准细则归到自动化支持中。同样，如果广泛认为某种数据格式不再交叉兼容，或者不再得到主动维护并支持SBOM用例，那么就应当将这种数据格式从SBOM最小元素自动化要求中删除。使用专有数据格式的标准也不应当包含在内。这样就能实现基于现有工具实现易于采用、支持未来演变以及可扩展性的要求。

实践和流程

SBOM 不止结构性数据集；将其集成到安全开发生命周期中，组织机构应当遵循某些专注于SBOM使用机制的实践和流程。在任何要求提供或提供 SBOMs 的策略、合同或约定中，都应当明确提出多个元素。其中某些元素（如频率）的要求很直接；在一些情况下（如访问），存在多种实践且正在开发更多实践，因此某些约定具有最小元素要求。

频率。如果软件组件以新版本或发布的形式更新，那么必须创建新的 SBOM 来体现该软件的新版本。其中包括集成已更新组件或依赖的软件版本。同样，如果供应商获悉关于底层组件的新详情，或者希望修正已有SBOM数据中的错误，那么供应商应当发布新的经过修订的SBOM。

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

随着组织机构开始建立SBOM，由于子组件供应商的现有要求，可能无法轻易获取除主要组件以外的深度。对SBOM流程的最终采用将能够在子组件层面通过更深的透明度层级进行更深度的访问。应当注意的是，某些用例要求完整的或基本完整的表。如 “举反证“，证明某既定组件不存在于某机构网络中。

SBOM 消费者可通过传递步骤的数量来指定深度要求。或者也可通过运营术语的方式指定深度要求。可以包括软件属性，如“所有非开源软件“，或者某个功能的所有组件或者复杂程度。组织机构还可以向那些提供并缓解SBOM所列组件中漏洞的一方做出不同要求，鼓励报告深度和完整性。这类标准细则不在最小元素范围内。

已知的未知。对于在SBOM 中未列举出完整依赖表的实例，SBOM 作者必须明确识别出“已知的未知“。即，依赖数据清晰地区分出不含其它依赖的组件和所含依赖不明及不完整的组件。该数据必须集成到自动化数据中。为了避免错误假设，数据的默认解释应为：数据是不完整的；SBOM 数据的作者应当肯定地说明何时已完全枚举组件的直接依赖，或何时组件不含其它依赖。当前，这一信息在依赖关系数据字段中实现。

分发和交付。应当及时地向所需方提供SBOMs，而且必须设置恰当的访问权限和角色。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 社区的优先级任务。

生命周期阶段。关于软件组件的数据可在软件生命周期的不同阶段进行收集，如通过二进制分析工具在软件源、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工作的限制或对其潜力的完全枚举。这些建议是行业和政府专家所关注的。

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

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

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

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

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

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

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

七、结论

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

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

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

推荐阅读
在线阅读版：《2021中国软件供应链安全分析报告》全文
Apache PLC4X开发者向企业下最后通牒：如不提供资助将停止支持
Apache 软件基金会：顶级项目仍使用老旧软件，补丁作用被削弱
NIST 发布关于使用“行政令-关键软件”的安全措施指南
NIST 按行政令关于加强软件供应链安全的要求，给出“关键软件”的定义及所含11类软件
SolarWinds 攻击者再次发动供应链攻击
美国“加强软件供应链安全实践的指南” (SSDF V1.1草案) 解读来了
软件供应链安全现状分析与对策建议
“木马源”攻击影响多数编程语言的编译器，将在软件供应链攻击中发挥巨大作用
GitHub 在 “tar” 和 npm CLI 中发现7个高危的代码执行漏洞
流行的 NPM 包依赖关系中存在远程代码执行缺陷
速修复！热门npm 库 netmask 被曝严重的软件供应链漏洞，已存在9年
Npm 恶意包试图窃取 Discord 敏感信息和浏览器文件
微软“照片”应用Raw 格式图像编码器漏洞 (CVE-2021-24091)的技术分析
SolarWinds 供应链事件后，美国考虑实施软件安全评级和标准机制
找到软件供应链的薄弱链条
GitHub谈软件供应链安全及其重要性
揭秘新的供应链攻击：一研究员靠它成功入侵微软、苹果等 35 家科技公司
开源软件漏洞安全风险分析
开源OS FreeBSD 中 ftpd chroot 本地提权漏洞 (CVE-2020-7468) 的技术分析
集结30+漏洞 exploit，Gitpaste-12 蠕虫影响 Linux 和开源组件等
限时赠书|《软件供应链安全—源代码缺陷实例剖析》新书上市
热门开源CI/CD解决方案 GoCD 中曝极严重漏洞，可被用于接管服务器并执行任意代码
GitKraken漏洞可用于盗取源代码，四大代码托管平台撤销SSH密钥
因服务器配置不当，热门直播平台 Twitch 的125GB 数据和源代码被泄露
彪马PUMA源代码被盗，称客户数据不受影响

原文链接

https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf

题图：Pixabay License

本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。