一句话定义：SBOM（Software Bill of Materials，软件物料清单）是一份机器可读的清单，列出某个软件或系统里用到的所有组件、依赖、版本、来源和许可证，相当于软件的"配料表"。
为什么需要它
买一盒饼干，包装背面会写清楚：面粉、糖、植物油、乳化剂……一旦某批原料出问题，厂家能立刻查出哪些产品用了它，召回范围也能精确到批次。软件也一样，只是"配料"变成了开源库、框架、驱动和模型文件。
一个 AI 应用远不止一个模型文件。它通常还包含训练框架、推理引擎、Python 依赖、CUDA 驱动、容器基础镜像、预训练权重、微调脚本、数据处理代码等。这些组件层层嵌套：你直接安装的包 A 依赖 B，B 又依赖 C。SBOM 要做的，就是把这棵树完整记下来，包括每一层的名称、版本、来源和许可证。
它的价值在"出事"时才真正体现。假设某个被广泛使用的开源日志库爆出严重漏洞，没有 SBOM 的团队只能靠人肉翻代码、翻构建脚本，猜测"我们好像用过"；有 SBOM 的团队可以直接查询：有没有用？哪个版本？是哪个服务、哪个镜像带进来的？影响面多大？这就是从"大概可能"到"精确定位"的差别。
和相邻概念的区别
| 概念 | 回答的问题 | 关注点 |
|---|---|---|
| SBOM | 这套系统由哪些零件组成？ | 组件、依赖、版本、来源、许可证 |
| 漏洞扫描 | 这些零件有没有已知问题？ | 拿清单去比对漏洞库 |
| 模型卡（Model Card） | 这个模型能做什么、有什么限制？ | 用途、数据、评估、风险 |
| 依赖锁文件（lockfile） | 这次构建具体装了哪些包？ | 通常只覆盖某一种包管理器，面向构建而非审计 |
简单说，SBOM 是"清单"，漏洞扫描是"拿清单去查病历"，模型卡是"说明书"。三者互补，不能互相替代。SBOM 本身也有格式标准，比如 SPDX、CycloneDX，具体支持情况以官方页面为准。
对从业者和普通人的意义
对 AI 从业者，SBOM 正在从"加分项"变成"合规项"。不少采购方和行业规范会要求供应商随软件交付 SBOM；出了安全事件，它也是最快划定影响范围的工具。对普通职场人，你未必亲手生成 SBOM，但可以记住一个判断：当厂商说"我们已修复"时，能拿出 SBOM 的团队，通常更清楚自己到底修了什么、还有没有漏网之鱼。
AI 供应链的特殊难点在于，模型权重、数据集、GPU 驱动这些"配料"往往不在传统包管理器的视野里，因此 AI 场景的 SBOM 比普通软件更难做全。但方向是明确的：先把能记的记下来，再逐步补齐。