# Packer v1.16.0 Brings Native SLSA Provenance to Machine Images

- Link: https://thestackobserver.com/packer-v1-16-0-brings-native-slsa-provenance-to-machine-images/
- Published: 2026-08-14T08:10:14-04:00
- Author: Stackxx

Supply chain security has become a non-negotiable requirement for platform engineering
teams, but most tooling in this space has focused on application packages and containers.
Machine images—the actual foundation that every workload runs on—have received far
less attention. A compromised or tampered image can silently propagate to every 
instance launched from it, yet tracking down the origin of a problem often means
digging through build logs that may no longer exist.

With the release of **Packer v1.16.0**, HashiCorp is changing that. This version
introduces native support for generating, signing, and verifying [SLSA provenance attestations](https://slsa.dev/)
for every image Packer builds. No separate provenance tooling required. No post-
build scripts to maintain. Just a few lines of HCL added to an existing build, and
every artifact carries a cryptographic, tamper-evident record of its origin.

## Why Provenance Matters for Machine Images

The [SLSA framework](https://slsa.dev/) (Supply-chain Levels for Software Artifacts)
defines progressively stronger guarantees about how software artifacts are produced.
Until Packer v1.16.0, applying SLSA principles to machine images was largely manual
and fragmented. Teams would cobble together scripts to capture build metadata, sign
it with custom keys, and store it somewhere accessible—but rarely in a standardized
format that downstream tooling could consume.

A provenance attestation is a signed, machine-readable statement that records the
origin of an artifact. It captures the Git commit the build ran from, the repository
and ref it came from, the CI pipeline that triggered the build, and the timestamps
for when it ran. For local artifacts, the attestation is bound to the SHA-256 digest
of the artifact file. For cloud artifacts without local files, Packer derives the
attestation subject from a canonical identity record containing the builder ID and
artifact ID—and optionally includes the artifact’s registry state, such as an HCP
Packer registry URI.

Packer generates attestations as [in-toto](https://in-toto.io/) statements carrying
an SLSA Provenance v1 predicate. This is the vendor-neutral format that supply-chain
security tooling already knows how to consume and verify, which means the attestations
work with existing policy engines, artifact stores, and compliance workflows.

## The Provenance Post-Processor

Adding provenance to an existing build requires minimal changes. The new `provenance`
post-processor attaches to any Packer build and generates a signed attestation envelope
as a plain JSON file:

    ```wp-block-code
    build {
      source "amazon-ebs" "my-image" { ... }

      post-processor "provenance" {
        signing_mode         = "keyless"
        upload_tlog          = true
        keyless_identity     = var.keyless_identity
        keyless_oidc_issuer  = var.keyless_oidc_issuer
        output_dir           = "attestations/"
      }
    }
    ```

After the build completes, Packer writes the attestation to the specified output
directory. You can store it in S3, a container registry, an artifact store, or alongside
the artifact itself. The attestation captures the artifact name and its SHA-256 
digest for local files, or a digest of the canonical artifact identity for cloud
artifacts. It also records available Git and CI metadata, the builder identity, 
and build timestamps.

### Four Signing Modes

Packer ships with four signing options, allowing teams to adopt provenance without
overhauling their key management setup first:

 * **none** — Unsigned JSON statement. Best for getting started or storing in a 
   trusted internal system.
 * **key** — Local PEM private key. Ideal for air-gapped environments or teams with
   an existing PKI.
 * **kms** — Cloud KMS or HashiCorp Vault. Production workloads with centralized
   key management. The provider is selected automatically from the URI (AWS KMS,
   GCP Cloud KMS, Azure Key Vault, or HashiCorp Vault).
 * **keyless** — Sigstore Fulcio with optional Rekor transparency log. Perfect for
   GitHub Actions and CI pipelines with no long-lived keys to manage.

Each mode maps to a different SLSA build level, giving teams a clear ladder to climb
as their security requirements mature.

## SLSA Build Levels in Practice

SLSA defines a ladder of trust rather than a single pass/fail threshold. Here’s 
how Packer maps to each level:

### Build L1: Signed Provenance Exists

Add the `provenance` post-processor with `signing_mode = "none"` to generate a record
that identifies the artifact by digest and describes how it was produced. At L1,
signing is optional. The provenance must be distributed with the artifact, but no
cryptographic verification is required.

### Build L2: Hosted Service Generates and Signs Provenance

Run Packer on GitHub Actions or another hosted CI platform and sign using `keyless`
mode. The CI job’s OIDC identity becomes the signer, eliminating static credentials.
Upload the attestation to the Rekor public transparency log for auditable evidence.
A ready-to-use reference workflow ships with Packer at `examples/ci/github-actions-
l2-keyless.yml`.

### Build L3-Compatible: Isolated Provenance Generation

The build job publishes only the artifact digest. A separate, isolated signing job
handles the attestation and never shares a process space with the build steps. The
reference workflow at `examples/ci/github-actions-l3-delegated.yml` uses [slsa-github-generator](https://github.com/slsa-framework/slsa-github-generator)
to demonstrate an L3-compatible delegated signing pattern. Full L3 also depends 
on hardened platform and build isolation controls.

## Verifying Attestations at Deployment Time

Provenance is only useful if it gets checked before an image is consumed. Packer
v1.16.0 introduces the `packer verify-attestation` command, designed to sit inside
deployment pipelines or pre-flight scripts:

    ```wp-block-code
    packer verify-attestation \
      -signing-mode        keyless \
      -keyless-oidc-issuer https://token.actions.githubusercontent.com \
      -keyless-identity    https://github.com/my-org/my-repo/.github/workflows/build.yml@refs/heads/main \
      -builder-id          https://github.com/my-org/my-repo \
      -source-uri          git+https://github.com/my-org/my-repo \
      -require-rekor \
      -require-timestamp \
      -bundle attestations/my-image.qcow2.provenance.sigstore.json \
      -artifact my-image.qcow2 \
      attestations/my-image.qcow2.provenance.json
    ```

If any check fails, the command exits non-zero and the deployment is blocked. Teams
can enforce as much or as little as their environment warrants:

 * **Deployment gates:** Block any image that cannot produce a valid signed attestation
   from your trusted CI pipeline.
 * **Incident response:** When a CVE drops, correlate the affected commit with images
   built from it and identify exactly which instances need remediation.
 * **Compliance audits:** Provide auditors with cryptographic proof that every production
   image came from a specific pipeline, commit, and identity.

## Packer’s Provenance vs. Container-Focused Alternatives

Container-focused tools like Cosign and Syft have done excellent work making container
provenance accessible, but machine images present different challenges. AMIs, Azure
VHDs, VMware templates, and QEMU images are often harder to introspect than a container
layer. They may carry kernel configurations, firmware, and init systems that containers
simply don’t have. Packer’s native provenance generation treats the entire image
as a single artifact, binding the attestation to the image’s digest regardless of
the underlying builder. This means a single verification workflow works across AWS,
Azure, VMware, and local builders—no per-platform scripts required.

## HCL2 Quality-of-Life Improvements

Beyond provenance, v1.16.0 includes HCL2 improvements that make day-to-day template
authoring smoother. While smaller in scope, these changes reduce friction for teams
already investing heavily in Packer as part of their image factory.

## What This Means for Platform Teams

For platform engineering teams running image factories at scale, Packer v1.16.0 
removes a significant gap in supply chain coverage. Machine images are often the
blind spot in an otherwise mature SBOM and attestation pipeline. Now they can be
treated with the same rigor as container images and language packages.

The practical impact is threefold:

 1. **Reduced operational burden:** No custom scripts to maintain for capturing build
    metadata or signing attestations.
 2. **Standardized verification:** Downstream consumers can verify image provenance
    with the same tools they already use for other artifacts.
 3. **Gradual adoption:** Start with `signing_mode = "none"` and incrementally increase
    assurance as your organization matures.

## Bottom Line

Machine image provenance has been an underserved area in supply chain security. 
Packer v1.16.0 changes the game by making SLSA attestation a native, first-class
part of the build process. For teams already using Packer for golden image pipelines,
this is a near-zero-friction upgrade that closes a meaningful security gap. For 
teams building new image factories, it removes one more reason to postpone provenance
adoption.

The attestation format is standard. The signing options are flexible. The verification
command is purpose-built for CI/CD pipelines. And it all ships in a single post-
processor that requires no external tooling. If you’re running infrastructure that
depends on machine images, this is the kind of upgrade that makes your security 
team happy without making your build engineers miserable.

## Sources

 * [HashiCorp Blog – Packer v1.16.0 Brings Verifiable Provenance to Machine Images](https://www.hashicorp.com/blog/packer-v1160-brings-verifiable-provenance-to-machine-images)
 * [SLSA Framework Official Site](https://slsa.dev/)
 * [in-toto Project](https://in-toto.io/)