HashiCorp gives machine images proof of origin

A compromised machine image runs in every instance launched from it. HashiCorp has released Packer 1.16 with provenance based on the SLSA supply chain standard: the build can generate and sign an attestation, then verify it with one command. Proof requires enabling the post-processor and someone verifying it before launch.

Key takeaways

Related:OpenTofu vs. Terraform: which IaC tool really delivers  /  Hugging Face hacked: a dataset loader was the entry point

What is Packer 1.16? The HashiCorp version that natively generates, signs and verifies SLSA provenance for machine images during builds. Without the post-processor and verification before launch, the attestation remains a file alongside the Amazon Machine Image (AMI).

The golden image is considered safe until someone checks its origin

Golden images are trusted, although few people check their origin. The pipeline has built the image, it sits in the registry, and instances launch from it. If a vulnerability emerges later or a build looks suspicious, the search begins in logs that are often already gone. HashiCorp writes that, until this version, reconstructing a machine image’s provenance required searching archives.

The gap is structural. The SLSA framework, Supply-chain Levels for Software Artifacts, defines graduated guarantees about how artifacts are created. Its tools were developed for packages and containers. Machine images, including AMIs, VHD, QCOW2 and comparable cloud artifacts, fell outside their scope. Yet every workload starts there. A tampered image silently infects every instance launched from it.

Packer was already where these images were built. What was missing was vendor-neutral, signed provenance readable by other supply chain tools. Version 1.16 adds it to the build. Protection depends on whether teams enable it and verify it before launch.

Packer records provenance as an in-toto statement

The new provenance post-processor supplements an existing build. After the run, Packer writes a signed JSON attestation to a directory such as attestations. It sits alongside the artifact, in S3, a registry or the team’s artifact store. The format is an in-toto statement, the attestation format used by supply chain tools, with an SLSA Provenance v1 predicate. Existing verification tools already consume this format for containers.

The statement records the origin: Git commit, repository and ref, CI pipeline and timestamps. For local artifacts, Packer binds the attestation to the file’s SHA-256 digest. For cloud artifacts without a local file, it creates a canonical identity record: always the builder ID and artifact ID, optionally registry state, such as an HCP Packer URI, if provided by the builder.

HashiCorp offers four attestation output modes, including an unsigned option. Unsigned (none) writes a JSON statement for an internal system already considered trusted. key uses a local PEM key, useful in air-gapped environments. kms accesses AWS KMS, Google Cloud KMS, Azure Key Vault or HashiCorp Vault through the respective URI. keyless uses Sigstore Fulcio and optionally the Rekor transparency log, intended for GitHub Actions without a long-lived key.

Existing templates require no changes. Packer 1.16 continues building what 1.15 built. Provenance is an addition someone writes into the HCL. The code has been on GitHub since 24 July 2026; the HashiCorp blog post of 13 August announced it. It also describes the four signing options and attestation format: an in-toto statement with an SLSA Provenance v1 predicate, keyless via Sigstore Fulcio with an optional Rekor entry, and kms for AWS KMS, Google Cloud KMS, Azure Key Vault and HashiCorp Vault.

L3 has no Packer switch

SLSA distinguishes build levels with increasing requirements. HashiCorp mentions three in connection with Packer. The tool itself reaches two; the third depends on the build platform.

Build L1 means provenance exists that identifies the artifact by digest and describes how it was created. Signing is optional at this level. signing_mode none provides documentation without protection against forgery. The statement must accompany the artifact; otherwise, L1 remains an internal file with no external effect.

Build L2 requires a hosted service that generates and signs the provenance. HashiCorp demonstrates this with a Packer workflow on GitHub Actions: keyless signing, OpenID Connect (OIDC) providing the job’s short-lived CI identity as signer, and upload to the public Rekor log. A reference workflow is available under examples/ci. HashiCorp states that this pattern meets L2 only if the hosted build platform and provenance generation controls meet SLSA L2 requirements. Packer alone does not confer that status.

HashiCorp explicitly calls the third example only L3-compatible. Here, the build job publishes only the digest. A separate signing job, sharing no process space with the build steps, issues the attestation. The example uses slsa-framework/slsa-github-generator. HashiCorp is clear: this does not establish L3 by itself. L3 requires a hardened platform and build isolation. Accordingly, the changelog for version 1.16.0 lists features for SLSA Build L1 and L2. A YAML file in the repository does not make Packer 1.16 SLSA Build L3; the level remains a property of the build platform.

Without verification before launch, the attestation goes unread

HashiCorp intends the new packer verify-attestation command for the deployment pipeline or preflight checks. If verification fails, the command exits with an error code, stopping deployment. HashiCorp specifies signing identity and artifact digest as minimum checks. L2 additionally requires Rekor and timestamps.

Packer 1.16 makes provenance verifiable once the post-processor runs and the verify command is placed before launch. Without this step, a JSON file remains alongside the AMI. Pipeline operators decide whether the command runs before launch. Packer does not enforce it.

Frequently asked questions

Image Source: AI-generated (September 2026)

Translated from the German original using artificial intelligence. The German version is authoritative.