CISA 网络安全提高了 SBOM 基线，但更完善的清单仍无法弥补安全缺口

尽管外界持续质疑组织能否有效利用软件物料清单，CISA 网络安全指南仍取代了已有五年历史的联邦基线。

网络安全与基础设施安全局（CISA）与国家安全局、联邦调查局及国际合作伙伴共同发布了《2026 年软件物料清单最低要素》。该指南更新了国家电信和信息管理局于 2021 年发布的框架。

SBOM，即软件物料清单，是一份以机器可读格式呈现的软件产品内部组件及其关系清单。它可以帮助组织判断新披露的漏洞是否存在于其应用程序或基础设施中的某处。

此次替换之所以重要，是因为 2021 年框架出台时，SBOM 工具大多仍专注于生成清单。如今的系统还会在开发流水线和客户环境中交换、合并、验证和分析这些清单。

这种转变构成了新指南背后的核心矛盾。CISA 希望获得更丰富、更一致且可由机器处理的数据，但增加字段并不能保证最终清单完整或可执行。

最初的 NTIA 基线帮助建立了共同术语。新的 CISA 网络安全框架要求软件生产者和使用者将 SBOM 视为运营安全数据，而非静态的合规文件。

CISA 网络安全取代 2021 年 SBOM 基线

最重要的变化体现在机构职责和运营层面：CISA 现负责一套更广泛的基线，用于日常软件风险管理。

在第 14028 号行政命令发布后，NTIA 于 2021 年 7 月 12 日公布了最初的最低要素。该框架将合格的 SBOM 划分为三个类别：数据字段、自动化支持，以及实践与流程。

最初的七项数据字段涵盖供应商名称、组件名称、版本、唯一标识符、依赖关系、SBOM 作者和时间戳。自动化要求鼓励使用机器可读格式，而运营实践则涉及生成频率、分发、访问、深度和已知缺口。

这些要素有意保持简洁。在许多供应商从未生成过 SBOM 的时期，它们定义了最小可用的清单标准。

2026 年发布的版本更新并取代了该框架。此前，CISA 于 2025 年 8 月启动公开征询，并于 2025 年 10 月 3 日结束。

公开征求意见通知指出，SBOM 工具已从单纯生成扩展到共享、分析和管理。通知还提到，开源社区、各国政府和更多行业的参与度正在提高。

CISA 并未通过该指南制定具有约束力的联邦采购规则。最低要素仍是一项用于生成和索取可用 SBOM 的基线，而非新的法律或普遍性强制规定。

这一区别对供应商至关重要。客户可以在合同或采购流程中采用该框架，但仅凭该出版物并不会强制每家软件公司生成 SBOM。

不过，其适用范围仍然广泛。该框架可适用于政府机构采购或开发的软件，包括开源组件、软件即服务以及涉及人工智能的软件。

CISA 还承认，复杂服务可能需要超出一般最低要求的信息。SaaS 平台持续变化，而 AI 系统可能依赖于模型、数据集、框架和外部服务，这些要素与传统软件包并不相似。

2026 年发布的单独 AI 专项指南处理了其中部分差异。通用 SBOM 最低要素仍是这些专业清单的基础起点。

因此，这些机构是在设定共同底线，而非描述所有可能的软件供应链。各组织仍需制定与其架构、风险和监管义务相匹配的政策。

这比简单延长字段列表更具影响力。它将 SBOM 的讨论从定义一份文件，转向维护有关软件组成的共享证据。

新的最低要素要求提供更多上下文

当安全团队需要区分软件包、验证制品，并在不同工具之间关联发现结果时，组件名称和版本已不再足够。

2026 年基线保留了 NTIA 建立的三部分结构，仍涵盖数据字段、机器可处理格式，以及用于创建、更新和交换 SBOM 的实践。

不过，更新后的模型要求围绕软件本身及清单本身提供更丰富的上下文。制定过程重点提出了四项新增内容：组件哈希值、许可证信息、工具标识和生成上下文。

组件哈希值是根据软件内容计算得出的加密值。它可帮助使用者区分名称和版本相同、但字节内容不同的制品。

当供应商重建软件包、应用私有补丁或分发特定平台的二进制文件时，这一区别尤为重要。即使实际制品发生变化，版本字符串也可能保持不变。

不过，哈希值并非通用身份识别系统。结果取决于哈希的对象、该对象是否经过压缩，以及构建过程如何打包其文件。

Business Software Alliance 在征询期间提出了这一问题。其行业回应认为，哈希可以提供有用的验证，但对于归档文件、解压后的文件、固件及其他软件形式，需要更明确的定义。

