HashiCorp's Packer 1.16 Adds Signed SLSA Provenance Attestations for Machine Images
Packer 1.16 adds a provenance post-processor and a verify-attestation command, letting teams cryptographically sign and check the origin of every machine image they build.
Editor's Note ·
- Correction:
- The article quotes HashiCorp as saying "machine images received less attention in supply-chain security workflows." The HashiCorp blog post actually states: "Machine images have received less attention than many supply-chain security workflows." The quoted sentence in the article is a paraphrase, not a verbatim quotation; the underlying point (that machine images have gotten comparatively less supply-chain-security attention than application packages and containers) is accurately represented.
Overview
HashiCorp has released Packer 1.16.0, adding native support for generating, signing, and verifying SLSA provenance attestations for the machine images the tool builds, according to HashiCorp’s announcement. The GitHub release notes date the version to July 24, 2026; HashiCorp’s blog post detailing the feature followed on August 13, 2026, under the byline of Tanmay Jain.
Packer is HashiCorp’s tool for building machine images — the VM or cloud-instance templates that many workloads are launched from — as code across multiple platforms. The new release targets a gap the company says has persisted in supply-chain security tooling: while SLSA (Supply-chain Levels for Software Artifacts) attestations have become common for application packages and containers, according to HashiCorp, “machine images received less attention in supply-chain security workflows.”
What We Know
The centerpiece of the release is a new provenance post-processor paired with a packer verify-attestation command. The GitHub release notes describe it as adding support for “SLSA Build L1/L2 supply-chain attestations,” stating the feature “derives in-toto subjects from Packer artifacts, builds SLSA Provenance v1 predicates with Git/CI metadata, and signs via local PEM key, cloud KMS (awskms://, gcpkms://, azurekms://, hashivault://), or keyless Sigstore (Fulcio + optional Rekor transparency log).” HashiCorp’s blog post frames the goal similarly: the release gives teams a cryptographic, tamper-evident record of each build without requiring separate provenance tooling.
According to HashiCorp, after a build finishes Packer writes a signed attestation to an attestations/ directory as a JSON file, which teams can then store in S3, a container registry, or an artifact store alongside the image itself. For images built locally, the attestation binds to the artifact’s SHA-256 digest; for cloud artifacts with no local file, Packer instead derives the attestation subject from a canonical identity record containing the builder ID and artifact ID.
The release supports four signing modes: “none” for unsigned JSON statements suited to initial adoption or internal systems, “key” for local PEM private keys in air-gapped environments, “kms” for cloud KMS or HashiCorp Vault in production workloads, and “keyless” for Sigstore Fulcio with an optional Rekor transparency-log upload, aimed at CI/CD pipelines, according to both HashiCorp and the GitHub changelog. The changelog specifies the KMS mode is addressed by URI scheme — awskms://, gcpkms://, azurekms://, or hashivault:// — letting Packer auto-detect the provider.
Those signing modes map to SLSA’s tiered build levels, per HashiCorp: Build L1 is satisfied by distributing signed provenance that identifies the artifact by digest; Build L2 requires a hosted CI service to generate and sign the provenance, which the keyless mode enables using the CI job’s own OIDC identity, with an optional Rekor transparency-log entry; and an L3-compatible pattern isolates provenance generation from the build itself through reference workflows for delegated signing.
The new packer verify-attestation command runs before deployment, according to HashiCorp, checking the signing identity, the artifact digest, and — optionally — Rekor and timestamp requirements; a non-zero exit code blocks the deployment on a failed check.
HashiCorp describes several intended use cases for the feature: deployment gates that block unsigned images originating from untrusted pipelines, correlating a security incident back to the specific commits that produced an affected image, generating compliance evidence for frameworks such as SOC 2 and FedRAMP, and detecting shadow builds by verifying that a golden image actually originated from an approved pipeline.
The release also ships several smaller changes documented in the GitHub release notes: a continue_on_error meta-argument for provisioner blocks that logs a provisioner failure and lets the build continue rather than halting; optional() attribute modifiers for HCL2 object-type variables, letting per-attribute defaults be declared without updating every caller; and two new template functions, rfc3339_parse and unix_timestamp_parse, for parsing timestamps into image names without shell scripting. The changelog also credits a fix for a path-traversal vulnerability in the plugin getter’s GitHub filename handling, added FreeBSD arm build support, and a security-motivated dependency upgrade replacing x/crypto/openpgp by bumping go-github from v33 to v75.
What We Don’t Know
HashiCorp’s announcement and the GitHub changelog do not disclose adoption figures, name any customers already using the provenance post-processor in production, or specify a timeline for extending signed attestations to earlier Packer releases. Independent third-party coverage or analysis of the release was not available at publication time.
Why It Matters
SLSA-style provenance has already become a common expectation for container images and application packages; extending the same signed, verifiable build record to machine images closes a gap HashiCorp says has left VM and cloud-instance templates more exposed in supply-chain-security workflows than the software packages they host.