Workflow-Lockfiles für GitHub Actions starten in die öffentliche Vorschau

GitHub hat Lockfiles für Workflow-Abhängigkeiten in GitHub Actions am 14. Oktober 2026 in die öffentliche Vorschau gebracht. Eine neue Datei, .github/workflows/actions.lock, hält den genauen Commit hinter jeder Action fest, die ein Workflow nutzt. Ein späterer Lauf kann so nicht mehr unbemerkt anderen Code einziehen. Diese Lücke in der Lieferkette mussten Teams bisher von Hand schließen.

GitHub Actions ist GitHubs System, um automatisierte Jobs wie Tests und Deployments auszuführen, wenn sich Code ändert. Diese Jobs bestehen aus wiederverwendbaren Schritten, die Actions heißen. Die meisten Actions liegen in Repositories anderer Leute.

Welches Problem das Lockfile löst

Ein Workflow nennt eine Action meist über einen Tag oder einen Branch, etwa actions/checkout@v6. Dieser Name kann morgen auf anderen Code zeigen. „Tags und Branches können sich verschieben, nachdem Sie einen Workflow geprüft haben, sodass ein späterer Lauf anderen Code ausführen könnte“, heißt es im Changelog von GitHub. GitHubs Dokumentation nennt einen Weg, wie das passiert: Das Konto eines Upstream-Maintainers wird übernommen, und ein Tag wird verschoben.

Bisher bestand der wichtigste Schutz darin, jede Action in der Workflow-Datei auf ihren vollständigen Commit-Hash zu pinnen, den sogenannten SHA. Laut GitHubs Dokumentation ist das für Repositories, die ein Lockfile einführen, „nicht mehr nötig“. Das Pinnen von Hand erfasste außerdem nicht die Actions, die andere Actions einbinden. Das Lockfile deckt auch diese indirekten, also transitiven, Abhängigkeiten ab.

Wie actions.lock funktioniert

Ein Kommandozeilen-Tool namens gh actions-lock schreibt die Datei. Es ist eine Erweiterung für gh, den Kommandozeilen-Client von GitHub. Installieren Sie es mit gh extension install github/gh-actions-lock und führen Sie dann gh actions-lock im Stammverzeichnis des Repositorys aus. Die Datei beginnt mit einer Warnung, sie nicht von Hand zu bearbeiten.

Jeder Eintrag für eine Abhängigkeit speichert vier Werte: die Referenz, den aufgelösten Commit sowie numerische IDs für Owner und Repository. Zur Laufzeit prüft Actions diese IDs. Das bestätigt, dass hinter dem Namen noch dasselbe Repository steht, das im Lockfile festgehalten wurde.

Punkt	Detail
Datei	.github/workflows/actions.lock
Tool	gh actions-lock, eine Erweiterung für die GitHub CLI
Deckt ab	Direkte Actions, transitive Actions, Abhängigkeiten wiederverwendbarer Workflows
Tarife in der Vorschau	Free, Team, Enterprise Cloud, Enterprise Cloud mit Datenresidenz
Durchsetzung	Eine Richtlinie „Require lockfile“ für Admins von Enterprises, Organisationen oder Repositories
Status	Öffentliche Vorschau seit dem 14. Oktober 2026

Teams können Workflows einzeln oder alle auf einmal aufnehmen, zum Beispiel mit gh actions-lock .github/workflows/ci.yml. Danach muss jede Action, die der Workflow nutzt, einen Eintrag haben, und Actions führt den festgehaltenen Commit aus. Das Tool schreibt außerdem eine lose Referenz wie @v3 auf die genaue Version um, die es gefunden hat, etwa @v3.1.0.

Wenn ein Upstream-Tag aus gutem Grund verschoben wird, aktualisiert gh actions-lock --relock den Eintrag. Ist ein festgehaltener Commit verschwunden, etwa nach einem Force-Push, verweist die Dokumentation auf --relock --accept-moved.

Wer es bekommt und was Dependabot macht

Der Changelog nennt vier Tarife: Free, Team, Enterprise Cloud und Enterprise Cloud mit Datenresidenz. Laut einer Anmerkung der Redaktion hat GitHub diese Liste am 14. Oktober geändert. Frühe Berichte, darunter OpenTools, beschrieben die Vorschau als nur für Enterprise Cloud verfügbar. Keine der Quellen erwähnt GitHub Enterprise Server, die selbst gehostete Edition.

Eine Richtlinie „Require lockfile“, ebenfalls in der Vorschau, erlaubt Admins, Lockfiles verpflichtend zu machen. Sie greift auf der Ebene von Enterprise, Organisation oder Repository.

Dependabot ist GitHubs Bot für Abhängigkeits-Updates. Wenn er eine Action in einem aufgenommenen Workflow aktualisiert, erzeugt er jetzt den passenden Lockfile-Eintrag im selben Pull Request neu. Neue Workflows nimmt er laut GitHubs Dokumentation nicht von selbst auf.

Was das Lockfile nicht leistet

Ein Lockfile friert Code ein, prüft ihn aber nicht. GitHubs Changelog rät Teams, Abhängigkeiten zu prüfen, bevor sie sie festschreiben. Der Entwickler Dave Kurian betont dasselbe in seinem Leitfaden auf DEV Community. „Das Lock hält fest, auf welchen Commit eine Workflow-Abhängigkeit aufgelöst wird; es bewertet nicht, ob die Action sicher ist.“

Bei wiederverwendbaren Workflows gibt es einen Haken. Ein wiederverwendbarer Workflow ist ein ganzer Workflow, den andere Workflows aufrufen. Er wird vom Lockfile des Repositorys abgedeckt, in dem er definiert ist, nicht von seinen Aufrufern. Teams, die Workflows aus einem zentralen Repository teilen, sollten laut Dokumentation zuerst dieses Repository mit einem Lockfile versehen.

Was das für Entwickler bedeutet

• Beginnen Sie mit einem Workflow. Versehen Sie zuerst einen Deploy- oder Release-Workflow mit einem Lockfile, denn dort liegen meist die stärksten Zugangsdaten. Beobachten Sie einige Läufe, bevor Sie den Einsatz ausweiten.
• Passen Sie Ihre Allowlists an. Manche Organisationen erlauben Actions per Tag, etwa actions/checkout@v6. Laut GitHubs Dokumentation passen solche Einträge nicht mehr zu Workflows mit Lockfile. Stellen Sie sie also auf eine Wildcard oder einen vollständigen SHA um.
• Schalten Sie zuerst Dependabot für Actions ein. Er hält Lockfile-Einträge im selben Pull Request aktuell, damit Workflows mit Lockfile nicht veralten.
• Prüfen Sie in der CI auf veraltete Lockfiles. Das Tool kann Einträge prüfen, ohne Dateien zu ändern. OpenTools schlägt eine verpflichtende Prüfung vor, die bei einem veralteten Lockfile fehlschlägt, dazu ein Review der Datei durch Code Owner.
• Warten Sie mit der Richtlinie, bis die Abdeckung steht. „Die Richtlinie einzuschalten, bevor Abdeckung und Update-Automatisierung bereit sind, kann Workflow-Läufe blockieren“, warnt OpenTools. Erst messen, dann durchsetzen.
• Behandeln Sie eine geänderte Owner- oder Repository-ID als Alarm. Laut GitHubs Dokumentation sollte eine solche Änderung selten sein. Untersuchen Sie sie, bevor Sie mergen.