GitHub Actions Lockfiles: So werden CI/CD-Pipelines gegen manipulierte Abhängigkeiten robuster

Neue Sicherheitsfunktion für GitHub Actions: Was am 14. Oktober angekündigt wurde

GitHub hat am 14. Oktober 2026 Workflow Dependency Lockfiles für GitHub Actions als Public Preview vorgestellt. Die Funktion adressiert ein Problem, das in vielen Entwicklungsprojekten leicht übersehen wird: Ein Workflow kann unverändert im Repository liegen und bei seinem nächsten Lauf trotzdem anderen fremden Code ausführen. Das passiert, wenn eine verwendete Action über einen beweglichen Tag oder Branch eingebunden ist und sich dessen Ziel nachträglich ändert. Die neue Funktion soll diesen Unterschied zwischen geprüftem und tatsächlich ausgeführtem Code verkleinern.

Laut der aktualisierten Ankündigung ist die Vorschau für GitHub Free, Team sowie Enterprise Cloud einschließlich der Variante mit Data Residency verfügbar. Weil es sich um eine Preview handelt, können sich Bedienung und Rahmenbedingungen noch ändern. Für Webentwickler, Agenturteams und Betreiber automatisierter Deployments ist die Neuerung trotzdem relevant: Ihre CI/CD-Pipeline ist Teil der produktiven Infrastruktur und verdient dieselbe Sorgfalt wie der Anwendungscode.

Warum ein harmloser Versions-Tag zum Sicherheitsproblem werden kann

Viele Workflows enthalten Referenzen wie actions/checkout@v4 oder andere Actions mit einem Versions-Tag. Das ist gut lesbar und erleichtert Updates. Allerdings ist ein Tag technisch eine Referenz, die auf einen anderen Commit zeigen kann. Ändert ein Anbieter seine Referenz oder wird ein zugehöriges Konto kompromittiert, kann ein späterer Workflow-Lauf Code ausführen, den niemand im eigenen Projekt geprüft hat. Eine Änderung an der Workflow-Datei ist dafür nicht erforderlich.

Die Auswirkungen hängen von den Berechtigungen ab. Eine fremde Action kann möglicherweise auf ausgecheckten Quellcode, Build-Artefakte, Umgebungsvariablen oder für den Job freigegebene Zugangsdaten zugreifen. Besonders kritisch sind Veröffentlichungs- und Deployment-Pipelines mit Schreibrechten oder Zugriff auf externe Systeme. Nicht jeder bewegliche Tag ist ein Angriff; die fehlende Bindung an einen bestimmten Codezustand schafft aber eine unnötige Unsicherheit.

Wie actions.lock die ausgeführte Version festlegt

Ein Workflow-Lockfile liegt unter .github/workflows/actions.lock. GitHub stellt dafür die CLI-Erweiterung gh-actions-lock bereit, die Abhängigkeiten erfasst und die aufgelösten Commit-IDs speichert. Im Lockfile werden die zugeordneten Workflows und ihre Dependencies dokumentiert. Für jede aufgelöste Abhängigkeit sind unter anderem die ursprüngliche Referenz, der konkrete Commit sowie numerische Identifikatoren des Quell-Repositories hinterlegt. Diese Repository-Identität hilft, Namenswechsel oder unerwartete Ersetzungen nicht allein anhand eines Textnamens zu beurteilen.

Sobald ein Workflow in das Lockfile aufgenommen wurde, verlangt GitHub für seine erfassten Abhängigkeiten passende Einträge. Bei der Ausführung zählt der festgelegte Commit und nicht ein möglicherweise inzwischen verschobener Tag. Das verbessert Reproduzierbarkeit und Nachvollziehbarkeit. Wichtig ist jedoch die Unterscheidung: Das Lockfile dokumentiert, welcher Code ausgeführt wird. Es bescheinigt nicht, dass dieser Code frei von Sicherheitslücken oder absichtlich schädlichen Funktionen ist.

Mehr als direkt eingebundene Actions: Was abgedeckt wird

Ein wichtiger Unterschied zum einfachen Fixieren einzelner Actions ist die Berücksichtigung transitiver Abhängigkeiten. Nutzt eine Action selbst weitere Actions, können auch diese in die Auflösung einbezogen werden. Das reduziert die Gefahr, nur die oberste Ebene einer Abhängigkeitskette zu kontrollieren und den Rest unbemerkt beweglich zu lassen. Ebenso können Referenzen auf wiederverwendbare Workflows erfasst werden.

