HashiCorp has released Packer v1.16.0, adding native support for generating, signing, and verifying SLSA provenance attestations for every image the tool builds. The release provides teams with a secure, tamper-proof record of how a machine image was made. It does this without needing extra supply-chain tools. This addresses an infrastructure gap that SLSA-style attestation has mostly overlooked until now.
The issue with the release targets is clear but important. Machine images support every workload running on them. If an image is tampered with or cannot be verified, it can quietly spread to every instance created from it. Before this release, locating the source of an image required sifting through outdated build logs. Packer didn’t have a way to show which commit, pipeline, or identity created a specific artifact.
The main addition is a new provenance post-processor. It creates in-toto statements with an SLSA Provenance v1 predicate. This format is vendor-neutral and works with current supply-chain security tools. Attestations capture the Git commit, repository, ref, triggering CI pipeline, and build timestamps. Local artifacts are bound to their SHA-256 digest, while cloud artifacts without local files are tied to a canonical identity record containing the builder and artifact IDs. Packer offers four signing modes for various key management needs. It gives unsigned JSON output for internal use. It offers local PEM keys for isolated setups. For centralized key management, you can use cloud KMS or Vault. Sigstore Fulcio allows keyless signing in CI pipelines and can upload to Rekor for transparency.
Packer maps its output directly onto SLSA's build-level ladder. Building L1 requires only the provenance post-processor with signing optional. L2 is achieved by running Packer on a CI platform with keyless signing. Here, the CI job's OIDC identity serves as the signer. Furthermore, Rekor upload provides a transparent log for auditing. HashiCorp offers a reference GitHub Actions workflow for this setup. An L3-compatible pattern completely separates provenance generation from the build job. It uses a different signing job based on slsa-framework/slsa-github-generator. However, HashiCorp notes that this workflow alone does not ensure full L3 compliance. Compliance also depends on platform hardening and build isolation controls. The workflow shows these practices but does not guarantee them.
HashiCorp positions this command for deployment gating and for correlating CVEs with commits and running instances. It also serves as supporting evidence, not proof, for SOC 2 or FedRAMP audits.
The release includes smaller HCL2 improvements. It adds a continue_on_error meta-argument for non-fatal provisioners. It also supports optional() in per-attribute defaults for object-type variables. Plus, there are new template functions: rfc3339_parse() and unix_timestamp_parse() for handling timestamps.
All new functionality is opt-in, and existing Packer templates require no changes to build under v1.16.0. Teams wanting provenance can simply add the provenance post-processor to their existing build block. If they choose L2 or L3-compatible patterns, they must also wire in the reference GitHub Actions workflows. These are provided by HashiCorp in the examples/ci directory of the Packer repository.
Packer's approach builds on a proven method from the container layer. It uses in-toto statements, SLSA Provenance predicates, keyless Sigstore signing, and Rekor transparency logs. These elements were missing in the machine-image layer, and now they’re effectively included. Packer enhances the toolchain for AMIs, QCOW2, and VHD artifacts. It doesn't introduce new cryptography. It makes Docker's buildx and GitHub's artifact attestations easy to access. The rigorous signing and verification process is the same. Teams no longer need to create their own complex pipelines.
That distinction matters most against AWS's existing offerings, which solve adjacent but different problems. AMI Watermarks track identity and lineage metadata. However, they don’t guarantee cryptographic build-provenance. NitroTPM-based attestation shows that a running instance matches a reference measurement at boot. It doesn’t explain how or where the image was originally built. Teams using AWS-native tools for AMI governance should consider adding Packer's provenance attestations. Both serve different purposes, so they aren't substitutes. SLSA build-level guarantees and boot-time integrity checks tackle key parts of the deployment process. Organizations pursuing FedRAMP or SOC 2 evidence will likely need both.