在容器化部署已成为事实标准的当下，如何确保生产环境中的镜像与构建源码完全一致、且能够被独立验证，成为供应链安全的关键命题。可复现构建（Reproducible Build）解决了「用相同源码能否产出相同产物」的问题，但仅有构建能力不足以支撑供应链安全 —— 必须配套完整的验证工作流，让每一次部署都能追溯到可验证的构建产物。本文聚焦构建之后的验证环节，以 Arch Linux 推出的 bit-for-bit 可复现 Docker 镜像为例，系统解析镜像哈希的自动化验证方案与 CI/CD 集成实践。
可验证镜像的核心逻辑
可复现 Docker 镜像的核心理念是：给定相同的源代码、Dockerfile 构建指令与依赖版本，两次独立构建应当产出字节级一致的镜像。这一特性为供应链安全提供了最直接的验证依据 —— 如果无法通过独立重建复现出相同的镜像哈希，则说明构建过程中存在不可控因素，镜像的可信度应当被质疑。
Arch Linux 项目在 2024 年底宣布其官方 Docker 镜像实现 bit-for-bit 可复现性，其验证方法具备典型参考价值。项目方使用两种方式确认可复现性：第一种是镜像摘要（digest）比对 —— 在完全一致的环境中用相同源码构建两次，生成的镜像摘要应当完全相同；第二种是使用 diffoci 工具对两个镜像进行逐层对比，确认无任何字节差异。diffoci 是专门为可复现容器镜像设计的对比工具，能够解析 OCI 镜像格式并输出详细的差异报告，已被纳入 Arch Linux 官方仓库的 extra 分类。
自动化验证工作流的工程实现
将镜像哈希验证嵌入正式环境，需要设计一套可重复执行的自动化流程。完整的工作流包含四个核心步骤：构建、导出、比对、判定。
第一步是标准化构建。验证流程必须使用与发布流程完全一致的构建上下文，包括相同的 Dockerfile、相同版本的构建工具（如 BuildKit）、固定的依赖版本锁定文件。基础镜像必须使用摘要（digest）而非标签（tag）进行固定，防止因基础镜像更新导致构建结果不可复现。这一原则在供应链安全实践中被称为「不可变基础镜像引用」—— 只有 digest 级别的引用才能确保构建环境的确定性。
第二步是镜像导出与哈希计算。构建完成后，需要以确定性格式导出镜像以供后续比对。推荐的做法是将镜像导出为 OCI 镜像 tar 包或 Docker save 格式，然后计算整个 tar 包的 SHA-256 哈希值。另一种更轻量的方案是直接比较镜像的 manifest digest—— 这是 OCI 镜像规范中定义的全局唯一标识符，等同于镜像的「指纹」。对于追求更高灵活性的场景，可以在构建时输出 image config 的 SHA-256 作为校验依据，该值不依赖于传输格式，更适合跨环境比对。
第三步是独立重建与比对。验证工作流应当从相同的源码 commit 出发，在隔离的构建环境中执行第二次构建。两次构建产出的镜像摘要进行字节级比对：若完全一致，则说明构建过程具备可复现性，镜像可通过验证；若不一致，则需要介入排查，可能是依赖版本浮动、构建时间戳未消除或网络资源动态拉取等原因导致。
第四步是自动化判定与 gate。在 CI/CD 流水线中将哈希比对结果作为质量门禁（quality gate），比对通过才允许进入下一阶段。对于需要存档或审计的场景，还应当在通过验证后将镜像的 digest、构建元数据（构建时间、commit SHA、构建者标识）写入可信存储，并生成对应的软件物料清单（SBOM）供下游系统查询。
CI/CD 流水线集成要点
将镜像哈希验证集成到 CI/CD 流水线，需要在发布流程中插入一个独立的验证阶段。以 GitHub Actions 为例，一个典型的流水线设计包含以下阶段：源码检出、依赖锁定、镜像构建、镜像导出、哈希计算、验证 job、发布。
在验证 job 中，流水线会拉取已发布的镜像（或使用前序 step 产出的镜像），用相同的源码重新构建一次，然后执行比对脚本。比对脚本的退出码决定流水线成败：摘要一致则退出码为 0，继续执行发布步骤；不一致则退出码非零，流水线终止并报告差异。
对于追求更高级别安全保障的团队，可以引入可验证构建声明（Attestation）。基于 SLSA 框架或 OpenSSF 标准，构建系统可以在完成验证后生成一条加密签名声明，声明中包含镜像 digest、源码 commit、构建时间戳、验证结果等信息。该声明随镜像一同存储或分发，下游系统在拉取镜像时可以同步验证声明的有效性，从而构建起完整的信任链。
供应链可审计性的实践参数
将上述工作流落实到生产环境，需要关注以下几个关键参数的配置。
构建环境的隔离程度直接影响验证的可信度。建议使用专用的构建 runner，每次构建前重置或使用一次性容器环境，避免前一构建的缓存或残留文件污染验证结果。构建工具链的版本必须锁定 —— 无论是 Docker 版本、BuildKit 版本还是系统层面的工具，都应在配置文件中声明明确版本号，并在验证环境中保持一致。
依赖版本的锁定是实现可复现性的前提。对于语言级别的依赖，使用 lock 文件（如 Pipfile.lock、package-lock.json、go.sum）锁定所有传递依赖的精确版本；对于系统包，使用固定版本的 base image 并在 Dockerfile 中显式声明所有 apt/dnf/pacman 包的版本。Arch Linux 的做法是移除镜像中的 pacman 密钥环，这一细节看似奇怪，实则是为了消除构建过程中的随机元素 —— 密钥环生成包含熵源，会导致每次构建的镜像产生微小差异。
验证阈值的选择需要权衡安全性与可用性。严格模式下要求两次构建的完整 digest 完全一致，这提供了最高级别的安全保障；宽松一些的做法可以是只要求关键层的摘要一致，容许构建元数据层（如历史记录、标签）存在差异。对于大多数供应链场景，推荐采用前者 —— 只有在镜像内容层面的完全一致才能真正支撑可审计性。
资料来源
本文技术细节参考 Arch Linux 官方 Docker 镜像可复现性实践与 diffoci 工具文档。
- Arch Linux 可复现 Docker 镜像公告：https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/44PW52T547MACXFU5HZ5U7SIPAX3BAXS/
diffoci工具 GitHub 仓库：https://github.com/reproducible-containers/diffoci