许可证信息增加了另一个维度。它有助于组织识别与组件相关的条款，包括开源和专有依赖项。

许可证数据支持法律审查和组件治理，同时也改善基本识别。名称相似的两个软件包可能具有不同的所有权或分发条件。

工具名称记录了生成 SBOM 的系统。该字段让使用者能够调查不一致的结果，并了解为何两个扫描器会以不同方式描述同一制品。

生成上下文说明清单是如何产生的。从源代码创建的 SBOM 所能发现的组件，可能不同于从容器镜像、已安装系统或最终二进制文件创建的 SBOM。

这种来源信息会影响安全团队应如何理解缺失的数据。源代码扫描可能识别出从未进入生产构建的声明依赖项；二进制扫描则可能发现软件包清单遗漏的捆绑代码。

更新后的框架还强化了既有字段。唯一标识符至关重要，因为自动化漏洞系统无法可靠地将自由文本的软件包名称与安全记录关联起来。

Package URL、Common Platform Enumeration 标识符和 SWID 标签提供了识别软件的结构化方式。没有任何单一方案能够覆盖所有组件，因此生产者必须选择适合现有生态系统的标识符。

依赖关系仍是核心。当清单展示一个组件如何包含或依赖另一个组件，而不是将每一项都呈现为互不相关的行时，其价值会更高。

2021 年的最低要素已要求提供依赖信息。当前指南赋予这一要求更强的运营意义，因为漏洞分诊日益依赖关系图谱。

更新后的实践还保留了“已知未知项”的概念。生产者应标明可用工具无法确定是否存在其他依赖项的领域。

这种表述避免了一个危险假设。缺少某项关系，可能意味着不存在依赖关系，也可能意味着生成工具未能发现它。

在事件响应期间，这一区别至关重要。安全团队需要知道，负面搜索结果究竟代表不存在的证据，还是仅仅意味着可见性不完整。

CISA 实际上是在要求生产者为其清单附加置信度和上下文。这会让 SBOM 不那么整洁，但也让数据更诚实。

软件供应商面临更高的证据负担

新基线促使供应商产出可重复的安全证据，而买方则必须构建能够解读这些证据的系统。

对软件生产者而言，SBOM 不再能被视为销售审查前一次性生成的文件。它必须随产品经历发布、重建、依赖项变更和漏洞披露。

这要求与开发和交付系统集成。生产者需要在足够接近构建流程的环节生成清单，以确保其描述的是客户实际收到的制品。

团队还需要稳定的组件标识符。如果同一依赖项在连续构建中获得不同标识符，自动化比较和漏洞交换就会变得不可靠。

工具披露和生成上下文带来了相关预期。生产者必须了解其扫描器如何运行、检查哪些来源，以及其可见性的边界在哪里。

这可能暴露令人不安的缺口。公司可能发现，其构建扫描器能捕获软件包清单，却遗漏了动态加载的插件、嵌入式固件、复制的源文件或专有二进制文件。

随后，工程团队面临实际选择：改进流水线、记录未知区域，或从上游供应商获取更好的组成数据。

这项工作超出了安全专家的范围。采购团队需要接收 SBOM 的合同条款，法务团队需要制定分发规则，产品团队则需要建立更新客户的流程。

管理大量应用程序的组织还需要可搜索的存储。接收数千份 JSON 文档却不对其中组件建立索引，只会产生文书工作，而非运营可见性。

因此，负担同样落在买方身上。买方必须规范化不同文件、保护可能敏感的数据、监控新漏洞，并决定哪些发现结果值得采取行动。

原始的组件匹配并不能自动证明存在暴露风险。易受攻击的代码可能被排除在构建之外、因配置而禁用，或在正常运行中无法触达。

Vulnerability Exploitability eXchange，即 VEX，可以提供关于产品是否受某一漏洞影响的机器可读声明。这些声明依赖稳定的标识符，将 VEX 记录连接到正确的 SBOM 组件。

这一关系解释了为何标识符质量变得更加重要。一条模糊的组件记录会削弱之后关于可利用性或修复措施的每一次描述。

这也说明了为何 CISA 的最低要素无法独立运行。组织还需要围绕清单建立漏洞数据库、VEX 数据、资产所有权信息、运行时上下文和响应工作流。

联邦承包商将首先感受到压力，因为各机构可以将这一基线纳入采购要求。企业客户也很可能将同样的问题用于供应商评估。

国际协调进一步放大了这一影响。服务多个市场的供应商若能生成一份可互操作的清单，而不是维护不同国家版本，将从中受益。

不过，只有客户以一致方式解读该基线，协调才能真正减轻负担。额外的合同特定字段、格式和交付规则，可能重新造成最低要素原本旨在避免的碎片化。

