美国网络安全和基础设施安全局（CISA）于 2025 年 8 月发布了《软件物料清单（SBOM）最基础要素》更新草案，这是自 2021 年 NTIA 发布首个 SBOM 标准以来最重要的一次更新。本文将结合 CISA 官方文档和 OpenSSF 专家观点，为您深度解析此次更新的技术要点和行业影响。

SBOM 最基础要素：为何此时更新？

SBOM 作为软件供应链安全的"基石"，通过机器可读的格式记录软件成分信息，使组织能够快速响应漏洞、管理许可证合规性。经过四年的实践发展，SBOM 工具链和行业实践已显著成熟，原有的 2021 版已无法满足当前需求。 主要驱动因素：

• SBOM 采用率大幅提升，涌现出新用例和应用场景

• SBOM 工具功能显著增强，支持更精细化的数据采集

• 联邦政府软件认证要求（OMB M-22-18 备忘录）的推动

技术要素更新详解：三大类别全面升级

数据字段（Data Fields）更新 

新增字段（3 个）：

Component Hash（组件哈希值）

要求提供组件的加密哈希值（如 SHA-256）

如无法获取原始组件工件（Component Artifact），应明确标注 

对此，行业专家 Lieberman 指出，在软件物料清单（SBOM）中引入组件哈希值可能是最关键的一项改进。由于同一软件包即使版本号相同，若来源不同（如来自 Red Hat 或 Debian），其构建过程也可能存在差异，导致实质上成为不同的组件。哈希值如同唯一指纹，能够精确标识出具体的构建版本，从而在出现安全漏洞时帮助快速定位受影响范围。例如之前的 XZ 后门事件仅波及部分 Linux 发行版，通过比对哈希值即可准确判断自身是否受影响，实现精准修复。此外，记录组件在构建前、构建中或构建后等不同阶段的上下文信息也十分重要，其中构建过程中生成的信息通常最为完整。

更进一步来看，当 CVE 披露某一漏洞时，往往不会覆盖所有代码仓库中的相关组件。例如，某 CVE 可能仅提及 GitHub 上的组件版本，而 Maven 中的同一版本却未在列，尽管漏洞实际存在。由于不同来源的组件哈希值不同，建立它们之间的关联就成为精准定位漏洞的关键。

而这一关联需求，恰好需要专业工具通过技术手段来打通组件的溯源链路，安势信息旗下的清源 SCA 产品，正是基于 AI 专家模型构建开源软件基因图谱，先深入分析不同分发源组件之间的关联关系（从技术层面解决哈希值差异化带来的关联难题），再依托图谱能力追溯组件的原始代码源与分发路径，清晰呈现组件之间的血缘、传递及失效等关系，最终保障开源组件在整个链路中溯源的准确性与可靠性。

License（许可证信息）

    必须以机器可读格式记录组件许可证

    需标注专有许可证条件，未知许可证需明确声明

Tool Name（生成 SBOM 的工具名称）

• 记录用于生成 SBOM 的工具名称

  支持列出多个工具（生成、增强、扩充）

重大更新字段（6 个）：

• SBOM Author ↔ Software Producer：明确区分 SBOM 作者与软件生产者

• Component Version：版本不可用时，可用文件创建日期替代

• Software Identifiers：要求至少包含一个软件标识符（CPE、purl 等）

• Dependency Relationship：要求记录派生关系（如分支、回溯移植）

• Generation Context：新增生成上下文（构建前、构建中、构建后）

自动化支持要求强化 

CISA 明确支持 SPDX 和 CycloneDX 两种主流格式，强调：

• 必须支持机器可读和互操作

• 避免使用已弃用的格式版本

• 定期评估支持的数据格式

实践与流程优化

Coverage（覆盖范围）取代 Depth（深度）：

    要求包含所有组件（包括传递性依赖）

    不再限定最小深度，强调水平广度

    元数据不同的组件实例需单独列出

