Geprüfter Tag, anderer Code im Lauf: Lockfiles für GitHub Actions

Du prüfst einen Pull Request, der uses: some-org/deploy-action@v4 in einen Workflow einträgt. Die Action sieht in Ordnung aus, du gibst frei, sie läuft. Einen Monat später läuft derselbe Workflow wieder, zeigt weiterhin auf v4 und führt Code aus, den niemand im Team gelesen hat. In deinem Repository hat sich nichts geändert. Der Tag wurde verschoben. Genau diese Lücke soll ein neues Feature schließen: Am 14. Oktober 2026 hat GitHub Workflow-Lockfiles als Public Preview veröffentlicht, verfügbar in den Plänen Free und Team sowie in Enterprise Cloud.

Warum ein geprüfter Workflow kein geprüfter Lauf ist

Tags und Branches lassen sich verschieben, nachdem du einen Workflow geprüft hast. GitHub beschreibt das Risiko selbst ohne Umschweife: Ist eine Action kompromittiert, kann ein verschobener Tag oder Branch Schadcode in deine Läufe bringen, ganz ohne Änderung in deinem Repository. Die Diff-Historie bleibt sauber, der Branch-Schutz greift nie, und die Änderung existiert nur im Repository eines anderen. Bei einem Workflow mit Deploy-Key oder Registry-Token steht damit alles auf dem Spiel.

Was das Lockfile fixiert

Laut GitHub kannst du im Workflow lesbare Referenzen wie @v4 behalten, während Actions genau die Commits ausführt, die du gesperrt hast. Erzeugt wird das Lockfile mit der Erweiterung gh actions-lock für die GitHub CLI. Sie schreibt .github/workflows/actions.lock mit prüfbaren Commits für deine Actions, deren transitive Abhängigkeiten und die Abhängigkeiten aufgerufener wiederverwendbarer Workflows. Wird der Tag später verschoben, nutzt der Lauf laut GitHub weiterhin den eingetragenen Commit.

Der Unterschied zum manuellen Pinnen von SHAs

Die altbekannte manuelle Lösung, als allgemeine Praxis, ist der volle 40-stellige Commit-SHA in der uses:-Zeile. Das funktioniert, ist aber schwer lesbar, wird beim Aktualisieren leicht vergessen und fixiert nur die Action, die du benannt hast. Ist diese Action eine Composite Action, die andere Actions per Tag aufruft, können sich diese inneren Referenzen weiterhin bewegen. Das Lockfile deckt diese transitive Ebene ab. Zusammen mit Dependabot erzeugt laut GitHub ein Versionsupdate für eine Action in einem eingebundenen Workflow den passenden Lockfile-Eintrag im selben Pull Request neu, sodass Pin und Upgrade gemeinsam geprüft werden.

Einführen ohne großen Umbau

Mit der Erweiterung von GitHub bindest du Workflows einzeln ein. Ist ein Workflow eingebunden, braucht er Lockfile-Einträge für seine Abhängigkeiten, und seine Läufe nutzen die eingetragenen Commits. Dieselbe Erweiterung kann ein veraltetes Lockfile erkennen, ohne Dateien zu ändern. Das passt zu einem CI-Schritt, der den Pull Request scheitern lässt, wenn der Lock nicht mehr aktuell ist. Admins auf Repository-, Organisations- oder Enterprise-Ebene können außerdem eine Richtlinie „Require lockfile" aktivieren, ebenfalls als Public Preview.

Ein praktischer erster Schritt: Nimm den Workflow in deinem Repository mit dem heikelsten Secret, meist den Deploy, führe gh actions-lock darauf aus, lies die eingetragenen Commits und ergänze die Prüfung auf veraltete Lockfiles in der CI. Danach kommt der nächste Workflow. GitHub dankt Andrew Nesbitt, François Proulx, Jesse Houwing und William Woodruff für die Zusammenarbeit an dem Feature. Quelle: GitHub Changelog, workflow lockfiles in public preview.