4、SBOM生命周期管理：从创建到归档的全流程
SBOM不是一份静态的文档。它像软件本身一样，有生命。
我见过太多团队把SBOM当成「一次性交付物」——发布前跑个工具生成一份，扔给客户就完事了。结果呢？漏洞爆发时，没人知道该用哪份SBOM去排查。说白了，SBOM的价值在于它能不能被持续地创建、分发、更新、消费，最后归档。这五个环节，缺一个都不行。
核心观点：SBOM的生命周期必须与软件的开发、交付、运维流程深度绑定。脱离流程谈SBOM，就是纸上谈兵。
4.1 创建：SBOM的起点
创建SBOM，说白了就是回答一个问题：你的软件里到底用了什么？
我习惯把创建方式分成三类：
| 创建方式 | 适用场景 | 典型工具 | 我的建议 |
|---|---|---|---|
| 源码级扫描 | 自研项目、有完整源码 | Syft、Trivy、FOSSology | CI流水线中必做 |
| 二进制分析 | 第三方组件、遗留系统 | tern、Dependency-Check | 用于无法获取源码的场景 |
| 清单导入 | 供应商提供、手动维护 | SPDX工具、Excel模板 | 仅作为兜底方案 |
我的经验：别只依赖一种方式。我在一个嵌入式项目中遇到过——源码扫描显示用了OpenSSL 1.1.1，但二进制分析发现实际链接的是1.0.2。两种结果不一致，最后查出来是构建脚本写死了旧版本路径。所以，交叉验证很重要。
创建时要注意几个关键字段：
- 组件名称和版本——必须精确，别写「>=1.0」这种范围
- 供应链关系——是直接依赖还是传递依赖？
- 许可证信息——别漏了，合规审计全靠它
- 校验和——SHA256起步，确保完整性
4.2 分发：让SBOM跟着制品走
SBOM创建出来，得让人家能拿到。分发方式我见过三种主流做法：
- 嵌入制品——把SBOM塞进容器镜像的label里，或者放在OCI artifact中。这是我最推荐的方式，因为SBOM和制品永远在一起。
- 独立分发——通过API、文件服务器、或者专门的SBOM仓库来提供。适合需要集中管理的场景。
- 签名后分发——用GPG或Sigstore给SBOM签名，确保来源可信。嗯，这个在供应链安全要求高的项目里是必选项。
⚠️ 避坑指南：我曾经遇到一个客户，把SBOM放在内部Wiki上，版本号用手写。结果漏洞爆发时，根本分不清哪个SBOM对应哪个版本的制品。后来我们强制要求：SBOM必须作为CI/CD产物的一部分，和制品一起发布。这才把问题解决。
4.3 更新：SBOM不是一次性的
软件会变，SBOM也得跟着变。更新的触发条件有哪些？
- 依赖变更——新增、升级、降级一个组件
- 漏洞修复——打了补丁后，版本号变了
- 许可证变更——组件换了许可证
- 定期刷新——即使没变，也建议定期重新生成一次
更新策略有三种：
| 策略 | 做法 | 优点 | 缺点 |
|---|---|---|---|
| 全量更新 | 每次重新生成完整SBOM | 简单、完整 | 文件大、传输慢 |
| 增量更新 | 只记录变化的部分 | 轻量、高效 | 需要维护基线 |
| 差异更新 | 对比新旧版本，生成差异报告 | 便于审计 | 工具支持有限 |
我个人习惯的做法是：每次构建都生成全量SBOM，同时保留历史版本。存储成本不高，但排查问题时省心太多。
4.4 消费：SBOM的价值兑现
SBOM不是用来收藏的。它的价值在于被消费。消费场景主要有三个：
- 漏洞扫描——把SBOM喂给漏洞库，匹配已知CVE。我常用的是Grype搭配Syft生成的SBOM，效果不错。
- 许可证合规——检查有没有GPL污染、或者不允许商用的许可证。
- 供应链风险评估——看依赖的组件有没有维护、有没有已知的安全事件。
关键点：消费工具必须能解析你使用的SBOM格式。SPDX、CycloneDX、SWID是三大主流格式。我建议统一用CycloneDX，它在漏洞匹配和工具生态上更成熟。
举个例子，消费SBOM做漏洞扫描的流程：
# 用Syft生成SBOM
syft my-image:latest -o cyclonedx-json > sbom.json
# 用Grype扫描漏洞
grype sbom:sbom.json
# 输出结果
NAME INSTALLED FIXED-IN VULNERABILITY
openssl 1.1.1t 1.1.1u CVE-2023-3817
log4j-core 2.17.0 2.17.1 CVE-2021-448324.5 归档：给SBOM一个「终点站」
归档不是把SBOM扔进垃圾桶。恰恰相反，归档是为了将来能查得到。
归档的核心要求：
- 不可篡改——用哈希链、区块链、或者简单的签名来保证
- 可检索——按制品名、版本、时间、漏洞ID都能查到
- 长期保存——至少覆盖软件的生命周期，我建议保留5年以上
我的做法：把SBOM归档到对象存储（比如S3或MinIO），按「项目/制品名/版本/sbom.json」的路径组织。同时维护一个索引数据库，记录每个SBOM的元数据。这样不管是审计还是应急响应，都能在几分钟内找到需要的SBOM。
归档的生命周期管理，我建议这样规划：
| 阶段 | 存储位置 | 保留策略 | 访问频率 |
|---|---|---|---|
| 活跃期 | CI/CD产物仓库 | 保留所有版本 | 高 |
| 冷存储期 | 对象存储（低频） | 保留所有版本 | 低 |
| 归档期 | 对象存储（归档） | 保留最后3个版本 | 极少 |
| 销毁期 | — | 超过保留期限后删除 | — |
⚠️ 注意：别等到出事了才去找SBOM。我见过一个案例，某公司被审计要求提供三年前的SBOM，结果发现当时的归档系统已经迁移过两次，数据全丢了。最后被罚了款。归档不是「存了就行」，要定期验证归档数据的可读性。
好了，SBOM的五个生命周期环节都讲完了。从创建到归档，每个环节都有坑，但也都有成熟的应对方案。记住一句话：自动化、可追溯、可验证——做到这三点，SBOM管理就成功了一大半。