Known Unknowns（已知未知）精细化：

    将“已知但被故意隐瞒的信息”和“SBOM 作者根本不知道的信息”明确区分

    目的是为了消除“已知的未知”这个概念的模糊性，增强 SBOM 的透明度和可信度

机遇与挑战

云环境 SaaS 应用的 SBOM 挑战与演进

将 SBOM 应用于云端的 SaaS 服务，其逻辑与传统本地软件截然不同。核心挑战在于 SaaS 的安全责任由生产者和运营者共担，且软件版本持续高频更新。这导致传统的 SBOM 分发模式难以直接套用——双方都可能被海量的版本清单淹没。可行的思路是转变静态分发的思维，利用 API 等自动化接口，在 CI/CD 流程中动态生成和提供 SBOM“快照”，使其与 SaaS 的敏捷交付模式相匹配。必须承认，尽管存在适配难题，但实现 SaaS 软件成分透明化的目标不仅依然重要，而且势在必行。未来的关键将是为云环境定义更具体的实施细则和可能的扩展字段。 

AI 软件系统对 SBOM 提出的新课题

AI 软件系统（如包含专用模型和数据的应用）的复杂性对 SBOM 构成了新的前沿挑战。其特有组件（如训练数据集、模型架构文件）所蕴含的风险，已超出了当前 SBOM 最基础要素的覆盖范围。随着 AI 日益融入关键系统，确保对这些“黑盒”组件的可见性已成为风险管理的关键。虽然现行标准明智地暂未引入 AI 专用字段，但业界的讨论早已开始，焦点在于未来可能需要增补哪些信息（如模型溯源、数据谱系）才能有效评估 AI 系统的风险。这预示着 SBOM 标准本身需要为一个由 AI 驱动的软件未来而持续演进。 

确立 SBOM 的可信基石

SBOM 的价值实现，根本上依赖于其自身的可信度。为确保这份“成分清单”的真实与完整，验证环节不可或缺，这主要包括两大层面：一是来源可信，需要通过数字签名等密码学手段来验证 SBOM 的生成者身份并防止数据在传输中被篡改，这要求组织将 SBOM 纳入现有的软件签名与密钥管理体系；二是内容可信，即 SBOM 清单是否准确、全面地反映了软件的实际构成。仅凭生产者提供的信息可能不够，主动使用二进制分析等工具进行审计验证，或与开源仓库等第三方数据源进行交叉比对，成为发现未声明组件、确保清单完整性的关键步骤。 

从清单到行动——SBOM 与安全公告的联动

SBOM 提供了软件的“静态地图”，而 VEX、CSAF 等安全公告则提供了关于漏洞的“动态情报”。二者结合，才能将成分数据转化为高效的漏洞管理行动。SBOM 使得组织在收到漏洞通告时，能瞬间定位自身资产中是否存在受影响组件，将响应时间从天甚至周缩短至分钟级。而 VEX 公告的精妙之处在于，它不仅能通告风险，更能精准“降噪”——当权威判定某个漏洞在特定产品环境中不可被利用时，可避免团队进行不必要的应急响应，从而集中资源处理真正迫在眉睫的威胁。这种“地图”与“情报”的联动，实现了从被动响应到主动、精准的风险管控。

中国企业技术实施建议

为构建软件供应链透明化的核心能力，组织需从基础能力建设入手，立即展开行动。这一阶段的关键在于务实推进三方面工作：

首先，结合自身技术栈与资源情况，合理选型 SBOM 生成工具，无论是采用开源方案还是商业平台，核心是确保工具能有效覆盖现有开发环境；

其次，将 SBOM 生成无缝嵌入 CI/CD 流水线，使其成为自动化构建流程的必备环节，实现每次构建产物都附带对应的成分清单；

最后，建立 SBOM 数据质量验证机制，通过自动化脚本或人工抽查等方式，确保证据链的准确性与完整性，为后续风险分析奠定可靠基础。

