气隙环境如何设计可审计的信任根?

气隙环境里最容易被低估的失败模式，不是没有签名，而是签名验证在隔离侧被静默降级。联网侧一切正常，制品进入隔离网络后却因为缺少 TrustedRoot、缺少证书身份条件、缺少透明日志的可达路径，验证要么被跳过，要么回落到宽松的默认值。部署照样成功，审计链却在这里断掉。因此“可审计的信任根”首先不是密钥管理问题，而是验证策略能否在断网条件下被完整复现的问题。

信任根必须作为制品的一部分被带进去

公钥或 Sigstore TrustedRoot、证书身份与 OIDC issuer 的匹配条件、时间戳策略、透明日志的处置方式，这些都不该被当作隔离侧的环境配置，而应视为交付物本身。它们需要版本号、来源记录和归档位置，与包文件处于同一证据目录。原因很直接：如果信任根是“现场配的”，那么半年后没有人能证明当时验证用的到底是哪一份根、哪一套身份策略。可审计性的前提是可复现，而可复现的前提是材料齐全且被固定下来。

把验证从可选改成必经

Zarf 的 --verify 默认值是 if-possible，有签名材料才验证，没有则可能继续。这个默认值在联网环境里问题不大，在气隙环境里却恰恰是最危险的一档：签名材料缺失、信任根未配置，都会让部署在“看起来正常”的状态下推进。生产流程应明确使用 --verify=always，并把“验证失败即中止并隔离制品”写成规则，而不是留给执行人临场判断。

离线场景还有一个常被误读的地方：气隙下默认跳过 Rekor 透明日志，并不意味着签名可以省略，而是说明离线验证需要另一套可审计安排。时间戳数据是否随包保留、跳过透明日志的理由是否记录、发布侧与隔离侧是否使用同一套信任策略，这些才是审计时真正被追问的内容。同理，证书问题应通过修复 CA 和信任链解决，--insecure-skip-tls-verify 不应出现在常规脚本里。

证据链的完整性比单点验证更重要

值得注意的是信任根自身的起点。Zarf 2026 路线图仍将“签名 init 包”和 keyless 签名支持列为推进项，这意味着就目前而言，初始化组件的来源完整性不能默认为已解决，人工复核记录、哈希和获取渠道都应进入交付证据。SBOM 默认写入执行部署时的当前目录，若在临时目录操作，很容易随清理丢失，固定证据目录是低成本的必要动作。

判断一套气隙信任根是否真的可审计，可以用一个简单标准：第三方拿着归档的包、哈希、签名、信任根版本、SBOM 和失败日志，能否在不接触原始环境的情况下重放出同样的验证结论。能做到，信任根才是工程资产；做不到，它只是一次当时通过的部署。