SBOM 字段实操指南：NTIA 七要素之外还该填什么

七要素是门槛，不是天花板

每次讨论 SBOM 该怎么填，对话往往止步于 NTIA 的七要素清单——供应商、组件名称、版本、唯一标识、依赖关系、SBOM 作者、时间戳。检查完这七项，有人就认为工作完成了。

这个判断在 2021 年《行政令 EO 14028》刚落地时或许勉强成立。但当 FDA 于 2023 年 3 月起正式要求医疗器械上市申请必须附带完整 SBOM，EU CRA 将在 2027 年 12 月全面适用并开出最高 1500 万欧元或全球营收 2.5% 的罚款，汽车领域 UN R155 / ISO 21434 与国内 GB 44495 强制国标相继生效，七要素的"最低可行"定位就越来越尴尬了。

问题不在于七要素是错的，而在于它们在实操中极容易填错，且填完之后还有大量决定 SBOM 实际价值的字段被忽视。本文按照从"必填"到"强烈建议"的顺序逐一拆解，重点标出高频陷阱，供负责 SBOM 生产或消费的工程师、合规负责人参考。

---

逐字段拆解：七要素的常见填错方式

1. 供应商名称（Supplier Name）——歧义最多的字段

这是实操中最容易产生歧义的字段。同一个组件，上游可能有多个"供应商"身份：原始作者、打包维护者、镜像分发者、内部二次封装者。

典型陷阱：把包注册表名称（如 npmjs.com）填入供应商字段，或把 Git 用户名与法人主体混用。对于企业内部 fork 或私有镜像，供应商字段应当明确标注内部标识，而非照抄上游名称——否则在漏洞响应时根本无法快速判断"这个组件到底谁在维护"。

SPDX（ISO/IEC 5962）规范中，PackageSupplier 支持 Organization: 和 Person: 前缀，CycloneDX（已成为 Ecma 标准）则在 supplier 与 author 之间做了更细致的区分。选型时应与下游消费方对齐，避免解析歧义。

2. 组件版本（Version）——"无版本"不等于可以留空

对于从源码构建、未打 tag 的内部组件，版本字段留空会让漏洞匹配彻底失效。正确做法是填入 Git commit SHA 的缩写（至少 12 位），并在附加字段中说明版本来源类型。

3. 唯一标识（Unique Identifier）与哈希——两者不可互相替代

唯一标识（PURL 或 CPE）解决的是"这是哪个组件"的问题，哈希解决的是"这是组件的哪个构建产物"的问题。两者缺一不可，却经常被混淆或只填其一。

PURL（pkg: 格式）已成为跨生态互操作的事实标准，覆盖 npm、Maven、PyPI、Cargo 等主流包管理器。CPE 在政府采购和 NVD 漏洞匹配场景仍有不可替代的地位。

哈希算法的选型同样有讲究：MD5 和 SHA-1 在完整性校验场景已不够用，SHA-256 是当前最低要求，对于高安全等级场景应使用 SHA-512。哈希对象应明确是压缩包还是解压后的文件树，否则两端校验必然对不上。片段级 SCA 与清单级 SCA 的差异在这里尤为关键——清单只能给出声明版本，哈希才能证明实际使用的代码与声明一致。

4. 依赖关系（Dependency Relationships）——深度不够等于没填

这是七要素中信息密度最低、最容易被敷衍的字段。只声明直接依赖，不展开传递依赖，SBOM 的漏洞覆盖率会大幅缩水。Log4Shell（CVE-2021-44228，2021 年 12 月）的大面积扩散，相当程度上正是因为多数组织不知道自己的应用栈里有多少层传递依赖带入了 log4j-core。

实操建议：

• 传递依赖至少展开到三层，对于安全敏感系统建议全量展开
• 区分 DYNAMIC_LINK、STATIC_LINK、CONTAINS 等关系类型，而非统一用 DEPENDS_ON
• 开发依赖（devDependency）与运行时依赖必须分别标注，买方在做风险评估时关注点截然不同

5. SBOM 作者与时间戳——生命周期管理的起点

时间戳不只是"SBOM 是什么时候生成的"，它决定了这份 SBOM 在什么条件下应该被视为失效。建议同时填写 created（初次生成）和 documentNamespace 中的版本标识，配合 CI/CD 流水线在每次构建时自动刷新，而不是作为一次性文档手动维护。

---

七要素之外：哪些字段真正影响可用性