因此，软件团队应将该指南视为一份数据契约。生产者承诺提供明确程度的可见性，消费者则承诺负责任地处理这些数据。

工程知识库可以帮助团队将 SBOM 决策与构建记录、供应商文档和修复说明关联起来。它不能替代组件分析平台，但可以保留每项响应背后的决策依据。

更高的证据要求并非天然是坏事。当广泛使用的依赖项出现漏洞时，可重复生成的清单能够缩短查找受影响产品的时间。

只有当组织将生成流程与责任归属和行动衔接起来，这种益处才会显现。否则，改进后的 SBOM 只会成为又一个附件，直到审计开始才有人查看。

更好的 SBOM 数据仍无法保证更好的安全性

CISA 更丰富的基线改善了漏洞管理的输入，但不完整的依赖关系图仍可能导致危险的过度自信结论。

2026 年 7 月的一篇预印本研究了公开数据集中的 78,612 份 SBOM 文件，其中 77,092 份可被解析。研究人员关注的是依赖关系边，而不仅仅是检查组件字段是否存在。

他们的依赖关系图研究发现，52.9% 的可解析 SBOM 未声明任何依赖关系边。这些文件中的每个组件都呈现为孤立状态。

另有 8.8% 包含依赖关系块，但大多数组件仍未连接。在该组中规模较大的清单里，孤立组件占比的中位数为 93%。

总样本中仅有 38.3% 形成了连接良好的图。该研究还发现，即使工具检查的是可比的软件，不同生成器的图质量也存在显著差异。

这些发现来自预印本，不应被视为对私营企业清单的普遍衡量。尽管如此，它们仍说明了 CISA 强调依赖关系和已知未知项背后的实施问题。

扁平化清单可以回答某个软件包名称是否出现过。它无法可靠解释哪个应用程序包含该软件包、哪些组件依赖于它，或是否存在通向易受攻击代码的路径。

这一局限会影响优先级排序。当 SBOM 显示产品与受影响组件之间不存在路径时，一些安全系统会抑制该发现。

如果图不完整，“不存在路径”并不意味着“不可达”。它意味着清单缺少连接这些节点的证据。

该研究测试了一种方法，将可疑的否定结果转换为明确的未知状态。在其受控重新评分实验中，相对于 CISA 的已知被利用漏洞目录，召回率从 0.600 提升至 0.950。

这些数字描述的是研究人员的系统，而非对每个组织的保证性结果。其更广泛的教训是：不确定性必须在整个分析过程中保持可见。

这正是最低合规要求可能与运营安全产生分歧之处。一份文件即使包含所有指定字段，仍可能因发现过程浅显或关系断裂而错误呈现产品情况。

组件哈希值同样存在局限。哈希值可以验证两个对象是否相同，但无法说明该对象是否包含易受攻击的代码，或是否接收不安全的输入。

许可证字段也不能证明安全性。它们可以改善组件治理，但准确识别许可证并不能说明是否可被利用。

工具名称和生成上下文有助于消费者判断证据质量，但前提是消费者理解这些工具。当接收系统对其与构建后制品扫描区别处理时，记录“源代码扫描”才具有价值。

SBOM 也可能泄露敏感信息。详细的组件清单可能暴露架构选择、旧版依赖项，或攻击者可以研究的目标。

组织需要在访问权限与风险之间取得平衡的分发策略。公开的开源项目、受监管的医疗设备和受限的政府系统，并不需要完全相同的共享模式。

数据新鲜度带来了另一项挑战。软件发生变化后，除非生产者重新生成清单，且消费者将其与正确的发布版本关联，否则原本准确的清单会变得具有误导性。

云服务使这种关联更加复杂，因为其部署的组件可能发生变化，而客户并未下载新软件包。持续运行的服务需要静态产品清单无法提供的更新和通知机制。

AI 系统带来了更多模糊性。模型、数据集、适配器、远程 API、编排框架和传统库都会影响行为，但并非每个要素都适合传统组件字段。

新基线承认，专业化系统需要额外信息。它并未解决如何为持续变化的模型管线或外部托管依赖项建立清单的所有问题。

这些局限并不意味着 SBOM 毫无意义。它们界定了可见性与保证之间的边界。

配料表可以帮助识别被召回的原料，但无法证明厨房遵循了安全程序。安全开发、测试、补丁管理、监控和事件响应仍然必不可少。

因此，对该指南最恰当的理解并非“字段越多，软件越安全”。而是“当组织保留其上下文和不确定性时，更好的证据能够支持更好的决策”。

国际协调提高了利害关系

