HashiCorp gibt Machine Images einen Herkunftsnachweis
Packer 1.16 kann die Herkunft von Golden Images signieren. Der Schalter bleibt werkseitig aus. Ohne Prüfung vor dem Start bleibt die Attestation ungelesen.
Ein kompromittiertes Machine Image startet in jeder Instanz mit. HashiCorp veröffentlicht Packer 1.16 mit einer Herkunftsangabe nach dem Supply-Chain-Standard SLSA: Der Build kann eine Attestation erzeugen, signieren und mit einem Befehl prüfen. Der Nachweis entsteht nur, wenn der Post-Processor eingeschaltet ist und jemand ihn vor dem Launch prüft.
Das Wichtigste in Kürze
- Packer 1.16 erzeugt eine prüfbare Herkunft. Packer kann SLSA-Attestationen für Machine Images erzeugen und signieren. HashiCorp hat die Version am 13. August 2026 im Blog angekündigt, auf GitHub erschien sie am 24. Juli 2026.
- Der Opt-in-Schalter bleibt werkseitig aus. Bestehende Templates bauen unverändert weiter. Provenance entsteht nur mit dem provenance-Post-Processor in der Vorlage. Die Prüfung vor dem Launch ist ein eigener Schritt.
- L3 ist kein Packer-Knopf. Der Changelog führt SLSA Build L1 und L2 als Feature. Das mitgelieferte L3-Beispiel ist ein getrennter Signatur-Job. Es stellt die Sicherheitsstufe der Build-Plattform nicht her.
Verwandt:OpenTofu vs. Terraform: welches IaC-Tool wirklich trägt / Hugging Face gehackt: Der Einstieg war ein Dataset-Loader
Was ist Packer 1.16? Die HashiCorp-Version, die SLSA-Provenance für Machine Images nativ im Build erzeugt, signiert und prüft. Ohne Post-Processor und ohne Prüfung vor dem Launch bleibt die Attestation eine Datei neben dem Amazon Machine Image (AMI).
Das Golden Image gilt als sicher, bis jemand die Herkunft prüft
Golden Images gelten als vertrauenswürdig, obwohl ihre Herkunft selten jemand prüft. Die Pipeline hat gebaut, das Image liegt in der Registry, Instanzen starten daraus. Wenn später eine Schwachstelle auftaucht oder ein Build verdächtig wirkt, beginnt die Suche in Logs, die oft schon weg sind. HashiCorp schreibt dazu, bis zu dieser Version ließ sich die Herkunft eines Machine Images nur aus Archiven rekonstruieren.
Die Lücke ist strukturell. Das SLSA-Framework, Supply-chain Levels for Software Artifacts, beschreibt abgestufte Garantien darüber, wie Artefakte entstehen. Die Werkzeuge dafür entstanden für Pakete und Container. Machine Images, also AMIs, VHD, QCOW2 und vergleichbare Cloud-Artefakte, lagen daneben. Genau dort startet jeder Workload. Ein getäuschtes Image infiziert leise jede Instanz, die daraus hochkommt.
Packer war schon der Ort, an dem diese Images gebaut werden. Was fehlte, war eine herstellerneutrale, signierte Herkunft, die andere Supply-Chain-Werkzeuge lesen können. Version 1.16 legt sie in den Build. Ob ein Team sie einschaltet und vor dem Start prüft, entscheidet über den Schutz.
Packer schreibt die Herkunft als in-toto-Aussage
Der neue provenance-Post-Processor ergänzt einen bestehenden Build. Nach dem Lauf schreibt Packer eine signierte Attestation als JSON in ein Verzeichnis, etwa attestations. Sie liegt neben dem Artefakt, in S3, in einer Registry oder im eigenen Artifact Store. Das Format ist ein in-toto-Statement, das Attestationsformat der Supply-Chain-Werkzeuge, mit einem SLSA-Provenance-v1-Prädikat. Genau das konsumieren bestehende Prüfwerkzeuge schon bei Containern.
Was die Aussage festhält, ist der Ursprung: Git-Commit, Repository und Ref, die CI-Pipeline, Zeitstempel. Bei lokalen Artefakten bindet Packer die Attestation an den SHA-256-Digest der Datei. Bei Cloud-Artefakten ohne lokale Datei bildet es einen kanonischen Identitätsdatensatz: immer Builder-ID und Artifact-ID, optional der Registry-Stand, etwa eine HCP-Packer-URI, wenn der Builder sie liefert.
HashiCorp bietet vier Ausgabemodi für die Attestation, darunter einen unsignierten. Unsigniert (none) schreibt eine JSON-Aussage für ein internes, bereits vertrautes System. key nimmt einen lokalen PEM-Schlüssel, sinnvoll in air-gapped Umgebungen. kms spricht AWS KMS, Google Cloud KMS, Azure Key Vault oder HashiCorp Vault über die jeweilige URI an. keyless nutzt Sigstore Fulcio und optional das Rekor-Transparenzlog, gedacht für GitHub Actions ohne langlebigen Schlüssel.
Bestehende Templates brauchen dafür keine Änderung. Packer 1.16 baut weiter, was 1.15 gebaut hat. Provenance ist ein Zusatz, den jemand in die HCL schreibt. Der Code liegt seit dem 24. Juli 2026 auf GitHub, der HashiCorp-Blog vom 13. August machte daraus die Ankündigung. Dort stehen auch die vier Signaturwege und das Attestationsformat: ein in-toto-Statement mit SLSA-Provenance-v1-Prädikat, keyless über Sigstore Fulcio mit optionalem Rekor-Eintrag, kms für AWS KMS, Google Cloud KMS, Azure Key Vault sowie HashiCorp Vault.
L3 ist kein Packer-Schalter
SLSA unterscheidet Build-Stufen mit steigenden Anforderungen. HashiCorp nennt drei davon im Zusammenhang mit Packer. Zwei erreicht das Werkzeug selbst, die dritte hängt an der Build-Plattform.
Build L1 heißt: Es gibt eine Provenance, die das Artefakt per Digest identifiziert und beschreibt, wie es entstand. Signieren ist auf dieser Stufe optional. signing_mode none erfüllt die Dokumentation, nicht die Fälschungssicherheit. Die Aussage muss mit dem Artefakt verteilt werden, sonst bleibt L1 eine interne Datei ohne Außenwirkung.
Build L2 verlangt einen gehosteten Dienst, der die Provenance erzeugt und signiert. HashiCorp zeigt das an einem Packer-Workflow auf GitHub Actions, Signatur im keyless-Modus, OIDC als kurzlebige CI-Identität des Jobs als Unterzeichner, Upload ins öffentliche Rekor-Log. Ein Referenz-Workflow liegt unter examples/ci. HashiCorp schreibt dazu: Dieses Muster erfüllt L2 nur, wenn die gehostete Build-Plattform und die Kontrollen der Provenance-Erzeugung die SLSA-L2-Anforderungen erfüllen. Packer allein stellt das nicht aus.
Das dritte Beispiel heißt bei HashiCorp ausdrücklich nur L3-kompatibel. Der Build-Job veröffentlicht dort nur den Digest. Ein getrennter Signatur-Job, ohne gemeinsamen Prozessraum mit den Build-Schritten, stellt die Attestation aus. Das Beispiel nutzt slsa-framework/slsa-github-generator. HashiCorp sagt klar: Das etabliert L3 nicht von selbst. L3 setzt eine gehärtete Plattform und Build-Isolation voraus. Der Changelog zur Version 1.16.0 nennt entsprechend die Features für SLSA Build L1 und L2. Ein YAML im Repository macht aus Packer 1.16 kein SLSA Build L3; die Stufe bleibt eine Eigenschaft der Build-Plattform.
Ohne Prüfung vor dem Start bleibt die Attestation ungelesen
Der neue Befehl packer verify-attestation ist nach HashiCorps Vorgabe für die Deploy-Pipeline oder den Pre-Flight vorgesehen. Scheitert eine Prüfung, endet der Befehl mit einem Fehlercode, der Deploy bleibt stehen. HashiCorp nennt Signaturidentität und Artefakt-Digest als Mindestprüfung. Für L2 kommen Rekor-Pflicht und Zeitstempel dazu.
Packer 1.16 macht Herkunft prüfbar, sobald der Post-Processor läuft und der Verify-Befehl vor dem Launch steht. Ohne diesen Schritt bleibt eine JSON-Datei neben der AMI. Ob der Befehl vor dem Launch läuft, entscheiden die Betreiber der Pipeline. Packer erzwingt ihn nicht.
Häufige Fragen
Was ändert Packer 1.16 an Machine Images?
Die Version kann für jedes gebaute Image eine SLSA-Provenance erzeugen, signieren und später prüfen. Neu und werkseitig ausgeschaltet sind ein Post-Processor und der Befehl packer verify-attestation. Ohne diese beiden Schritte baut Packer Images wie zuvor.
Was steht in einer Provenance-Attestation?
Eine signierte, maschinenlesbare Herkunft: Git-Commit, Repository, Ref, CI-Pipeline und Zeitstempel. Lokal kommt der SHA-256 der Datei dazu. In der Cloud ohne lokale Datei ein Identitätsdatensatz aus Builder-ID und Artifact-ID, optional mit Registry-URI. Das Format ist in-toto mit SLSA-Provenance-v1-Prädikat.
Muss ich bestehende Packer-Templates umbauen?
Nein. HashiCorp stellt die neuen Fähigkeiten als Opt-in. Bestehende Templates laufen unter 1.16 weiter. Provenance entsteht erst, wenn der Post-Processor in der HCL steht.
Reicht Packer 1.16 für SLSA Build L3?
Nein. Der Changelog führt L1 und L2 als Feature. Das L3-Beispiel trennt Build und Signatur in zwei Jobs und nutzt slsa-github-generator. HashiCorp schreibt, dass das L3 nicht allein herstellt. L3 bleibt eine Eigenschaft der Build-Plattform.
Was prüft packer verify-attestation?
Der Befehl prüft die Attestation gegen das Artefakt, die erwartete Signaturidentität und wählbare Zusatzpflichten wie Rekor und Zeitstempel. Bei einem Fehler endet er mit einem Fehlercode. In Pipelines ohne diesen Befehl starten Instanzen ohne Prüfung.
Lesetipps der Redaktion
cloudmagazinHugging Face gehackt: Der Einstieg war ein Dataset-LoadercloudmagazinStudie: Mehr Cloud-Budget füllt die Security-Lücke nichtcloudmagazinNHI-Sprawl: Lifecycle schlägt Login-MFAMehr aus dem MBF Media Netzwerk
MyBusinessFutureMcKinsey: KI macht schnell, der EBIT bleibt flachDigital ChiefsWarum KI an den Stammdaten scheitertSecurityTodayCISA listet Ray: Browser starten Cluster-Jobs ohne LoginBildquelle: KI-generiert (September 2026)
