4、SBOM的版本管理与生命周期

SBOM 不是一份静态的 PDF 文档。它跟软件一样，有自己的版本号、更新节奏和废弃规则。说白了，SBOM 是活的。

我见过不少团队，花大力气生成了一份 SBOM，然后就丢在文件夹里吃灰。等到产品出安全漏洞了，回头一看，SBOM 里的组件版本跟实际跑的根本对不上。嗯，这就是没管好版本。

这一章，我们就把 SBOM 的版本管理讲透。包括版本号怎么定、跟软件版本怎么对齐、什么时候该更新、什么时候该废弃。

4.1 SBOM 版本号策略

SBOM 版本号不是随便写的。我个人习惯，直接复用语义化版本号（SemVer）的规则：主版本.次版本.补丁。

举个例子：

软件版本：v2.1.0
SBOM 版本：v2.1.0-sbom.1  （首次生成）
SBOM 版本：v2.1.0-sbom.2  （发现漏了一个组件，补上）
SBOM 版本：v2.1.0-sbom.3  （修正了某个许可证字段）

为什么要这么搞？因为软件版本没变，但 SBOM 可能因为审计要求需要反复修正。你总不能为了改个 SBOM 字段就发个软件新版本吧？

4.2 SBOM 版本与软件版本的关系

这里有个容易踩的坑：很多人以为 SBOM 版本必须跟软件版本完全一致。其实不是。

它们的关系，我总结成三种模式：

1. 一对一模式：每个软件版本对应一份 SBOM。简单直接，适合小项目。
2. 一对多模式：一个软件版本对应多份 SBOM（比如不同构建环境、不同架构）。
3. 多对一模式：多个软件版本共享一份 SBOM（比如补丁版本只改了配置文件，没动依赖）。

我在项目中遇到过最头疼的情况，是「一对多」模式。同一个软件版本，在 x86 和 ARM 上编译，依赖的库版本可能不一样。这时候如果只生成一份 SBOM，那肯定对不上。

正确的做法是：

myapp-v2.1.0-x86_64.spdx.json
myapp-v2.1.0-arm64.spdx.json
myapp-v2.1.0-riscv64.spdx.json

文件名里带上架构信息，一目了然。

4.3 SBOM 的更新机制

SBOM 什么时候该更新？我列了一个清单，你可以直接拿去用：

• 依赖变更：新增、删除、升级、降级任何第三方组件
• 漏洞修复：某个组件打了安全补丁，版本号变了
• 许可证变更：某个组件的许可证从 MIT 改成了 GPL
• 构建环境变化：编译器版本、基础镜像版本变了
• 元数据修正：发现之前的 SBOM 里有错误字段

更新流程我建议走 CI/CD 自动化。每次构建都重新生成 SBOM，然后跟上一版做 diff。如果 diff 不为空，就自动发布新版本。

我曾经见过一个团队，手动更新 SBOM，结果漏掉了三个关键依赖。后来安全审计时被客户当场问住，场面非常尴尬。从那以后，我坚持所有 SBOM 必须由流水线自动生成，人只负责审核，不负责录入。

4.4 SBOM 的废弃机制

SBOM 不是永生的。过期的 SBOM 如果不废弃，会带来两个问题：

• 安全扫描工具可能还在用旧的 SBOM 做比对，产生误报
• 审计人员分不清哪份是当前有效的 SBOM

废弃条件我建议这样定：

废弃不是删除。我建议在 SBOM 的元数据里加一个 status 字段：

{
  "status": "deprecated",
  "deprecatedDate": "2025-03-15",
  "supersededBy": "myapp-v2.1.0-sbom.4"
}

这样既保留了历史记录，又明确了当前状态。审计的时候，直接查 status 字段就能知道哪份是活的。

4.5 生命周期全景图

把上面这些串起来，SBOM 的完整生命周期是这样的：

从图上你能看到，SBOM 不是一条直线走到头。更新之后会回到版本号分配阶段，形成循环。只有确定不再需要了，才进入废弃和归档。