SBOM 解决什么问题
SBOM（软件物料清单）记录交付物里的组件与版本，回答「这个制品里究竟有什么」。用 syft 生成清单、用 grype 依据清单比对已知漏洞，可以在新问题披露时快速定位哪些系统受影响，而不必一台台去翻。它是供应链事件响应的基础数据，也让许可证盘点与依赖治理有据可依。
基本信息
| 常见工具 | syft 生成清单，grype 依据清单比对漏洞 |
|---|---|
| 标准格式 | SPDX 与 CycloneDX 较常用 |
| 覆盖对象 | 源码目录、容器镜像、文件系统 |
| 主要用途 | 成分透明、供应链事件响应、许可证盘点 |
| 更新节奏 | 每次构建重新生成，与制品一起归档 |
| 关联环节 | CI 构建流水线与制品仓库 |
环节与做法
| 环节 | 做法 | 注意 |
|---|---|---|
| 生成 | syft 指向目录或镜像，输出标准格式 | 源码与镜像成分不同，按需要分别生成 |
| 归档 | 与构建产物一起存放 | 记录构建号与生成时间 |
| 比对 | grype 依据清单扫描漏洞 | 设定失败阈值，避免只产出不判断 |
| 追溯 | 按组件名与版本反查受影响系统 | 需与资产台账或构建记录关联 |
| 更新 | 每次构建重新生成 | 只在发布节点做一次会失真 |
生成与比对
生成与比对
# 从源码目录生成 SPDX 清单
syft packages dir:./app -o spdx-json > sbom.json
# 从容器镜像生成 CycloneDX 清单
syft image myapp:1.0 -o cyclonedx-json > sbom-image.json
# 依据清单做漏洞比对，命中高危时返回非零退出码
grype sbom:./sbom.json --fail-on high
# CI 中把清单与制品一起归档，便于事后追溯典型使用场景
- 供应链事件响应：某组件爆出问题时定位影响范围
- 上线前的成分与开源许可证核查
- 制品归档与留痕要求的落地
- 第三方组件引入评审的输入材料
- 定期盘点过时依赖与废弃库
- 客户或监管要求提供成分清单时直接输出
突发组件级事件时，有完整 SBOM 的团队可以在数分钟内定位影响范围，没有的只能按周盘点。两者的差距主要体现在响应速度和结论可信度上。
SBOM 生成一次就封存等于没有：后续构建未同步更新时，事件来临拿到的清单与实际运行版本不一致，结论会误导决策。