Dabei gibt es eine entscheidende Grenze: Die internen Abhängigkeiten eines wiederverwendbaren Workflows werden vom Lockfile des Repositories abgedeckt, in dem dieser wiederverwendbare Workflow definiert ist. Ein aufrufendes Projekt kontrolliert damit nicht automatisch jede interne Dependency eines fremden Workflow-Repositories. Teams mit zentralen Workflow-Vorlagen sollten deshalb zuerst die gemeinsam genutzten Repositories absichern und ihre Zuständigkeiten eindeutig festlegen.

Lockfile oder vollständige Commit-SHA: Was ist besser?

GitHub hat bisher empfohlen, Drittanbieter-Actions direkt in der Workflow-Datei auf eine vollständige Commit-SHA zu pinnen. Diese Methode bleibt nachvollziehbar: Der Workflow nennt exakt den auszuführenden Codezustand. In größeren Projekten leidet darunter jedoch die Lesbarkeit, weil statt sprechender Versionen lange Hashwerte in den YAML-Dateien stehen. Außerdem müssen Teams bei jeder Aktualisierung den passenden Commit bewusst nachziehen.

Mit einem eingeführten Workflow-Lockfile können die lesbaren Referenzen in den Workflow-Dateien stehen bleiben, während die konkreten Commits zentral dokumentiert werden. GitHub bezeichnet das für unterstützte Workflows als bessere Alternative zum direkten SHA-Pinning, unter anderem wegen transitiver Dependencies und gespeicherter Repository-Identitäten. Ein Lockfile ist damit kein Freibrief für beliebige Versionssprünge: Jede Änderung des festgelegten Commits sollte weiterhin wie eine Änderung am ausgeführten Programmcode geprüft werden.

Einführung in bestehende Projekte: Erst prüfen, dann festschreiben

Der offizielle Einstieg erfolgt über die GitHub CLI und die Erweiterung github/gh-actions-lock. Nach der Installation mit gh extension install github/gh-actions-lock kann im Repository die Anweisung gh actions-lock ausgeführt werden. Sie untersucht die Workflow-Dateien und erzeugt die Lockfile-Daten. Wer vorsichtig beginnen möchte, kann zunächst nur einen ausgewählten Workflow angeben, etwa gh actions-lock .github/workflows/ci.yml. So lässt sich die Wirkung an einem weniger kritischen Prozess erproben.

Vor dem ersten Commit sollte das Team alle Änderungen ansehen. Die Erweiterung kann nicht nur actions.lock erzeugen, sondern auch Referenzen in den Workflow-Dateien präzisieren oder lokale Action-Pfade umschreiben. Gerade bei bestehenden Deployment-Workflows ist deshalb ein Testlauf in einer geeigneten Umgebung sinnvoll. GitHub rät ausdrücklich davon ab, das generierte Lockfile manuell zu bearbeiten. Wenn etwas nicht stimmt, werden die Ursachen in den Workflows korrigiert und die Datei anschließend neu erzeugt.

Reviews müssen auch Lockfile-Änderungen ernst nehmen

Der Sicherheitsgewinn entsteht nicht allein durch die neue Datei, sondern durch einen kontrollierten Änderungsprozess. Eine geänderte Commit-ID bedeutet, dass die Pipeline anderen Code ausführen wird. Reviewer sollten deshalb prüfen, ob die neue Version aus der erwarteten Quelle stammt, welche Änderungen sie enthält und ob zusätzliche Berechtigungen erforderlich sind. Änderungen an owner_id oder repo_id verdienen besondere Aufmerksamkeit, weil sie auf eine andere Repository-Identität hinweisen können.

Für Teams empfiehlt sich ein CODEOWNERS-Eintrag für .github/workflows/actions.lock, ergänzt durch geschützte Branches oder Rulesets. So können Änderungen an kritischen Pipeline-Abhängigkeiten gezielt von Personen mit Security- oder Plattformverantwortung freigegeben werden. Diese Kontrolle hilft auch bei durch KI-Agenten erzeugten Pull Requests: Ein automatisch aktualisiertes Lockfile ist noch keine automatisch vertrauenswürdige Entscheidung.

Dependabot hält die festen Versionen beweglich – aber kontrolliert

Eine oft geäußerte Sorge bei festgeschriebenen Abhängigkeiten ist das Veralten. Wenn eine Action einen Sicherheitsfix erhält, soll der Commit nicht auf Dauer eingefroren bleiben. GitHub integriert deshalb Dependabot: Aktualisiert Dependabot eine Action in einem bereits eingebundenen Workflow, wird der zugehörige Lockfile-Eintrag im selben Pull Request nachgeführt. Damit lassen sich lesbare Versionsangabe und tatsächlich ausgeführter Commit gemeinsam prüfen.

