Skip to content

Packer v1.16.0 Adds SLSA Provenance Attestations for Machine Images

Packer v1.16.0 ships SLSA provenance generation and a verify-attestation command, giving infrastructure teams cryptographic build attestations for machine images.

Official Packer logomark in black on HashiCorp's Packer-blue gradient background
Credit: HashiCorp

HashiCorp shipped Packer v1.16.0 with native SLSA provenance generation and a companion verify-attestation command, bringing cryptographic build attestations to machine images. The release addresses a notable gap: SLSA tooling has concentrated on application packages and containers, leaving the underlying machine images those workloads run on largely outside established attestation workflows.

Machine images carry an asymmetric risk. A compromised or tampered image propagates silently to every instance launched from it, and tracing the source of a problem has historically depended on build logs that may no longer exist. The new provenance post-processor generates an in-toto statement with an SLSA Provenance v1 predicate for every build, capturing the source commit, CI pipeline, builder identity, and timestamps. For local artifacts, the attestation is bound to the SHA-256 digest of the image file. For cloud-hosted artifacts without a local file, Packer derives a canonical identity record from the builder ID and artifact ID, optionally extended with a registry reference such as an HCP Packer registry URI.

The Packer post-processor supports four signing modes so that teams can adopt provenance without restructuring existing key management practices. Unsigned JSON statements suit trusted internal systems; local PEM private keys fit air-gapped environments; cloud KMS integrations cover AWS, GCP, Azure Key Vault, and HashiCorp Vault; and keyless signing via Sigstore Fulcio eliminates long-lived credentials entirely in CI pipelines. Signing mode affects the trust root but not the attestation format, so teams can progress from unsigned statements to KMS-backed signing without changing how downstream tooling consumes the provenance.

Packer's new verify-attestation command is designed to sit inside deployment pipelines and pre-flight scripts, exiting non-zero on any failed check to block an image before it reaches an environment. HashiCorp details the expected use cases in the v1.16.0 release notes: deployment gates that reject images without valid signed attestations, incident response workflows that correlate a CVE with the affected commit and potentially affected running instances, and compliance evidence for common security audit and regulatory review programs. Reference CI workflows ship with the release covering both the L2 keyless pattern on GitHub Actions and an L3-compatible delegated signing variant that isolates provenance generation from the build job itself.

Three HCL2 improvements complete the update. A continue_on_error meta-argument for provisioners marks a step non-fatal so that diagnostic or telemetry scripts cannot block image delivery. Object-type variables now accept the optional() modifier per attribute, letting callers omit fields with declared defaults and making shared variable schemas easier to extend without updating every caller. Two new timestamp functions, rfc3339_parse() and unix_timestamp_parse(), convert between epoch integers and structured ISO timestamp objects for build-time image naming. All new features are opt-in, and existing Packer templates build without modification.

Share this story

Henrik Larsen

Henrik Larsen writes for the techshooked news desk, following cross-cutting technology stories that span more than one beat. He reports the news first and the analysis second, naming attribution clearly and flagging what is still unconfirmed.