SBOM 是什么
SBOM（Software Bill of Materials，软件物料清单）描述一个应用或镜像由哪些组件、什么版本、来自哪里组成。它本身不修漏洞，解决的是新漏洞公布后“多快说清影响面”的问题：Log4Shell 这类事件的应急时间，大头都花在确认“我们哪里用了这个组件”。落地可以先是一份随版本归档的依赖清单，成熟后再统一到 SPDX/CycloneDX 这类标准格式。
基本信息
| 适用对象 | 自研应用、容器镜像、外购交付物 |
|---|---|
| 产出物 | 组件名 + 版本 + 来源 + 依赖关系 |
| 常见载体 | SPDX/CycloneDX 文件、package-lock.json、pip freeze 输出 |
| 维护时机 | 每次构建或发版同步归档 |
| 验收要点 | 关键应用能查到任意组件的版本 |
典型使用场景
- 新 CVE 公布：按组件名检索清单，圈出受影响的应用与主机
- 合规问卷与项目验收：甲方要求提供组件清单或依赖报告
- 供应链评估：核对交付物是否夹带未声明的开源组件
- 基础镜像治理：确认镜像内组件版本与官方基线是否一致
- 升级决策：评估旧版本还有哪些系统在用，排定替换顺序
最小可行做法
最小可行做法
# Java 应用：导出依赖树并随版本归档
mvn dependency:tree -DoutputFile=deps-2026-10-13.txt
# 兜底盘点：直接列出应用目录下的 jar 清单
find /opt/app -name '*.jar' | sed 's#.*/##' | sort > sbom/jars-2026-10-13.txt
# Node 前端：提交 lock 文件即是最小 SBOM
cp web/package-lock.json sbom/web-lock-2026-10-13.json
# Python：冻结实际安装版本
pip freeze > sbom/requirements-2026-10-13.txt
# 容器：导出镜像配置，作为运行时组件的补充证据
docker image inspect registry.local/app:1.4.2 --format '{{json .Config}}' > sbom/image-config.json清单最小要素
| 字段 | 含义 | 缺失后果 |
|---|---|---|
| 组件名 | 依赖库或包的标识 | 无法与 CVE 中的组件名对齐 |
| 版本 | 精确版本号（含小版本） | 无法判断是否落在受影响区间 |
| 来源 | 上游仓库、供应商或构建产物 | 无法评估供应链风险与替代来源 |
| 依赖关系 | 直接依赖还是传递依赖 | 误判修复优先级，改错地方 |
| 部署位置 | 在哪些镜像、主机、环境 | 找到组件却找不到受影响的系统 |
不必等格式标准确定才动手：先做到“清单随版本归档、可检索”，格式统一放到第二阶段。
清单会暴露内部组件与版本，对外提供时按需裁剪字段，只交付对方确需的部分。