HashiCorp 发布 Packer v1.16.0，新增原生支持：为该工具构建的每个镜像生成、签名和验证 SLSA 来源证明。该版本为团队提供了安全、防篡改的机器镜像构建记录，且无需使用额外的供应链工具。这填补了此前 SLSA 类证明机制基本未曾覆盖到的基础设施领域空白。
该版本所要解决的问题很明确，也很重要。机器镜像支撑着其上运行的所有工作负载。如果镜像被篡改或无法验证，那么从该镜像创建出的所有实例都会在不知情的情况下受到影响。在该版本发布之前，要定位镜像的来源只能通过翻查过时的构建日志。Packer 无法说明是哪个提交、哪个流水线或哪个身份创建了某个特定的构件。
本次主要新增功能是一个新的来源证明后置处理器。它会生成带有 SLSA Provenance v1 断言的 in-toto 声明。该格式与厂商无关，可兼容当前各类软件供应链安全工具。证明凭证会记录 Git 提交记录、代码仓库、引用分支、触发构建的 CI 流水线以及构建时间戳。本地构建会绑定其 SHA-256 摘要；没有本地文件的云构建则会关联一条标准身份记录，其中包含构建器 ID 和构建 ID。Packer 提供四种签名模式，以满足不同的密钥管理需求：可输出未签名 JSON 供内部使用；支持本地 PEM 密钥，适用于隔离环境；集中式密钥管理场景可使用云 KMS 或 Vault；Sigstore Fulcio 支持在 CI 流水线中实现无密钥签名，并可将凭证上传至 Rekor，实现可审计透明化。
Packer 可将其输出直接映射到 SLSA 的构建级别。构建 L1 只需要来源证明后置处理器，签名是可选的。在 CI 平台上运行 Packer 并采用无密钥签名即可达到 L2。此时，CI 作业的 OIDC 身份即作为签名者。此外，上传到 Rekor 可提供用于审计的透明日志。HashiCorp 为此提供了一个参考 GitHub Actions 工作流。L3 模式会将证明生成与构建作业完全分离。它使用基于 slsa-framework/slsa-github-generator 的签名作业。不过，HashiCorp 指出，仅凭该工作流并不能确保完全符合 L3。合规性还取决于平台加固和构建隔离控制。该工作流只是展示了这些实践，但并不能保证其实现。
HashiCorp 将该命令定位为部署门禁工具，用于将 CVE 与提交和运行中的实例关联起来。它还可作为 SOC 2 或 FedRAMP 审计的支持性证据，而非证明。
该版本还包含一些较小的 HCL2 改进。它新增了 continue_on_error 元参数，用于非致命配置器，还支持在对象类型变量的单属性默认值中使用 optional()。此外，还新增了模板函数：rfc3339_parse() 和 unix_timestamp_parse()，用于处理时间戳。
所有新功能均为可选，现有 Packer 模板无需任何更改即可在 v1.16.0 版本中进行构建。想要使用来源证明的团队只需在其现有构建块中添加来源证明后处理器即可。如果他们选择 L2 或兼容 L3 的模式，需要接入 GitHub Actions 工作流。HashiCorp 在 Packer 代码仓库的 examples/ci 目录下提供了这些工作流文件。
Packer 的方案建立在容器层已被验证的模式之上。它使用了 in-toto 声明、SLSA 来源断言、无密钥 Sigstore 签名和 Rekor 透明日志。这些元素此前在机器镜像层一直缺失，如今已被有效纳入。Packer 增强了针对 AMI、QCOW2 和 VHD 构件的工具链，并未引入新的加密技术。它让 Docker 的 buildx 和 GitHub 的构件证明更易于使用。其严格的签名和验证流程是相同的。团队不再需要创建自己复杂的流水线。
这一区别在与 AWS 现有产品进行对比时尤为重要，AWS 的相关产品解决的是相近但并不相同的问题。AMI 水印可跟踪身份和谱系元数据，但它们并不能提供加密级的构建来源证明。基于 NitroTPM 的证明能够表明运行中的实例在启动时与参考度量值匹配，但不能说明镜像最初是如何或在何处构建的。使用 AWS 原生工具进行 AMI 治理的团队应考虑添加 Packer 的来源证明。两者用途不同，不能相互替代。SLSA 构建级保证和启动时完整性检查分别解决了部署流程中的关键环节。追求 FedRAMP 或 SOC 2 证据的组织很可能两者都需要。
查看英文原文：https://www.infoq.com/news/2026/09/hashicorp-packer-verification/