联合支持使 CISA 的更新成为一个参考点，可能影响远超美国联邦政府范围的软件采购。

软件供应链跨越国界。一个国家设计的产品可能包含由其他多个国家维护的开源软件包，并运行在其他地区运营的基础设施上。

不同的 SBOM 定义会在整条链路中造成摩擦。生产者必须转换字段、重新生成文件，或解释为何一个客户要求的数据并不存在于另一种格式中。

国际伙伴一直在推动形成对 SBOM 应实现目标的共同认知。他们参与 2026 年指南，强化了采用共同最低数据要求和机器可读交换方式的理由。

这种协调并不意味着形成一部全球统一法律。各国政府仍保留自己的采购规则、监管权限和执法时间表。

但它仍可能影响合同和技术预期。买方经常采用政府指南中的措辞，因为这能在供应商评估期间提供可辩护的基线。

欧盟《网络韧性法案》为销售含数字元素产品的制造商增加了紧迫性。其要求构成独立的法律框架，但软件清单和漏洞处理处于相近的运营领域。

医疗器械制造商则面临另一项既有应用场景。美国法律要求某些网络设备制造商提供 SBOM，以及处理上市后漏洞的流程。

当常用库或嵌入式组件成为目标时，关键基础设施运营商也需要快速获得答案。他们面临的挑战往往不在于识别某一项依赖，而在于跨多个供应商提供的长期运行系统中定位它。

只有上游供应商参与，共享基线才会发挥作用。最终应用程序的生产者未必能够识别从另一家公司获得的封闭二进制文件所包含的内容。

合同要求可以将这一请求推向供应链更深处。它们也可能使缺乏专门合规和安全工程团队的小型供应商处于不利地位。

CISA 对自动化的强调旨在减轻这一负担。现代开发工具可以在构建过程中生成清单，通用格式则让下游系统无需人工转录即可处理它们。

自动化同样会扩大错误。如果扫描器系统性地遗漏依赖项，每一份生成的 SBOM 都可能以令人印象深刻的一致性重复同一盲点。

因此，互操作性测试与格式选择同等重要。生产者应比较输出结果、验证关系图，并确认下游工具能够正确保留标识符。

消费者也需要遵守相应的纪律。在大规模索取 SBOM 数据之前，他们应明确这些数据将如何影响采购、监控、修复和供应商沟通。

商业软件联盟在 2025 年咨询期间支持协调统一的预期。它也警告称，如果接收方缺乏摄取信息并据此采取行动的能力，则不应施加采购要求。

这一立场概括了主要的政策权衡。要求提供证据可以推动更好的工程实践，但收集无法使用的证据会浪费资源，并制造虚假的控制感。

国际协调提高了利害关系，因为薄弱做法和良好做法一样容易传播。获得全球认可的基线应鼓励一致且有用的清单，而不是全球一致的文书工作。

三项信号将表明 2026 年基线是否有效

只有依赖关系质量得到改善、买方将数据投入运营，并且专业化 SBOM 实践保持互操作性，该指南才能成功。

第一个信号是依赖关系图可衡量的改进。未来研究应发现更少的扁平化清单、更少的断开组件，以及更多对明确完整性指标的使用。

这一结果将强化 CISA 的前提：更清晰的最低要素能够改善机器辅助的漏洞决策。若关系图持续失败，则说明仅靠定义无法纠正生成器行为。

第二个信号是联邦机构和企业买方如何改变采购方式。有价值的采用将把 SBOM 交付与验证、资产所有权、VEX 处理和响应预期联系起来。

如果请求只是给问卷增加一个上传字段，就会削弱其合理性。它们会增加供应商工作量，却不会提升安全决策的速度或质量。

第三个信号是传统、云端和 AI 清单之间的互操作性。专业化指南应扩展共同基线，而不应为标识符、关系或时间戳创建互不兼容的定义。

成功的协调将使组织能够通过云服务或 AI 应用追踪易受攻击的传统软件包。碎片化的模式将重新造成 2026 年更新试图弥合的可见性缺口。

软件生产者无需等待这些结果。他们可以检查当前清单，识别每份清单的生成方式，并测试关系能否在面向客户的系统摄取过程中得到保留。

买方也可以从另一侧开展同样的练习。询问一项新披露的漏洞能否从组件记录追踪到受影响产品、责任人、决策和修复状态。

这套工作流程才是对 CISA 网络安全指南的真正检验。如果你的组织今天收到一份准确的 SBOM，能否将这份证据转化为及时的安全决策？

从一款关键产品入手，追踪数据从构建到响应的全过程。缺失的环节将揭示：你的 SBOM 项目究竟是一项运营控制，还是仅仅是库存档案。