构建可验证的软件物料清单:签名、时间戳与可追溯性
为什么清单也需要验证
如果攻击者能篡改构建产物,同样可能篡改描述产物的清单。一份未经签名、无法验证来源的SBOM,在事件调查和合规审计中很难作为有效证据。要让它具备可信度,需要解决三个问题:是谁生成的、内容是否被改动、生成时间是否可信。
签名机制
推荐采用基于公私钥的分离式签名。生成方用私钥对清单内容签名,消费方用公钥验证。私钥应保存在受控环境或硬件模块中,不进入代码仓库。签名对象应是内容的规范化表示,避免因序列化顺序差异导致验证失败。对于需要多级供应的场景,可以引入见证机制,由多方对同一制品的清单进行签署,提高伪造难度。
时间戳与不可否认
单纯的签名无法证明清单是在某个具体时间之前生成的。引入可信时间戳服务可以让生成时间具备可验证性,这在事后追责和合规举证中很有价值。时间戳应与签名一起归档,形成完整的证据链。
可追溯性建设
可追溯性意味着从运行中的制品能够反查到构建任务、代码提交、依赖清单和参与人员。实现方式是在构建时把来源信息写入制品元数据,在部署时记录制品标识,在运行时保持制品与实例的映射关系。这样在出现漏洞或事件时,可以从任意一端出发快速定位影响面。
落地的现实考虑
完整实现上述能力需要改造流水线和部署流程,建议分阶段推进:先做到清单归档和版本对应,再实现签名校验,最后补齐时间戳与来源追溯。每一步都能独立产生价值。
结语
可验证性是供应链安全从形式走向实质的分界线。只有当清单可以被独立验证,它才真正具备约束力和证据价值。