Explore how Packer now secures your machine images with built-in provenance.

Packer 1.16 now bakes SLSA provenance directly into every machine image it builds, giving teams a tamper-proof record of how that image came to be. That's a meaningful step for security-minded organizations tired of…

4 min readInfoQ
Explore how Packer now secures your machine images with built-in provenance.

The quiet escalation happening under the hood of your infrastructure is supply chain security, and it just took a meaningful step forward with HashiCorp Packer 1.16. The headline feature isn't a new builder or a cloud provider integration; it's the native generation, signing, and verification of SLSA provenance attestations for every machine image the tool creates. As Claudio Masolo reports, this means teams can now produce a tamper-proof record of how an image was made, without bolting on a separate chain of third-party tools. For anyone who has tried to piece together a software bill of materials for a golden AMI or a base VM, this feels less like a feature and more like a missing limb finally growing back.

Here is the practical reality: most organizations are already struggling to answer the question, "What exactly is in this image, and how was it built?" Spreadsheets and READMEs don't cut it, and the audit trail usually starts at the moment someone asks for it, not at the moment the image was created. Packer's move doesn't just add a metadata field; it makes provenance a first-class artifact of the build process. That is a significant distinction. As we have noted in our coverage of software supply chain best practices, the gap between "we have a policy" and "we can prove we followed it" is where most breaches happen. This release closes part of that gap by making the attestation an output of the tool you already use, not a separate project to maintain. For a platform team, this is the difference between asking developers to remember to run a verification script and having the build system refuse to produce an unverifiable artifact.

Our take is straightforward: this is the kind of feature that doesn't make a flashy demo, but it changes the calculus for regulated industries and anyone facing a serious customer security questionnaire. The fact that it is native matters more than the specific SLSA level it targets. When you rely on external tools for provenance, you inherit their lifecycle, their update cadence, and their failure modes. Packer embedding this into its core means the provenance story is tested, versioned, and supported alongside the build tool itself. We would tell a reader who is evaluating this release to look at it not as a compliance checkbox, but as a risk reduction tool. The signing key for your images is now a first-class concern, which means you need to manage it with the same rigor as your code signing keys. That is a new operational burden, but it is a necessary one.

The specific detail to watch is how this interacts with your existing image promotion pipelines. Verification is only useful if it fails loudly when something is wrong. As you adopt this, ask yourself whether your current workflow treats a provenance verification failure as a blocker or as a warning. If it is the latter, you have not fixed your supply chain problem; you have just added another log line. The teams that get this right will be the ones who treat the new attestation as a gate, not a report. The technology is now in place. The discipline is still on you.

From InfoQ

HashiCorp has released Packer v1.16.0, adding native support for generating, signing, and verifying SLSA provenance attestations for every image the tool builds. The release provides teams with a secure, tamper-proof record of how a machine image was made. It does this without needing extra supply-chain tools.

Read the original at InfoQ