Summary

  • GAO在GAO-26-107530中记录：24个受访联邦机构中，17个机构的高级信息技术及采购官员表示，OMB和NIST的不同指引妨碍软件物料清单（SBOM）的收集与保存。这是机构报告的采购障碍，不是安全事故数量。
  • OMB旧备忘录M-22-18把收集清单当作可选事项，倾向于静态合规文件；NIST强调每个软件版本的组件信息应能服务漏洞管理。OMB于2026年1月撤销旧备忘录。现行M-26-05允许机构在合同中要求按需提供最新清单，并把软件与硬件安全责任交给机构负责人。
  • GAO要求网络安全和基础设施安全局（CISA）给出生成、接收、分析和使用清单的具体操作指引。下一份有效凭据，应当展示组件数据怎样从合同走进运行系统的风险决策。

文件签收之后，清单去了哪里

软件物料清单列出某个软件版本包含的组件。采购部门可以把它当作交付物：供应方上传，机构签收，合同档案多了一项附件。安全部门需要的是另一种能力：新漏洞涉及哪个组件，受影响的版本是否在本机构运行，谁有权决定修复。前一种流程在文件归档时结束；后一种流程需要版本对应关系、及时更新和明确的责任人。

GAO于2026年6月23日发布的云采购报告把这种断裂放在联邦机构的真实采购工作中。审计覆盖24个机构，17个机构的官员报告说，OMB和NIST对SBOM收集与保存的指引相互冲突。报告另有17个机构谈到云成本管理问题；相同的数字对应另一项调查结果，不能移来解释软件清单。GAO也没有把SBOM的17个回答当作违规机构或安全事故的计数。

完整审计文本写出了三处摩擦。旧版OMB指引把收集SBOM留作可选做法；NIST则要求软件生产方跟踪并共享每次发布的组件信息。OMB要机构建立收集流程；NIST看重生产方提供标准化数据。更深的差别在用途：一个是静态的合规材料，另一个能够进入漏洞扫描和风险管理。只写“提交清单”的采购条款，无法自动解决版本更新、数据读取和后续行动。

机构向GAO提供了更具体的麻烦。五个机构认为，不同联邦买家各有表格和流程，会增加同时服务多家机构的供应方负担；另有五个机构难以从生产方拿到清单，特别是通过转售商采购时。这两组机构可能重叠，不能加成十个。问题也不限于表格太多：合同关系与生产方之间多一道手，组件信息就可能在需要它的当天到不了运营人员手里。

旧备忘录已经退场，选择权留在机构

OMB于2026年1月23日发布的M-26-05撤销了M-22-18及M-23-16。旧备忘录可用来解释冲突从何而来，却已不是现行命令。新政策仍要求完整的软件与硬件资产清单、基于风险的管理流程，以及机构负责人承担安全责任。机构可以选择在合同中要求生产方按需提供最新SBOM；涉及云服务时，条款应指向实际运行的生产环境。

这将判断权交回每个机构。不是所有软件采购都需要同样的组件证明；但决定要清单的买家，必须说清楚何时索取、覆盖哪个版本、经由谁交付、收到后由谁使用。GAO认为新备忘录澄清了责任，却没有消除机构已报告的实施难题。一个可选的文件，如果合同没有保证及时送达，或安全团队无法将它与运行系统对应，仍只是一张便于归档的纸。

NIST的软件供应链资料把组件信息放进软件安全工作。CISA于2025年9月发布的共同愿景文件主张在风险管理和开发流程中生成、接收、分析SBOM。GAO指出，这份愿景尚未说明机构具体怎样把数据接进现有工具与流程。政策可以提出目的；采购与运营需要交接说明。

CISA下一份指引必须写出交接动作

GAO建议国土安全部让CISA提供进一步实施指引，覆盖采购、开发和风险管理里的SBOM生成、接收与分析。国土安全部接受了建议，并在答复中预计于2026年9月30日前完成相关工作。预计日期是一项承诺，不能代替已发布、可检验的指引。在本文核查时，GAO公开建议页面仍将该项标为Open。

真正有用的指引应该回答几个朴素问题：生产方怎样标明组件属于哪个发布版本或云服务运行环境？通过转售商采购的机构怎样及时拿到数据？什么格式能被安全工具读取？漏洞出现后谁比对、谁作决定、谁留下记录？如果这些步骤分别落在不同部门，没有人负责接合，联邦政府就会得到越来越完整的文件柜和越来越迟缓的风险判断。

能够改变这一判断的，是CISA发布明确描述这些交接的正式指引，以及机构合同或工作流程证明数据确实被用于现行软件。GAO已经找到规则的裂缝。下一步应证明，一份清单离开采购桌后，能够走到需要它的人面前。

Sources