Packer 1.16 arrives with native SLSA provenance generation and verification

HashiCorp released Packer v1.16.0 with native support for generating, signing, and verifying provenance attestations under the SLSA standard for every image the tool builds. In practice, Packer now produces a tamper-proof record of how a machine image was made, without requiring additional supply chain tools bolted onto the pipeline.

The problem this solves is familiar to any team operating a cloud fleet: a machine image underpins every workload that runs on top of it. If an image is tampered with, or simply cannot be verified, the problem silently propagates to every instance created from it. Before this release, tracing an image's origin meant digging through old build logs, and Packer had no way to point to which commit, pipeline, or identity produced a given artifact.

The provenance post-processor

The core of the new feature is a new provenance post-processor. It generates in-toto statements with an SLSA Provenance v1 predicate, a vendor-neutral format that already integrates with existing supply chain security tools. The attestation captures the Git commit, the repository, the ref, the CI pipeline that triggered the build, and build timestamps.

How it binds to the artifact varies by type:

• Local artifacts are linked to their SHA-256 digest.
• Cloud artifacts with no local file (an AMI, for instance) are tied to a canonical identity record containing the builder and artifact IDs.

For signing, Packer offers four modes, covering different key management needs:

| Mode | Recommended use | |---|---| | Unsigned JSON | internal use, no cryptographic verification | | Local PEM keys | isolated environments | | Cloud KMS or Vault | centralized key management | | Sigstore Fulcio (keyless) | CI pipelines, with optional upload to Rekor for transparency |

How Packer maps to SLSA levels

Packer's output fits directly into SLSA's build levels scale:

• L1 requires only the provenance post-processor, with optional signing.
• L2 is reached by running Packer on a CI platform with keyless signing, using the CI job's OIDC identity as the signer. Uploading to Rekor provides the transparency log for auditing. HashiCorp provides a reference GitHub Actions workflow for this scenario.
• L3-compatible fully separates provenance generation from the build job, using a distinct signing job based on slsa-framework/slsa-github-generator.

An important point that HashiCorp makes a point of noting: the workflow alone does not guarantee full L3 compliance. Compliance also depends on platform hardening and build isolation controls. The workflow demonstrates these practices but does not guarantee them, which is an honest heads-up for anyone about to promise this internally during an audit.

The reference workflows for the L2 and L3-compatible standards live in the examples/ci directory of the Packer repository.

Nothing new in cryptography

It's worth understanding what Packer is not inventing. The approach reuses a method already established at the container layer: in-toto statements, SLSA Provenance predicates, keyless signing via Sigstore, and transparency logs on Rekor. These elements existed for container images, via Docker's buildx and GitHub's artifact attestations, but were missing at the machine image layer. Packer brings the same rigorous signing and verification process to AMI, QCOW2, and VHD artifacts, without introducing any cryptography of its own.

HashiCorp positions the feature for three concrete uses: deployment gating, correlating CVEs with commits and running instances, and as supporting evidence (not proof) for SOC 2 or FedRAMP audits.

Where this differs from AWS's native tools

For those already using native AWS tooling for AMI governance, the distinction matters, because those tools solve adjacent but different problems:

• AMI Watermarks track identity and lineage metadata, but do not guarantee cryptographic build provenance.
• NitroTPM-based attestation proves that a running instance matches a reference measurement at boot, but does not explain how or where the image was originally built.

These are complementary layers: SLSA's build-level guarantees and boot-time integrity checks cover distinct parts of the deployment process. Organizations targeting evidence for FedRAMP or SOC 2 will likely need both, not just one or the other.

Minor HCL2 improvements

The release also brings HCL2 tweaks relevant to anyone writing templates:

• continue_on_error meta-argument for non-fatal provisioners;
• support for optional() with per-attribute defaults for object-type variables;
• new template functions rfc3339_parse() and unix_timestamp_parse() for handling timestamps.

What changes for those building pipelines in Brazil

The good news for those who already have Packer in production: everything is opt-in. Existing templates continue to build under v1.16.0 with no changes required. Anyone wanting provenance just needs to add the provenance post-processor to the build block; those going further, toward the L2 or L3-compatible standards, also need to plug in the reference GitHub Actions workflows.

The practical benefit is lowering the barrier to adopting supply chain traceability in infrastructure, a topic that in Brazil tends to remain confined to teams with high DevSecOps maturity. With the process packaged into the build tool itself, there's no longer a need to assemble a homegrown signing and verification pipeline. For teams serving contracts with compliance requirements, or who simply want to be able to answer "which commit generated this AMI that's running in production?", the answer now comes signed and verifiable, not dug out of logs.

What remains open is the platform hardening effort that separates an L2 pipeline from a genuinely L3 one: the tool delivers the mechanism, but operational rigor remains the team's responsibility.