Am 14. Oktober 2026 hat GitHub die öffentliche Vorschau von Workflow-Abhängigkeits-Lockfiles für GitHub Actions gestartet. Die Funktion adressiert einen bekannten blinden Fleck in CI/CD-Pipelines: Ein Workflow, der eine Action über ihr Tag referenziert (uses: owner/action@v3), kann bei jedem Lauf anderen Code ausführen, wenn dieses Tag verschoben wird, auch nach einer Kompromittierung des Action-Repositorys. Lockfiles fixieren jede Abhängigkeit auf einen geprüften Commit, ohne die Syntax bestehender Workflows zu ändern.
Das Problem: Tags, die sich verschieben lassen
In einem typischen GitHub-Actions-Workflow garantieren Tag- oder Branch-Referenzen nichts über die Stabilität des ausgeführten Codes: Ein Maintainer kann ein Tag auf einen neuen Commit umsetzen, absichtlich oder nach einer Übernahme des Repositorys. Es ist einer der am besten dokumentierten Supply-Chain-Angriffsvektoren auf CI/CD-Plattformen, und bisher war die einzige verlässliche Abwehr das manuelle Fixieren jeder Action auf einen Commit-Hash, eine Praxis, die kaum je aktuell gehalten wurde.
Wie Lockfiles funktionieren
Die Umsetzung erfolgt über eine Erweiterung der GitHub-CLI, gh actions-lock, die eine Datei .github/workflows/actions.lock erzeugt. Diese Datei hält fest, welche Commits für jede Action verwendet werden sollen, einschließlich ihrer transitiven Abhängigkeiten und aufgerufener wiederverwendbarer Workflows. Die Einführung erfolgt Workflow für Workflow: Sobald ein Workflow umgestellt ist, müssen alle seine Abhängigkeiten im Lockfile stehen, und GitHub Actions führt dann genau die festgehaltenen Commits aus.
gh extension install github/gh-actions-lock
gh actions-lock init
gh actions-lock verifyDer Befehl verify prüft, ob das Lockfile aktuell ist, ohne Dateien zu verändern, was es erlaubt, ihn als Pflichtprüfung in eine Pull Request einzubauen statt ihn nur lokal laufen zu lassen.
Dependabot und Durchsetzungsrichtlinie
Wenn Dependabot ein Versionsupdate für eine bereits gesperrte Action öffnet, erzeugt es automatisch den passenden Lockfile-Eintrag in derselben Pull Request neu, ohne zusätzliche Konfiguration. Daneben erlaubt eine ebenfalls in öffentlicher Vorschau befindliche Richtlinie „Require lockfile“ Administratoren, die Nutzung von Lockfiles auf Unternehmens-, Organisations- oder Repository-Ebene zu erzwingen.
| Ebene | Wer aktiviert sie | Wirkung |
|---|---|---|
| Repository | Repository-Administrator | Erzwingt Lockfiles nur für die Workflows dieses Repositorys |
| Organisation | Organisations-Administrator | Erzwingt Lockfiles für alle Repositorys der Organisation |
| Unternehmen | Unternehmens-Administrator | Erzwingt Lockfiles für alle angeschlossenen Organisationen |
Eine Abhängigkeit zu sperren fixiert eine bestimmte Revision, garantiert aber nicht deren Sicherheit: Die Code-Prüfung bleibt Aufgabe des Teams, das sie einsetzt.
github/gh-actions-lock.Die Einführung bleibt freiwillig, solange ein Administrator die Richtlinie „Require lockfile“ nicht aktiviert, was Teams Zeit gibt, zunächst ihre sensibelsten Workflows zu migrieren, typischerweise jene, die Deployment oder die Veröffentlichung von Paketen betreffen. Für ein Team, das bereits konsequentes Hardening seiner Produktionsumgebungen praktiziert, fügt sich das Workflow-Lockfile in dieselbe Logik ein: die Angriffsfläche verkleinern, indem bewegliche Referenzen beseitigt statt nachträglich überwacht werden.
Erste Schritte
Die Erweiterung wird aus dem öffentlichen Repository github/gh-actions-lock installiert, zusammen mit dem üblichen Satz an Kommandozeilen-Werkzeugen, auf die Teams im Alltag der Webentwicklung ohnehin zurückgreifen. Nach der Erzeugung sollten das Lockfile und die damit verbundenen Workflow-Änderungen geprüft und wie jede andere CI-Konfigurationsänderung committet werden.
Das Wichtigste in Kürze
- Workflow-Lockfiles fixieren jede GitHub-Actions-Action auf einen bestimmten Commit, statt auf ein Tag oder einen Branch, der sich verschieben lässt.
- Die Einführung erfolgt Workflow für Workflow über die Erweiterung
gh actions-lock, mit einer in CI integrierbaren Prüfung. - Dependabot erzeugt Lockfile-Einträge bei Versionsupdates automatisch neu.
- Eine Durchsetzungsrichtlinie existiert auf drei Ebenen, bleibt aber optional, bis ein Administrator sie aktiviert.
- Die Sperre schützt vor dem Verschieben eines Tags, nicht vor einer Abhängigkeit, die zum Zeitpunkt der Fixierung bereits bösartig war.
Diese Art von Funktion hätte es längst geben müssen: Eine Action auf einen Commit-Hash zu fixieren ist seit Jahren als gute Praxis bekannt, aber kaum jemand pflegt das von Hand. Die Sperre zu automatisieren und an Dependabot zu koppeln, ändert die Lage, vorausgesetzt Teams aktivieren die Durchsetzungsrichtlinie auch wirklich, statt das Lockfile als Option zu belassen, die jeder vergisst. — Simon Janvier
Weiterführend: die offizielle Ankündigung im GitHub-Changelog.
