近日，美国网络安全和基础设施安全局发布了更新的《软件物料清单最低要素》草案，开启了公众意见征询期，致力于加强软件供应链的透明度。
2021年，美国国家电信和信息管理局（NTIA）发布了《软件库存清单最低物资》（2021 NTIA）软件补货清单（ SBOM ）是记录软件构建过程中所用组件详情及供应链关系的正式文件。SBOM为软件生产者、选择者和运营者提供了增强其软件对供应链理解的信息，这些信息可转化为推动风险管理决策的洞察力，排除已知及新发现的漏洞等风险。
自2021年文件发布以来，SBOM实施实践已取得显著进展。随着软件生态系统各利益方的广泛采用与实施，SBOM数据的新应用场景不断得到满足。为响应SBOM应用需求的增长，相关工具已远超2021年水平实现功能成熟。这些进展使得组织要求SBOM的能够获取比2021年更先进的软件组件及供应链信息。
作为美国首席网络安全机构，网络安全与基础设施安全局（CISA）发布本文件旨在更新并澄清2021年文件的核心要素；在保留2021年文件基本原则的同时，新增内容以反映当前软件材料清单（SBOM）的需求与能力。例如自动化技术仍是实现大规模安全防护的关键要素。本文件旨在为美国联邦部门及机构实施SBOM提供指导，亦可供其他众多组织参考。文件中的更新与新增内容将助力联邦政府机构及其他SBOM使用者应对各类应用场景、理解生成流程并提升数据质量。
本文档新增的要素（组件哈希值、许可证、工具名称和生成上下文）为提升基于风险的软件安全决策提供了信息支持。同时更新了部分要素的细节（SBOM作者、软件生产商、组件版本、软件标识符、覆盖范围以及SBOM数据更新的容纳机制），旨在明确SBOM应包含的数据内容，以实现更统一的实施标准。其他元素（组件名称、时间戳、依赖关系、自动化支持、频率、已知未知项、分发与交付）更新了早期版本的定义，以提升信息质量并适应技术发展。本版本移除了访问控制元素，并将访问控制考量纳入分发与交付部分。
软件生态系统内的讨论已开始探索为某些类型软件（即云环境中的软件即服务和人工智能（AI）软件系统）增加额外要素的可能性。本文档讨论的最低要素适用于所有软件。对于这些不同类型的软件，增加数据字段、实践和流程可能有所裨益。任何旨在提高软件透明度的努力，无论软件类型如何，都应从应用软件物料清单（SBOM）最低要素开始。
引言
软件物料清单（SBOM）已成为软件安全与软件供应链风险管理中的关键基石。SBOM是一种嵌套式清单，记录构成软件应用程序和系统的所有组件。美国国家电信和信息管理局（NTIA）发布的《软件物料清单（SBOM）最低要素》（2021 NTIA SBOM最低要素）明确了SBOM实施的预期标准。该文件反映了2021年SBOM工具的技术成熟度以及软件界对SBOM的认知水平。此后，软件生态系统中的组织、专家及从业者对SBOM及其在软件与供应链安全中的应用日益熟悉。随着生成SBOM的软件生产商数量、要求提供SBOM的软件选择者与运营者数量的增长，SBOM工具也日趋成熟。在专家协作与从业者创新的推动下，SBOM技术现状自2021年以来已取得显著进步。根据美国管理和预算办公室（OMB）发布的《软件认证与供应链安全备忘录》（M-22-18），本文件更新了2021年NTIA SBOM最低要素标准，以反映当前SBOM实施实践的成熟度。本文件更新了美国政府机构生成或请求的SBOM基准数据字段、实践规范及流程。
为何需要SBOM：提升透明度与安全性
软件物料清单（SBOM）是实现软件组件透明化的关键步骤，它能揭示软件供应链的构成，帮助组织基于风险信息做出更明智的软件决策。SBOM如同软件的“成分表”，为组织提供软件构成数据。组织可将这些数据转化为洞察力，从而采取行动降低可能危及软件系统安全的风险。
有效的软件数据共享机制必须具备机器可处理性和可扩展性。SBOM模型通过以机器可处理格式捕获软件组件数据，并支持对其进行分析、共享和管理，实现了这两点。SBOM数据可映射至其他数据源（如安全公告或组织级“批准/未批准”软件数据库），从而提升其他优先实践（如安全软件开发、漏洞管理）。SBOM虽无法解决所有软件安全与供应链问题，却是推动风险知情安全决策的关键必要步骤。
为何采用最低要素：推动大规模安全建设
最低要素规定了软件物料清单（SBOM）应满足的基础技术和实践要求。政府机构使用的软件数量庞大，手动流程难以有效评估和缓解风险。鉴于软件在支撑核心职能和关键基础设施中的关键作用，未被追踪管理的软件将对国家安全构成威胁。这两点情况凸显了全美政府机构建立统一SBOM数据基准的必要性。统一的SBOM预期标准将助力各机构将SBOM数据应用于软件与供应链安全实践，并促进跨机构信息共享。
除美国政府外，全球软件生态系统中的各类组织及从业者均已认识到SBOM在提升软件与供应链透明度方面的价值，并推动了SBOM应用普及与技术实施的进步。随着SBOM在各行业、领域及国际范围内的持续推广，统一SBOM预期标准的重要性将日益凸显。
范围
本文档所述的最低要素可适用于各机构采购或开发的软件及其组件，包括开源软件、人工智能（AI）软件以及软件即服务（SaaS）。对于AI或SaaS等更复杂的软件系统，可能需要额外要素以实现对软件整体及其组件的透明化管理，但软件物料清单（SBOM）仍应包含最低要素。特定类型软件可能需要的附加要素超出本文档范围。
本文所述最低要素并非新增联邦要求，而是细化联邦政府生成和请求SBOM的方式。数据管理与存储实践、精确编码细节均不在本报告范围之内。
最小要素
软件物料清单（SBOM）的最小要素通过捕捉技术与功能运作，支持软件透明度的发展性方法。随着时间推移，软件供应链的透明度能力将不断提升，未来工作将融入更多细节与技术进步。
最低要素分为三大类：
数据字段
自动化支持
实践与流程
SBOM大致采用分层结构：软件由组件构成，每个组件可能包含子组件。每个子组件亦可由子组件构成，依此类推。组件（及子组件）可分为“第三方”或“第一方”。第三方组件源自外部供应商；第一方组件虽出自同一生产商，但可识别为独立可追踪的软件单元。每个组件均应具备SBOM，以记录其子组件及依赖关系层次。数据字段适用于所有组件，可通过工具与预定义格式实现机器可处理性。
数据字段
软件物料清单的核心在于其一致且统一的结构，该结构用于捕获并呈现理解软件组成部件所需的信息。数据字段包含每个组件的基础信息，其目标是实现对这些组件的充分识别，以便在软件供应链中追踪它们，并将它们映射到其他有益的数据源，如漏洞数据库或许可证数据库。某些数据字段可能在不同组件及子组件中呈现相似数据，但其存在能确保清晰度与可识别性。附录B包含所有最小元素更新的变更日志。
SBOM作者（重大更新）
定义：创建该组件SBOM数据的实体名称
SBOM作者元素包含一个字符串，用于标识生成该组件SBOM的实体。该字段与标识软件组件生产者的“软件生产者”字段不同。若同一实体既生产软件组件又生成SBOM，则两者可能相同。当非生产实体为特定组件生成SBOM时，两字段将存在差异。
软件生产者（重大更新）
定义：创建、定义和识别组件的实体名称
软件生产者字段包含一个可读字符串，用于标识生产软件组件的实体。“软件生产者”指软件组件的创建者或制造商。组织可通过软件生产者元素获取软件组件生产者的详细信息，该字段还可用于确定软件安全问题的联络点。软件生产者元素应支持多条记录。
对于开源软件项目，软件生产者信息依然重要。命名规范可能因项目开发、分发及维护包文件的方式而异。某些生态系统通过包管理器提供供应商命名惯例。若无此类惯例，SBOM作者应使用原始项目或维护组织名称（如可获取）。若无法明确标识软件生产者，SBOM 编写者应明确标注组件来源不明，以承认其不可追溯性。
此项取代了 2021 年美国国家电信和信息管理局（NTIA）SBOM 最低要素中的供应商名称元素。实践证明供应商名称存在歧义，尤其涉及软件分销商时。尽管改为生产者名称后歧义有所减少，但在形成全球共识的软件创建实体识别方法之前，部分模糊性仍将存在。
组件名称（次要更新）
定义：软件生产商为软件组件分配的名称。
组件名称元素以人类可读的形式标识软件组件。软件生产商确定软件组件的名称。该字段与软件标识符字段不同。实现组件名称元素的数据格式应允许多条目以捕获别名。SBOM作者应谨慎避免引入混淆。
组件版本（主要更新）
定义：软件生产商用于标识软件相较于先前版本变更的标识符。
组件版本元素记录软件版本信息，使组织能够识别特定代码交付版本。若软件生产商未提供版本信息，SBOM作者可使用文件创建日期替代。
软件标识符（重大更新）
定义：用于识别组件或作为相关数据库查询键的标识符。
软件标识符元素包含至少一个与软件组件关联的软件标识符。可机读的唯一软件标识符支持自动化分析。推荐使用通用软件标识符，如通用平台枚举（CPE）和软件包统一资源定位符（purl）。该字段也可包含全局唯一标识符（UUID）、组织专属标识符、提交哈希值以及内在标识符（如OmniBOR和SWHID）。若存在多个软件标识符（无论采用相同或不同格式），SBOM 创建者应完整包含所有标识符。
组件哈希值（新增）
定义：通过对软件组件进行哈希运算生成的加密值。
组件哈希元素包含哈希值，并标识所用哈希算法，或表明SBOM作者无法访问原始组件工件。若SBOM作者无法访问原始组件工件，则不应包含组件哈希。
许可证（新增）
定义：软件组件提供的许可协议。
许可证元素记录软件组件可供使用的许可信息。在可能的情况下，SBOM作者应以机器可处理的方式传达此信息。该字段还应包含专有许可条款的存在情况。若SBOM作者未知晓许可信息，则应标注许可信息未知。
依赖关系（重大更新）
定义：指两个软件组件之间的关联关系，具体体现为软件X包含组件Y，或组件A主要源自组件B。
依赖关系元素反映特定软件组件如何被纳入目标软件。这种包含关系（“包含”或“被包含于”）支持构建依赖关系图。除包含关系外，该元素还应体现组件如何主要衍生自其他软件，或作为其他软件的后代存在。此设计使SBOM能明确记录回溯移植或分叉的软件。
工具名称（新增）
定义：SBOM作者用于生成SBOM的工具名称。
工具名称元素包含一个字符串，用于标识SBOM数据作者生成SBOM所使用的软件工具及其数据源类型（例如混合型或增强型）。若SBOM作者为特定组件生成、增强或扩充SBOM数据时使用了多款工具，则应列出所有使用工具。
时间戳（次要更新）
定义：记录SBOM数据最近一次更新的日期和时间
时间戳字段标识SBOM作者上次修改SBOM数据的时间，无论是手动还是通过软件工具完成。若SBOM作者在生成后未对SBOM进行任何修改，则应输入生成时的日期和时间。该字段内容应遵循ISO 8601标准。
生成上下文（新增）
定义：软件生产商生成软件物料清单时所处的相对软件生命周期阶段及可用数据（构建前、构建中、构建后）。
生成上下文元素揭示了SBOM生成过程的具体情境、数据来源及可见性。对于接收SBOM的组织而言，构建前、构建中、构建后这三种上下文至关重要。构建前或源代码SBOM基于代码库及其他组件集的数据生成。SBOM生产者可在创建可发布工件（如可执行文件或软件包）时生成构建或构建时SBOM，记录构成该工件的确切组件。二进制分析工具可生成分析后或构建后SBOM。该元素为SBOM作者生成SBOM所依据的数据类型提供背景信息。
自动化支持
自动化支持对于大规模管理软件组件数据至关重要，尤其是在跨组织边界的情况下。由于数据量庞大、用例多样且工具各异，软件物料清单（SBOM）的实施必须相互兼容才能支持自动化。当前软件生态系统参与者广泛采用的两种生成和使用SBOM的数据格式为：
软件包数据交换格式（SPDX）
CycloneDX
这两种数据格式均源自开放的国际化流程，兼具机器可处理性与人类可读性。
软件生产商或SBOM作者可根据组织、行业或领域特有的因素选择首选生成格式。机构应接受任何广泛使用、互操作且可机器处理的SBOM格式。但为确保与SBOM消费管理工具的兼容性，各机构应避免接受采用已弃用版本格式生成的全新软件SBOM。
自动化支持的最低要求是支持所有广泛使用、开源且与现有数据格式兼容的数据格式。应定期重新评估支持的数据格式。若某格式普遍存在兼容性问题、不再维护或无法满足SBOM使用场景需求，则应将其从自动化支持范围中移除。此方法既能依托现有工具实现便捷采用，又能支持未来演进与扩展。
实践与流程
SBOM不仅是结构化数据集。组织在SBOM使用方面的实践与流程应将其融入软件开发生命周期。在任何要求或提供SBOM的政策、合同或协议中，组织都应明确涵盖以下要素：频率（如更新周期）这类要素较为直接，而访问权限等要素则涉及多项实践，既需基于现有方法，也需融入创新理念。
更新频率（次要更新）
每个软件版本或更新都应关联一份SBOM。当软件生产商发布新构建版本或新版本时，其（或SBOM作者）应同步生成反映变更的新SBOM。这包括整合更新组件或依赖项的软件构建版本。当软件生产商（或SBOM作者）发现底层组件的新细节，或需修正现有SBOM数据中的错误时，应发布修订版SBOM。
覆盖范围（重大更新）
软件物料清单应包含构成目标软件的所有组件信息，包括传递性依赖项。无最小深度要求。若存在多个具有不同元数据的软件组件实例，则每个实例必须单独列出并标注相应的依赖关系。SBOM无需包含非代码文件，但可包含配置文件等安全相关文件。SBOM应提供组件的全面清单，以便接收方进行基于风险的决策。例如，从漏洞管理角度而言，若SBOM中未列出与漏洞关联的组件，接收方应能据此判定新报告的漏洞对其不构成影响。
已知未知项（重大更新）
若软件物料清单未列出所有依赖项，清单编制者必须明确标识已知未知项。此做法可清晰区分无后续依赖的组件与依赖项清单不完整的组件。软件物料清单的默认解释应为数据不完整。SBOM作者还需区分两类依赖信息：作者自身未知信息与被刻意删除的信息。作者应建立流程供接收方查询任何被删除的安全相关信息。若关键依赖项被删除，组织可视为SBOM不完整。作者应采用区别于特定元素未知值的标记方式，标注未知或被删除的组件。
分发与交付（次要更新）
SBOM应及时提供给需要者。访问控制可限制与外部方共享SBOM数据，但不应阻碍机构间信息共享，也不应限制机构将SBOM数据集成至可信安全工具。共享SBOM数据的方式多样，例如随安装程序附带SBOM。亦可通过特定版本URL、数据库应用程序接口（API）或公共存储库访问SBOM。
SBOM数据更新机制（重大更新）
组织应支持数据更新机制，包括SBOM数据的错误修正。SBOM编写者应及时更正错误。各机构在风险管理决策中，可将错误因素纳入考量，无论错误源于SBOM编写实践还是工具选择不当。
讨论
随着SBOM及相关工具持续成熟，以下四个关键领域值得深入探讨并制定潜在指导方针：云与SaaS软件、人工智能软件、验证机制，以及与安全公告的关联性。云计算与人工智能软件这两类软件可能需要增加SBOM元素。验证机制与安全公告关联性对所有软件而言既是宝贵机遇也是严峻挑战。这些议题属于持续探索与未来工作重点。
云环境中SaaS的软件物料清单
SaaS生产商与SaaS运营商在风险缓解方面的责任共担，以及SaaS的频繁变更，使得将软件物料清单模型从本地软件迁移至SaaS变得复杂。SaaS生产商和运营商均在SaaS的管理与安全保障中扮演角色。这种责任共担可能限制某些软件物料清单用例的应用。SaaS软件物料清单的交付频率也需要进一步明确。云软件特性与现代开发实践导致软件变更频率极高。如此高频的SBOM交付与接收可能使SaaS生产商和运营商不堪重负。API等分发机制可通过捕获快照来适应持续集成与持续交付（CI/CD）流程中的快速代码变更。
承认SBOM在云与SaaS场景中的应用挑战，并不否定其对云/SaaS软件的价值，亦不意味着实现软件组件透明度不可行。包括SaaS/云软件SBOM潜在附加要素在内的进一步规范，值得深入探讨。
人工智能软件系统的SBOM
人工智能软件系统（如云环境和SaaS环境）包含额外组件，这些组件可能无法通过最低要素进行捕获。随着人工智能日益嵌入软件系统并在关键基础设施中发挥潜在作用，组织应保持并提升对系统组件的可视性，以妥善管理相关风险。由于人工智能属于软件范畴，最低要素将揭示机构需关注的部分组件，但可能存在未被最低要素捕获的数据，这些数据能提供更有效的可视性。关于AI应用场景的SBOM及AI用户可请求的数据字段仍在持续探讨中。但本文件未为AI系统SBOM引入额外要素。
验证机制
SBOM与其他安全数据类似，可能需要不同级别的信任。SBOM使用者可能关注验证SBOM数据的来源，并确认其未被篡改。在软件领域，完整性与真实性通常通过签名和公钥基础设施来保障。SBOM格式已开始采用部分签名技术。管理SBOM信息的组织应利用现有的软件签名基础设施、工具及密钥管理机制。相关机构可通过访问开源软件仓库等来源，或运用二进制分析工具检测SBOM未列组件，来验证SBOM数据的准确性、覆盖范围及完整性。
将SBOM与安全公告关联
安全公告（如漏洞可利用性交换平台VEX和通用安全公告框架CSAF文档）为相关软件组件提供额外安全信息。安全公告传达软件组件的漏洞状态信息。软件生产商可借助安全公告通知客户其软件组件存在漏洞，并说明正在修复中（或采用最恰当的漏洞状态表述）。漏洞状态更新不仅能突出安全问题，还能避免不必要的努力——当可信来源判定潜在风险不会转化为实际风险时，此类更新尤为重要。
此类安全信息对漏洞管理具有显著影响。当新漏洞信息发布时，拥有SBOM的企业可立即核查其SBOM中是否包含易受攻击组件，相较于未建立软件SBOM的企业，响应速度将大幅提升。VEX和CSAF等安全公告通过缩小风险软件组件范围，能进一步优化漏洞管理流程的效率。
结论
随着新用例的出现和技术的演进，SBOM的最低要素应持续发展，以保持对软件组件的可视性。SBOM本身仅是关于软件组件的数据。对SBOM的分析将数据转化为关联风险的洞察。机构可据此洞察推动其软件系统的安全决策。能够摄取SBOM、分析数据并将其映射至其他数据源的漏洞管理工具，将使机构能够充分利用SBOM驱动的数据、情报和行动。
网络安全与基础设施安全局（CISA）在推进和完善SBOM采用与实施方面发挥着关键作用，但SBOM成熟度的大部分进展是由软件生态系统中的SBOM社区和利益相关方推动的。软件物料清单社区各成员的经验与专业知识弥足珍贵，它们不仅揭示了软件物料清单采用与实施的挑战，促成了跨行业经验的共享，更推动了软件物料清单技术层面的优化。CISA将持续发挥其作为美国网络安全主管机构的领导地位，促进信息共享，汇聚社区专家力量，共同识别并推广解决软件供应链挑战的方案。
声明：本文来自天极智库，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
