GitHub hat Lockfiles für Workflow-Abhängigkeiten als Public Preview gestartet. Sie verhindern, dass ein verschobener Tag oder Branch unbemerkt anderen Code ausführt. Admins können die Nutzung per Richtlinie verlangen, und Dependabot hält die Einträge aktuell. Die Vorschau gilt für vier Tarife, darunter Free.
Ab dem 14. Oktober 2026 kannst du Lockfiles für GitHub Actions in vier Tarifen testen. Sie fixieren deine Abhängigkeiten auf einen geprüften Stand. GitHub hat die Meldung am 14. Oktober 2026 veröffentlicht und noch am selben Tag überarbeitet, ein Nachtrag korrigiert die Liste der Tarife.
Das Wichtigste in Kürze
- Lockfiles sperren Abhängigkeiten auf feste Commits. Deine Workflows behalten ihre Verweise, laufen aber mit dem Code, den du geprüft hast.
- Die Vorschau gilt für vier Tarife. Dazu zählen Enterprise Cloud, Enterprise Cloud mit Datenresidenz, Team und Free.
- Admins können Lockfiles vorschreiben. Die Richtlinie Require lockfile gilt für das Enterprise-Konto, eine Organisation oder einzelne Repositories.
- Dependabot pflegt die Einträge mit. Bei einem Update erzeugt er den passenden Lockfile-Eintrag im selben Pull Request.
Warum bewegliche Tags ein Risiko sind
Ein Workflow verweist oft auf Tags oder Branches einer Action. Beides kann sich verschieben, nachdem du den Workflow geprüft hast. Ein späterer Lauf führt dann anderen Code aus.
Das wird heikel, wenn eine Action kompromittiert wird. Ein verschobener Tag oder Branch bringt dann schädlichen Code in deinen Workflow. In deinem Repository ändert sich dabei nichts. Nichts warnt dich.
Deshalb setzt GitHub auf Lockfiles. Du behältst die Verweise im Workflow. Die Läufe nutzen aber den Stand, den du festgelegt hast.
Was die Lockfiles leisten
Ein Lockfile bindet jeden Lauf an die gesperrten Commits. So bleibt der Code gleich, bis du ihn bewusst änderst. Die Details stehen im GitHub Changelog.
Dabei gilt eine Grenze. Ein Lockfile sagt nichts darüber, ob eine Abhängigkeit sicher ist. Prüfe sie, bevor du sie sperrst.
| Kennzahl | Wert | Bedeutung |
|---|---|---|
| Status | Public Preview | Funktion ist offen testbar |
| Tarife | Vier, bis hinunter zu Free | Auch Gratis-Konten dürfen testen |
| Werkzeug | gh actions-lock | Erweiterung für die GitHub CLI |
| Richtlinie | Require lockfile | Admins erzwingen Lockfiles |
| Dependabot | Eintrag im selben Pull Request | Verweis und Sperre bleiben synchron |
Richtlinie und Dependabot
Die Richtlinie Require lockfile ist ebenfalls in der Public Preview. Damit schreiben Administratoren Lockfiles vor. Das geht auf drei Ebenen:
- für das ganze Enterprise-Konto
- für eine Organisation
- für ein einzelnes Repository
Zudem hilft Dependabot bei der Pflege. Er hält deine Actions aktuell. Öffnet er ein Versions-Update in einem Workflow mit Lockfile, erneuert er den passenden Eintrag im selben Pull Request. Du brauchst dafür keine zusätzliche Konfiguration.
So bleiben der aktualisierte Verweis und die gesperrte Version im Gleichschritt. Du prüfst beides in einem Review.
So startest du
Die Erweiterung gh actions-lock für die GitHub CLI erstellt und pflegt dein Lockfile. Der Einstieg geht in drei Schritten:
- Installiere die Erweiterung aus dem öffentlichen Repository gh-actions-lock.
- Prüfe das erzeugte Lockfile und die Änderungen am Workflow.
- Übernimm beides in dein eigenes Projekt.
Links zu den Setup-Anleitungen findest du in der Dokumentation unter GitHub Docs. Rückmeldungen kannst du in der bestehenden Community-Diskussion teilen. Alternativ öffnest du ein Issue im Repository gh-actions-lock.
Daran haben viele mitgearbeitet. GitHub dankt der Community für Tests und Feedback. Besonders erwähnt es Andrew Nesbitt, François Proulx, Jesse Houwing und William Woodruff. Sie haben die Lösung über das letzte Jahr eng begleitet.
Fazit
Lockfiles schliessen eine Lücke, die bewegliche Tags und Branches offen lassen. Du weisst jetzt, welche Tarife die Vorschau nutzen und wie Richtlinie und Dependabot ins Bild passen. Als nächsten Schritt installierst du die Erweiterung in einem Testrepository und prüfst das erzeugte Lockfile.
Quellen: GitHub Changelog. Foto: viarami / Pixabay. Stand: 14. Oktober 2026.
Recherche und Entwurf KI-gestützt, geprüft und freigegeben von Andreas Brauckmann · So arbeitet die Redaktion
Änderungshistorie
- — Artikel veröffentlicht.