Führen Sie ein GitHub-Actions-Lockfile zunächst für einen Workflow ein, dessen Änderung Ihr Team erklären und prüfen kann. Sehen Sie nach, welche Action-Commits die Datei erfasst, sichern Sie nicht erfasste Eingaben gesondert ab und bestimmen Sie, wer künftige Updates prüft. Das erste brauchbare Ergebnis ist ein Pull Request mit klar beschriebenem Umfang und einem erfolgreichen Lauf auf dem geprüften Stand.

Verglichen mit einer Sicherheitsverbesserung für das gesamte Repository wirkt das überschaubar. Dafür kann ein kleines Team diese Aufgabe abschließen. Eine generierte Datei wird dann nützlich, wenn die Prüfer verstehen, welchen ausführbaren Code sie freigegeben haben und was sich in dessen Umgebung weiterhin ändern kann.

GitHub hat Workflow-Lockfiles [am 28. Oktober allgemein verfügbar gemacht](https://github.blog/changelog/2026-10-28-github-actions-workflow-lockfiles-are-generally-available/), und zwar für die Tarife Free, Team und Enterprise Cloud, einschließlich Enterprise Cloud mit Datenresidenz. Hugo van Kemenades [Anleitung vom 11. November](https://hugovk.dev/blog/2026/lock-github-actions/) hat das Thema erneut aufgegriffen. Für Ihr Team stellt sich die Frage, wie es diese Absicherung einführt und dabei den übrigen Workflow im Blick behält.

## Was Sie mit einem Workflow-Lockfile freigeben

Ein Workflow-Lockfile hält fest, welche Action-Commits ein dafür eingerichteter Workflow ausführen soll, einschließlich transitiver Action-Abhängigkeiten. Laut [GitHubs Erläuterung des Konzepts](https://docs.github.com/en/actions/concepts/security/workflow-dependency-lockfiles) setzt der Runner diese Auflösung durch, prüft die Identität des Quell-Repositorys und weist einen erfassten Commit zurück, der über die hinterlegte Upstream-Referenz nicht erreichbar ist.

Sie erhalten damit einen konkreten Satz von Abhängigkeiten zur Freigabe. Die sichtbare Referenz einer Action mag leicht lesbar sein, doch bei ihrer Ausführung können weitere Actions beteiligt sein. Werden auch diese Abhängigkeiten erfasst, können Prüfer besser überblicken, welcher Code tatsächlich ausgeführt wird.

Die Freigabe erfordert weiterhin eine fachliche Entscheidung. Der erfasste Commit könnte Code enthalten, der zusätzliche Dateien liest, einen neuen Dienst kontaktiert oder Berechtigungen nutzt, die Ihr Workflow nie hätte erhalten sollen. Ein Lockfile kann auch diese Auswahl zuverlässig festhalten. GitHubs [Hinweise zur sicheren Nutzung](https://docs.github.com/en/actions/reference/security/secure-use) bleiben deshalb relevant: Prüfen Sie den Quellcode der Actions, beschränken Sie Token-Berechtigungen und behandeln Sie nicht vertrauenswürdige Inhalte aus Pull Requests mit Vorsicht.

Stellen Sie bei der Prüfung zwei Fragen: **„Verwendet dieser Lauf den erfassten Action-Code?“ und „Soll dieser Code hier ausgeführt werden dürfen?“** Ein Lockfile hilft bei der ersten Frage. Die zweite hängt vom Code, dem auslösenden Ereignis, dem Runner und dessen Befugnissen ab.

## Halten Sie den ersten Pull Request überschaubar

Stellen Sie sich ein Startup mit vier Personen vor, das einen Test-Workflow, einen Deployment-Workflow, einen gemeinsam genutzten wiederverwendbaren Workflow und einen Docker-Schritt hat. Dieses Einführungsbeispiel ist hypothetisch. Beginnen Sie mit dem Workflow, dessen Zweck, Eingaben und erwartete Ergebnisse eine verantwortliche Person erklären kann. Nehmen wir für dieses Team an, dass dies der Test-Workflow ist.

Beschreiben Sie vor dem Generieren in der PR-Beschreibung, wie dieser Workflow derzeit abläuft. Nennen Sie das auslösende Ereignis, die Herkunft des ausgecheckten Codes, die Befugnisse des Tokens, die verfügbaren Secrets und den verwendeten Runner. Wenn externe Mitwirkende den Workflow auslösen können, berücksichtigen Sie deren Code als Eingabe. Auch ein vermeintlich gewöhnlicher Testjob kann eine sensible Vertrauensgrenze berühren.

Nach [GitHubs Anleitung zur Einrichtung](https://docs.github.com/en/actions/how-tos/secure-your-work/lock-workflow-dependencies) lässt sich die Generierung auf einen Workflow beschränken. Nutzen Sie diese Möglichkeit, damit die erste Änderung gut prüfbar bleibt. Folgen Sie für Installation und Generierung der aktuellen Anleitung. Sehen Sie sich anschließend sowohl die Workflow-Änderungen als auch `actions.lock` an.

Achten Sie besonders auf lokale Actions. Eine `./`-Referenz verwendet die ausgecheckten Inhalte des Arbeitsverzeichnisses. Eine Umstellung auf `$/` verweist stattdessen auf den Commit des Workflows selbst. Das kann das Verhalten ändern, wenn sich der Workflow-Stand vom ausgecheckten Stand unterscheidet. Prüfen Sie die beabsichtigte Quelle ausdrücklich, bevor Sie die Umschreibung übernehmen. Eine nicht aufgelöste lokale Abhängigkeit muss untersucht werden.

Ihr erster PR sollte genügend Nachweise enthalten, damit ein Teammitglied eine Entscheidung treffen kann:

1. **Umfang:** der Workflow, für den das Lockfile eingerichtet wird, und die zunächst ausgelassenen Workflows.
2. **Auflösung:** die generierten Änderungen an den Abhängigkeiten, einschließlich transitiver Actions.
3. **Verhalten:** jede Umstellung lokaler Referenzen und jede weitere Workflow-Änderung.
4. **Validierung:** die Prüfmethode und ein erfolgreicher Workflow-Lauf auf dem Stand, der zur Prüfung vorliegt.
5. **Ausnahmen:** ausführbare Eingaben, die das Lockfile nicht erfasst, jeweils mit Zuständigkeit und Entscheidung.

Ein grüner Testlauf zeigt, dass der beobachtete Lauf erfolgreich abgeschlossen wurde. Lesen Sie auch die relevanten Job-Ausgaben: Wurden die vorgesehenen Tests ausgeführt? Sind die erwarteten Artefakte entstanden? Hat ein Schritt einen anderen Ausführungspfad genommen? Hinterlegen Sie den Link zum Lauf neben dem Diff, damit die prüfende Person beides ansehen kann.

## Erfassen Sie Eingaben außerhalb des Lockfiles

Der Umfang des Lockfiles wird besonders dort wichtig, wo Ihr Workflow etwas anderes aufruft. Das [offizielle CLI-README](https://github.com/github/gh-actions-lock/blob/main/README.md) dokumentiert Grenzen, darunter Aufrufe externer wiederverwendbarer Workflows und Container-Images. Halten Sie im ersten PR kurz fest, wie diese Eingaben abgesichert werden.

Wiederverwendbare Workflows brauchen besondere Aufmerksamkeit. [GitHubs Konzeptbeschreibung](https://docs.github.com/en/actions/concepts/security/workflow-dependency-lockfiles) erläutert, dass das Lockfile des aufrufenden Workflows Aufrufe über `jobs.<job_id>.uses` nicht auf einen Commit festlegt. Um den Aufruf eines wiederverwendbaren Workflows auf einen bestimmten Stand festzulegen, geben Sie den vollständigen SHA-Wert des Commits an. Die Action-Abhängigkeiten innerhalb des aufgerufenen Workflows gehören zum Lockfile seines Repositorys. Allein aus der generierten Datei des aufrufenden Workflows geht daher nicht hervor, welche Abhängigkeiten im aufgerufenen Repository erfasst sind.

Für das hypothetische Startup lässt sich die folgende Tabelle im PR zum Test-Workflow verwenden. Ersetzen Sie die beispielhaften Zuständigkeiten vor der Prüfung durch konkrete Namen.

| Bestandteil | Nachweise für den ersten PR | Zuständige Person | Offene Entscheidung |
| --- | --- | --- | --- |
| Ausgewählter Test-Workflow | Workflow-Diff, Prüfausgabe und erfolgreicher Lauf auf dem geprüften Stand | Workflow-Verantwortlicher | Für welchen Workflow als Nächstes ein Lockfile eingerichtet wird |
| Direkte und transitive Actions | Erfasste Commits und Prüfung des geänderten ausführbaren Codes | Prüfer der Abhängigkeiten | Ob jede Abhängigkeit für diesen Einsatz geeignet ist |
| Gemeinsam genutzter wiederverwendbarer Workflow | Vollständige Commit-Referenz beim Aufruf und Prüfung des erfassten Umfangs im aufgerufenen Repository | Verantwortlicher für den gemeinsamen Workflow | Etwaige dort nicht erfasste Abhängigkeiten |
| Docker-Schritt | Gesonderte Image-Referenz und Vorgaben für Digests | Image-Verantwortlicher | Wie Image-Updates geprüft werden |
| Lokale Action | Erläuterung der Inhalte des Arbeitsverzeichnisses im Vergleich zu den Inhalten des Workflow-Commits | Workflow-Verantwortlicher | Ob die generierte Umstellung beabsichtigt ist |
| Heruntergeladenes Werkzeug | Versions- oder Artefaktprüfung für den Download-Befehl | Werkzeug-Verantwortlicher | Welche Eingaben sich weiterhin ändern dürfen |

Die Zeile zu heruntergeladenen Werkzeugen ergibt sich daraus, was die Shell tatsächlich ausführt. Ein Befehl kann ausführbare Inhalte außerhalb der im Lockfile erfassten Action-Referenzen abrufen. Prüfen Sie diesen Ablauf und entscheiden Sie, wie Ihr Team das Artefakt identifiziert und prüft. Behandeln Sie eine ungeklärte Eingabe als ausdrückliche Ausnahme, über die entschieden werden muss.

Prüfen Sie außerdem gesondert, welche Zugriffe bei der Ausführung möglich sind. Runner-Images, Eingaben und Zugangsdaten werden unabhängig von der erfassten Action-Auflösung behandelt. Unsere [Checkliste für Zugriffe aus Agent-Sandboxen](/blog/ai-agent-sandbox-security-boundaries) vertieft die übergeordnete Frage: Was kann ein Lauf lesen, ändern und kontaktieren? Stellen Sie dieselbe Frage für Ihre CI, ohne anzunehmen, dass eine Abhängigkeitsdatei sie bereits beantwortet.

## Klären Sie die Zuständigkeit für das nächste Update

Beim nächsten Update wird aus der Entscheidung zur Einführung eine dauerhafte Wartungsaufgabe. Halten Sie fest, wer Lockfile-Änderungen prüft, welche Nachweise erwartet werden und wie ein neu hinzugefügter Workflow einbezogen wird.

GitHubs [Anleitung zur Durchsetzung von Lockfiles](https://docs.github.com/en/actions/how-tos/administer/enforce-workflow-lockfiles) sieht einen Pilotversuch vor, bevor Sie die Vorgaben breiter durchsetzen. Dependabot pflegt die Einträge bereits einbezogener Workflows. Neue Workflows richtet es dafür nicht automatisch ein. Nehmen Sie die Einrichtung deshalb in die Prüfliste für neue Workflows auf, statt darauf zu vertrauen, dass der Update-Bot diese Aufgabe erkennt und erledigt.

Wählen Sie die Prüfmethode passend zur jeweiligen Frage. Die [CLI-Dokumentation](https://github.com/github/gh-actions-lock/blob/main/README.md) unterscheidet die Offline-Prüfung des erfassten Umfangs mit `--verify-local` von Online-Herkunftsprüfungen mit `--verify`. Halten Sie fest, welche Prüfung ausgeführt wurde, und untersuchen Sie Fehler, bevor Sie weitere Workflows einbeziehen. Eine erfolgreiche lokale Prüfung des Umfangs und eine Online-Herkunftsprüfung liefern unterschiedliche Nachweise.

Die CLI-Dokumentation nennt außerdem eine Grenze, die Prüfer kennen sollten: Wird eine veränderliche Referenz innerhalb ihres Verlaufs auf einen älteren Stand zurückgesetzt, wird dies nicht erkannt. Prüfen Sie deshalb die tatsächliche Änderung der Abhängigkeit auch dann, wenn die Verifikation erfolgreich ist. Fragen Sie, welcher Code sich geändert hat, ob sich Verhalten oder erforderliche Berechtigungen geändert haben und ob Sie tatsächlich den ausgewählten Stand freigeben wollen.

Wenn Ihre Organisation Modi zur schrittweisen Einführung von Richtlinien nutzt, prüfen Sie deren Verfügbarkeit, bevor Sie einen bestimmten Ablauf zusagen. GitHub nennt Enterprise Cloud als Geltungsbereich für den Modus Evaluate. Auch ohne diesen Modus kann ein Team mit einem geprüften Workflow und einer verpflichtenden Verifikation beginnen.

Beziehen Sie weitere Workflows ein, sobald die verantwortliche Person den erfassten Umfang, die Ausnahmen und den Update-Ablauf des Pilotversuchs erklären kann. Entscheiden Sie über den Deployment-Workflow gesondert: Er hat andere Auswirkungen und erhält möglicherweise andere Zugangsdaten.

## Halten Sie Prüfnachweise bei einer gemeldeten CI-Schwachstelle fest

Eine reguläre Lockfile-Einführung gehört in Ihren Entwicklungs-PR. Geht die Arbeit auf eine Schwachstellenmeldung zurück, verknüpfen Sie die Meldung mit diesem PR und seinen Prüfnachweisen. Dokumentieren Sie, was gefährdet war, was sich geändert hat, welcher Stand geprüft wurde und was ungeklärt bleibt.

Die Rekonstruktion eines Vorfalls ist eine andere Aufgabe. Unser [Leitfaden zu kompromittierten Repositorys und Release-Grenzen](/blog/repository-compromise-package-release-checklist) erklärt, wie Sie feststellen, ob verdächtiger Quellcode in ein Release oder zu Nutzern gelangt ist. Ziehen Sie ihn heran, wenn diese Fragen aufkommen. Aus der ausgefüllten Einführungstabelle lässt sich keine frühere Gefährdung nachweisen.

Kits [Security-Workflow](/security/features) kann die Zuständigkeit für eine Meldung, verlinkte technische Nachweise und die Entscheidung der prüfenden Person zur Fix-Verifizierung an einem Ort festhalten. Der Lebenszyklus unterscheidet die Behebung von der Verifizierung des Fixes. Die prüfende Person kann eine Notiz ergänzen. Ihr Entwicklungsteam generiert weiterhin das Lockfile, untersucht den Workflow und entscheidet, ob der Fix funktioniert. Kit führt diese Bewertung nicht aus und verlangt auch nicht bei jeder Verifizierung einen schriftlichen Nachweis.

Wählen Sie für Ihren ersten PR einen Workflow aus, prüfen Sie die Änderungen am ausführbaren Code, benennen Sie nicht erfasste Eingaben und klären Sie die Zuständigkeit für das nächste Update. War eine Sicherheitsmeldung der Anlass, hinterlegen Sie die PR- und Laufreferenzen bei dieser Meldung. Geben Sie der nächsten prüfenden Person genügend Nachweise, um genau zu verstehen, was Ihr Team freigegeben hat.