Packer v1.16.0 Brings Native SLSA Provenance to Machine Images

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 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 (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 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:

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 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:

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
• SLSA Framework Official Site
• in-toto Project