SBOM在离线交付中的证据价值

离线交付最容易出现的一种情况是：大家盯着“装上了没有、跑起来没有”，至于包里到底塞了哪些组件，往往等到出事才有人想起来追问。SBOM 就是提前回答这个问题的清单，类似装箱单，只不过列的是软件成分。

它在隔离网络里的分量比联网环境重得多。联网时，出了疑问还能现场查、临时拉一份比对；进了气隙环境，没人能替你到外面盘点。Zarf 1.0 把镜像、清单、依赖和 SBOM 一起打进可迁移的制品，思路就是让这份成分表跟着包走，而不是留在构建侧的某台机器上。但有个细节容易被忽略：部署流程会把 SBOM 文件保存到当前目录。如果恰好在一个临时目录里执行，清理时它就会和临时文件一起消失。这不是工具的问题，是操作习惯的问题。

需要说清楚的是，SBOM 本身证明不了“干净”。它只能证明“这份清单里写了哪些东西”，写漏了、写旧了、被人改过，单看 SBOM 是看不出来的。所以它必须和另外两样东西绑在一起：签名说明这份清单在签完之后没被动过，校验和说明传到隔离侧的还是原件。三样对上，才算一条能拿出手的证据链；只交一份 SBOM 出去，本质上还是“我说什么你信什么”。

这也解释了为什么部署时的验证策略要写死。Zarf 的验证参数有三种取值，默认是“有签名材料就验、没有就继续”。在离线侧，信任根没配好、公钥没带进去，这个默认值就可能让部署一路推进下去。对受控交付来说，这不是灵活，是漏洞。另一个同样需要留痕的地方是 init 包：官方公告里提到，给 init 包签名仍属于后续推进的事项，那么采用时就不该默认它天然可验证，来源、哈希和人工复核的记录最好一并进档案。

换个角度看，SBOM 的价值不在部署那一刻，而在半年后有人问“当时那台机器上装的到底是什么版本”时，你能拿出东西来。既然这样，就别把它当成部署过程的副产物。固定一个证据目录，把包文件、哈希、签名、SBOM、构建记录放在一起，和包本身同样对待。工具负责搬运和校验，能不能把这份清单变成证据，还是取决于人有没有认真归档。