2026年7月29日，CISA发布了 《2026年网络安全基准最低要素》Software Bill of Materials (SBOM)，取代了自2021年起实施的NTIA基准，该文件由CISA与美国国家安全局（NSA）、联邦调查局（FBI）以及15家国际网络安全机构共同起草。
《2026年软件物料清单（Software ）最低要素规范》（Bill of Materials (SBOM) ）是美国网络安全与基础设施安全局（CISA）针对SBOM必须包含哪些数据所发布的更新规范，其中最具影响力的变化在于结构而非数量：2026年版要素规范并未禁止基于源代码清单生成的SBOM，但要求编制者声明SBOM的生成方式、对可执行工件进行哈希计算，并标注所有无法填充的字段。 仅基于清单的 SBOM 现可通过机器可读格式披露其自身的缺失信息。
MetaDefender Software Supply Chain 这是OPSWAT 的软件供应链安全平台，旨在分析构建产物、二进制文件和容器镜像层——这正是新的哈希值、生成上下文和覆盖率要求所必需的数据类别。
一览
- 17 个数据字段——9 个 SBOM 元数据字段、8 个组件数据字段
- 6项实践与流程
- 新增 10 个字段、8 项重大更新、1 项删除（“访问控制”已并入“分发与交付”）
- 适用于所有软件，“包括开源软件、人工智能软件和SaaS”
- 并非新要求——而是对组织生成和请求 SBOM 方式的优化
2026年SBOM变更中，仅含源代码的SBOM最难满足的方面
1. 组件哈希值需要可执行工件
“组件哈希值”和“组件哈希算法”明确规定了哈希的对象：“对可执行组件工件应用密码学哈希算法后生成的输出”。既不是清单条目，也不是声明的版本字符串。
- 读取 package-lock.json、pom.xml 或 requirements.txt 的解析器不会涉及可执行工件，因此这两个哈希字段均返回“未知”
- 如果存在哈希，则该算法必须使用 IANA 哈希函数文本名称 ，并获得NIST等权威机构的批准
- 正是通过哈希值，收货人才能确认所描述的组件与实际发货的组件一致
2. SBOM 生成背景使该方法成为记录的一部分
SBOM 生成背景是此次更新中最不起眼但结构上最具意义的一项：“SBOM 编写者生成 SBOM 时所处的相对软件生命周期阶段以及当时可用的数据”。CISA 定义了三个值——“构建前”、“构建中”和“构建后”——并将每个值与 SBOM 的生成方式相关联：基于源代码生成的 SBOM 对应最早的阶段，而通过二进制分析工具生成的 SBOM 则对应最晚的阶段。
- 采购团队可以指定他们将接受哪个生命周期阶段，并更倾向于采用基于编译后产物生成的软件物料清单（SBOM），而非源代码级别的SBOM。
- 漏洞管理平台可以根据声明的上下文对发现结果进行加权
- 源自源代码的软件物料清单（SBOM）仍然被允许，但不能再将其视为与从最终二进制文件生成的SBOM等同。
3. 广度取代深度，且无下限
2021年的“深度”要素仅要求顶级依赖项——CISA现在表示，该定义“反映了当时SBOM工具的能力，而非做出明智安全决策所需的信息深度”。覆盖范围的要求更为严格：“构成目标软件的所有组件，包括传递性依赖项。没有最低深度要求。”
该测试具有实用性。如果软件材料清单（SBOM）中未列出与该漏洞相关的组件，接收方“应当能够得出结论：新报告的漏洞对其没有影响”。“缺失即证据”，这一原则仅在覆盖范围足够全面时才成立。仅靠解析清单文件，对于以下情况，往往难以达到这一标准：
- 静态链接和作为库包含的代码——不会生成清单条目
- C 和 C++ 项目——没有通用的包管理器会追踪构建时引入的 DLL 和共享对象
- 复制的源代码——CISA将其描述为“实际上是一种依赖关系，最好将其作为分支和依赖关系来追踪”
- Container 映像层——通过 layer 命令安装的软件包，而非在清单中声明的软件包
未知信息现在必须予以申报
- 作者应区分自己不知道的信息与被故意隐瞒的信息
- 建议作者建立一套机制，以便收件人就被遮盖的安全相关内容进行查询
- “如果 SBOM 编写者隐瞒了关键组件数据，组织可能会认为该 SBOM 不完整”
- “对错误的容忍”原则已被取代，理由是接收方可“预期 SBOM 数据是准确的”——如今，“因选用不恰当工具”而导致的错误已成为接收方风险评估中的合理考量因素
CISA 对 2026 年 SBOM 要素作出的其他修改
更改 | 什么是…… | 为何这很重要 |
SBOM 作者签名（新增） | 与 SBOM 作者相关的数字签名 | 允许接收方确认 SBOM 的真实性，并确认其在签名后未被篡改 |
组件许可（新） | 各组件所依据的许可协议 | 揭示版权与合规风险；CISA指出SPDX许可ID |
机器可处理数据（原名“自动化支持”） | 仅限 SPDX 和 CycloneDX | 由于SWID使用不广泛，已将其移除；将支持的格式缩减为两种 |
零部件生产商（原供应商名称） | 每个组件对应一个命名组织 | 当来源不明时，添加一个明确的“来源不明”备用选项 |
频率（更新） | 针对每个包含变更组件的版本、更新和构建，生成一份新的SBOM | 这种节奏很难靠人工维持，这促使各团队转向自动生成 |
弥合建设完成后的差距
2026年的更新反映了CISA的评估结果：即SBOM工具已足够成熟，需要发挥更大作用，而该机构目前所期望的信息位于构建流程的后端。
MetaDefender™Software Supply Chain 可直接从构建后的工件生成 SBOM 数据：
- 扫描的是资源文件、二进制文件和容器镜像层，而不仅仅是依赖文件
- 通过 可移植可执行文件（PE）元数据和基于签名的识别
- 在 CycloneDX 和 SPDX 中生成 SBOM，并丰富现有报告，以发现先前扫描中遗漏的组件和 CVE
- 参考 GHSA、CVE 和 EUVD，并标记不符合要求的许可证
- 可与 CI/CD 管道以及 JFrog Artifactory 等构建产物注册表集成，从而使 SBOM 生成能够伴随每次构建进行
了解MetaDefender Software Supply Chain 如何在整个开发生命周期中满足 SBOM 要求：
常见问题
CISA 2026 年 SBOM 最低要素有哪些变化？
此次更新新增了十个数据字段，进行了八项重大修订，并移除了一个元素。最重大的结构性变更在于用“覆盖范围”取代了“深度”，而包括“组件哈希值”、“SBOM生成上下文”和“SBOM作者签名”在内的新字段，则提高了人们对SBOM数据生成与验证方式的期望。
CISA 2026 SBOM 最低要素是强制性的吗？
不。CISA 并未设定合规截止日期或执法机制，并明确指出该文件“不构成用于合规、监管或法律目的的建议”。其实际约束力源自采购要求以及引用 SBOM 基准的法规，例如《欧盟网络弹性法案》。
CISA 2026 版 SBOM 最低要素是否要求进行二进制分析或构建后分析？
并非明确如此。不过，“组件哈希值”需要访问可执行工件，“SBOM 生成上下文”要求作者声明生命周期阶段，且未填充的字段必须标记为“未知”。因此，仅包含源代码的 SBOM 既符合格式要求，又能记录其自身的缺失信息。
CISA 2026 的最低要求是否适用于人工智能软件和SaaS？
是的。适用范围涵盖所有软件，包括开源软件、人工智能和SaaS。CISA指出，这些类别可能需要补充其他要素，但在此并未对其进行定义，而是援引了2026年5月发布的G7关于人工智能软件物料清单（SBOM）的联合指南。
CISA 2026 最低要素中接受哪些 SBOM 格式？
SPDX 和 CycloneDX 被描述为两种广泛用于生成和使用 SBOM 的格式。SWID 标签已被移除，因为“它并非一种广泛使用的 SBOM 数据格式，且没有多种工具支持”。任何格式的过时版本都不应用于新软件。