七要素打完地基之后，以下字段决定 SBOM 能否被机器消费、能否支撑漏洞响应、能否满足审计要求。

许可证字段（License）

SPDX License Expression 支持复合表达式（如 Apache-2.0 AND MIT），应当同时填写 DeclaredLicense（包元数据中声明的）和 ConcludedLicense（经扫描工具实际确认的）。两者不一致时，需要人工审核而非自动覆盖。许可证冲突检测的实操方法值得单独深入。

生命周期状态（Lifecycle / EOL）

Python 2 于 2020 年正式 EOL，AngularJS 于 2022 年 EOL，Log4j 1.x 早在 2015 年即已停止维护——但这些组件至今仍大量出现在生产环境的 SBOM 中，且没有任何字段标注其 EOL 状态。CycloneDX 的 lifecyclePhase 字段和自定义属性均可承载这一信息，建议列为必填项。停止维护的开源组件风险值得专门评估。

VEX 关联字段——漏洞可利用性的上下文

VEX（Vulnerability Exploitability eXchange）不属于 SBOM 本体，但与 SBOM 高度耦合。一份没有 VEX 的 SBOM 遇到漏洞公告时，消费方只能知道"组件存在该 CVE"，无法判断"在当前部署场景下是否真正可利用"。

VEX 的四个核心状态——not_affected、affected、fixed、under_investigation——配合影响陈述（impact statement）和操作陈述（action statement），才能构成完整的漏洞响应链条。EU CRA 的报告义务（2026 年 9 月 11 日起生效）明确要求制造商提供可利用性评估，VEX 是目前最成熟的机器可读载体。

构建信息与 SLSA 出处（Provenance）

组件是如何构建的、由哪条流水线产出、构建环境是否可复现——这些信息在供应链投毒场景（如 2024 年 3 月曝光的 xz 后门 CVE-2024-3094）中具有决定性的溯源价值。CycloneDX 的 externalReferences 和 buildMetaData 字段，配合 SLSA 出处文档，是目前最可操作的填写路径。

---

买方与卖方：关注重点不对称

SBOM 的生产者（软件卖方）和消费者（采购方/运营方）对字段的优先级判断往往存在明显不对称，这种不对称如果不在合同阶段对齐，会在漏洞响应时产生严重摩擦。

卖方通常更关注：

• 字段是否满足合规提交要求（FDA、CRA、GB 44495）
• 生成工具链的覆盖率与自动化程度
• 内部敏感信息（自研组件名、内部拓扑）是否需要脱敏

买方通常更关注：

• 哈希是否可验证（防止 SBOM 与实际交付物不一致）
• 传递依赖是否完整展开
• VEX 是否随漏洞公告持续更新，而非一次性附件
• EOL 组件是否有明确标注和替换计划

建议在采购合同或技术附件中明确约定：SBOM 格式版本、更新频率、VEX 响应时限、以及争议字段（尤其是供应商名称和版本）的填写规范。SBOM 从合规要求到能力建设的路径提供了更完整的治理框架参考。

对于需要处理二进制交付物的买方，仅凭 SBOM 声明内容无法核验实际成分，CleanBinary 的二进制成分分析能力可以从产物侧反向验证 SBOM 的准确性。对于希望在研发阶段即建立 SBOM 生产规范的团队，CleanSource SCA 支持覆盖 600 余种包管理生态、基于 3.2 亿组件指纹的全量依赖解析，可直接输出 SPDX 和 CycloneDX 格式；轻量化起步可选择 CleanSource SCA CE 社区版。PureStream 则在合规治理层面提供 AI 驱动的策略编排，适合需要跨团队统一 SBOM 质量基线的场景。

---

结语：字段质量决定 SBOM 的实际价值

SBOM 的价值不取决于它有多少字段，而取决于每个字段是否准确、是否机器可读、是否在组件生命周期内持续维护。一份七要素齐全但哈希不可验证、依赖关系只有一层、供应商名称前后不一致的 SBOM，在漏洞响应时能提供的帮助极其有限。

从 xz 后门到 Shai-Hulud npm 蠕虫（2025 年 9 月），供应链攻击的手法在持续演化，而防御侧的信息质量必须至少与攻击面的复杂度同步提升。把 SBOM 从一次性合规文档变成持续更新的软件物料账本，字段规范是起点，工具链自动化是保障，买卖双方的合同约定是纽带。

关于 SBOM 完整体系的建立，可参考《SBOM 完全指南》；医疗器械行业的具体合规路径，可参考医疗器械 SBOM 合规实践。

---