SBOM（Software Bill of Materials，软件物料清单）就是你软件的「配料表」：一份镜像里所有 软件包、库、版本与依赖的完整清单。就像营养成分表一样，它明明白白告诉你里面装了什么。
它的价值会在关键漏洞爆发的那天显现：你不必手工翻查几十份镜像，只要查一下 SBOM，几秒内就知道 哪些镜像含有受影响的组件、版本是多少。
它为何对你的镜像重要
- 快速响应 CVE：立刻判断某个新漏洞是否波及你。
- 供应链安全：你清楚每个组件的来路。
- 合规：越来越多的框架与客户把它当作证据来索要。
- 透明度：如果你对外发布镜像，SBOM 会让使用者更放心。
标准格式
| 格式 | 出处 | 说明 |
|---|---|---|
| SPDX | Linux 基金会 / ISO | ISO 标准，在合规场景中广泛使用 |
| CycloneDX | OWASP | 面向安全，做漏洞分析时信息更丰富 |
两种占主导地位的 SBOM 格式；很多工具都能同时导出。
一步步为镜像生成 SBOM
- 选工具：Anchore 的 Syft 是为镜像与文件系统生成 SBOM 的事实标准；云上也有原生方案。
- 在流水线里生成：构建 AMI 的过程中扫描文件系统并产出 SBOM，例如同时输出 CycloneDX 与 SPDX。
- 分析漏洞：把 SBOM 交给 Grype 或 Trivy，与 CVE 数据库做比对。
- 签名并归档：给 SBOM 签名——比如用 cosign——并作为与该镜像版本绑定的产物保存下来。
- 需要时查询：新的 CVE 出现时，翻查归档的 SBOM 就能确定影响范围。
2026 年的监管背景
多年来，SBOM 作为供应链安全的良好实践分量越来越重。不过监管图景是有层次的：在美国，行政部门 于 2026 年把沿袭下来的软件证明要求改为更偏向基于风险的路线；而在欧盟，《网络韧性法案》一类的 规则则在推动软件透明度与组件清单。实用的结论是：无论监管如何摇摆，拥有 SBOM 都是一种防御上与 商业上的优势，值得采用。
最佳实践
- 每次构建都自动生成 SBOM，而不是靠人手。
- 把它与对应镜像一起做版本保存。
- 与漏洞扫描结合，让它变得可操作。
- 为它签名，以保证完整性与来源可信。
常见问题
SBOM 和漏洞扫描是一回事吗？
不是。SBOM 是组件清单；扫描则拿这份清单与 CVE 数据库比对，找出漏洞。两者互补：先知道你有什么， 再判断它是否有漏洞。
该选 SPDX 还是 CycloneDX？
SPDX 是 ISO 标准，在合规中用得很多；CycloneDX 更偏安全。很多工具两种都能导出，所以你不必只选 一个。
如果我只使用第三方镜像，还需要 SBOM 吗？
需要。为你所用的镜像索要或自行生成 SBOM，能让你评估其风险、在漏洞出现时快速反应——哪怕镜像不是 你构建的。
在 imaxe.cloud，我们押注可追溯性：把镜像里的软件登记造册并写清楚，本就是「把镜像做好」的一 部分。
sbomspdxcyclonedxsyft供应链