着眼长远发展，组织应制定生态参与战略，从标准追随者转变为生态贡献者。积极参与 SPDX、CycloneDX 等国际标准的讨论与制定，不仅能提前把握技术演进方向，更能将自身实践反馈到标准建设中；同时，需要建立内部的 SBOM 质量度量体系，定义覆盖度、准确率、更新时效等关键指标，持续优化生成与管理流程；此外，应前瞻性探索区块链等创新技术在 SBOM 完整性验证中的应用，利用其不可篡改特性构建可信的溯源链条，为未来软件供应链的合规审计与信任传递提供技术支撑。

监管要求成为推动 SBOM 普及的核心驱动力

行业数据显示，SBOM 应用呈现显著增长态势：Snyk 的 2024 年度报告显示 62.4%的企业已实施 SBOM 监控，而 Anchore 的调查更表明 78%的机构计划在未来 18 个月内扩大 SBOM 使用。行业专家指出，此前 SBOM 的推广进度曾面临动力不足的困境，但如今政策环境已发生根本性转变。美国政府 2021 年行政命令的实施效果显著，Sonatype 发布的白皮书显示，行政命令促使了 92%的大型企业将 SBOM 纳入实施计划，其中 60%的企业更将其作为供应链合作的强制要求。

欧盟《网络弹性法案》（CRA）的出台更将 SBOM 推广推向新阶段。尽管该法案豁免了非商业性开源开发者，但所有进入欧洲市场的软件供应商都必须满足合规要求。因此，即使企业不直接对欧销售，其客户也可能受到 CRA 约束，从而形成链式反应——终端厂商的合规需求将沿着供应链向上传递，最终使 SBOM 成为全球软件行业的准入门槛。这种基于法规的传导机制，正推动 SBOM 从可选实践转变为不可或缺的合规要素。

FDA 最新发布的 2025 版网络安全指南，对比 2023 版也有了很大更新。其中，第七章详细阐述了为满足 524B 节要求，上市前提交（510(k)、PMA、De Novo 等）必须包含的资料，将 2023 版的建议性文档要求转化为了“网络设备”的法定动作：

“软件物料清单 (SBOM) (对应 524B(b)(3)节)：必须提供包含商业、开源和现成软件组件的 SBOM。指南推荐了具体的格式和应包含的额外信息，如软件支持级别和终止支持日期。”

CISA 此次更新标志着 SBOM 从"可有可无"走向"必不可少"。随着欧盟 Cyber Resilience Act、FDA 网络安全指南等全球监管要求的落地，软件成分透明化将成为市场准入的基本要求。

CISA 2025 版 SBOM 最基础要素的发布，为软件供应链安全建立了新的技术基准。对于中国企业而言，及早掌握新标准、布局技术能力，既是安全合规的要求，更是提升全球竞争力的关键。

在软件定义一切的时代，透明成为新的安全范式。现在正是投身 SBOM 实践、构建数字信任的最佳时机。

References

https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf

关于安势信息

上海安势信息技术有限公司是国内先进的软件供应链安全治理解决方案提供商，核心团队来自 Synopsys、华为、阿里巴巴、腾讯、中兴等国内外企业。安势信息始终坚持 DevSecOps 的理念和实践，以 AI、多维探测和底层引擎开发等技术为核心，提供包括清源 CleanSource SCA（软件成分分析）、清源 SCA 社区版、清正 CleanBinary (二进制代码扫描)、清流 PureStream（AI 风险治理平台）、清本 CleanCode SAST（企业级白盒静态代码扫描）、可信开源软件服务平台、开源治理服务等产品和解决方案，覆盖央企、高科技、互联网、ICT、汽车、高端制造、半导体 &软件、金融等多元化场景的软件供应链安全治理最佳实践。

欢迎访问安势信息官网https://www.sectrend.com.cn 或发送邮件至 info@sectrend.com.cn 垂询。