Dependabot nimmt bislang nicht automatisch beliebige neue Workflows in das Lockfile auf. Die erstmalige Aufnahme bleibt ein eigener Schritt. Zusätzlich sollten Teams eine Prüfung einrichten, die fehlende oder veraltete Einträge erkennt. Laut Dokumentation eignet sich gh actions-lock --verify für CI-Prüfungen und gh actions-lock --verify-local --no-fix als schneller lokaler Check. Das Ziel ist ein klarer Ablauf: Update vorschlagen, Änderungen verstehen, Tests ausführen, freigeben und erst dann den neuen Code in produktiven Pipelines nutzen.

Policies, Berechtigungen und die Grenzen des Schutzes

GitHub bietet in der Preview außerdem eine Require-lockfile-Policy. Administratoren können damit die Verwendung von Lockfiles auf passenden Ebenen einfordern. Eine harte Durchsetzung sollte jedoch erst erfolgen, wenn alle betroffenen Workflows vorbereitet sind. Sonst können wichtige Builds oder Deployments blockiert werden. Die GitHub-Dokumentation empfiehlt deshalb eine schrittweise Einführung und zunächst einen Pilotbetrieb. Einzelne Verwaltungsfunktionen und Policy-Modi können je nach Tarif variieren.

Lockfiles ersetzen keine grundlegende Absicherung. Workflows sollten mit möglichst wenigen GITHUB_TOKEN-Rechten laufen, Secrets nur dort erhalten, wo sie benötigt werden, und externe Deployments nach Möglichkeit kurzlebige Zugangsdaten nutzen. Auch ungesicherte Pull-Request-Kontexte, Script-Injection und kompromittierte Runner bleiben eigenständige Risiken. Ein festgeschriebener schädlicher Commit bleibt schädlich; ein Lockfile verhindert lediglich, dass sich die ausführbare Abhängigkeit ohne entsprechende Änderung unbemerkt verschiebt.

Praxisbeispiel: Die kleine Website mit automatischem Deployment

Eine Agentur betreibt eine Website, deren Änderungen über einen GitHub-Actions-Workflow geprüft und auf einen Webserver übertragen werden. Der Workflow nutzt eine Checkout-Action, ein Build-Werkzeug und eine Drittanbieter-Action für den Upload. Ohne Lockfile könnten sich die hinter Tags stehenden Commits zwischen zwei Veröffentlichungen ändern. Mit Lockfile bleiben die tatsächlich verwendeten Versionen nachvollziehbar. Das ist besonders hilfreich, wenn nach einem fehlgeschlagenen Deployment untersucht werden muss, welche Komponenten wirklich beteiligt waren.

Für ein solches Projekt bietet sich ein überschaubarer Einstieg an: zuerst den Deployment-Workflow inventarisieren, anschließend die externen Actions und ihre Herausgeber prüfen, das Lockfile erzeugen und gemeinsam reviewen. Danach sollten automatische Dependency-Updates und eine Verifikationsprüfung ergänzt werden. Die eigentlichen Zugangsdaten zum Webserver gehören weiterhin in einen abgesicherten Secret- oder Identity-Mechanismus und nicht in die Workflow-Datei oder das Lockfile.

Fazit: Reproduzierbare Pipelines sind ein Sicherheitsbaustein, kein Gütesiegel

Die am 14. Oktober vorgestellten GitHub-Actions-Lockfiles machen einen unsichtbaren Teil der Software-Lieferkette überprüfbarer. Sie schaffen eine feste Verbindung zwischen Workflow, Abhängigkeit und ausgeführtem Commit und erleichtern kontrollierte Updates. Für kleine Webprojekte kann das ebenso sinnvoll sein wie für größere Entwicklungsorganisationen, denn bereits ein einzelner Deployment-Job kann weitreichende Zugriffsrechte besitzen.

Der wichtigste praktische Schritt ist nicht das bloße Erzeugen von actions.lock. Entscheidend sind die anschließenden Prozesse: geprüfte Herkunft, nachvollziehbare Änderungen, begrenzte Berechtigungen, regelmäßige Aktualisierungen und verlässliche Tests. Wer die Preview nutzen möchte, sollte mit einem Workflow beginnen, die Ergebnisse dokumentieren und erst nach erfolgreichen Tests ausweiten. So wird aus einer neuen GitHub-Funktion eine konkrete Verbesserung der CI/CD-Sicherheit.