GitHub Actions: Auch gesperrte Commits brauchen Prüfung
Was wurde freigegeben, wenn ein geprüftes Workflow später anderen Code ausführt? GitHub stellte am 14. Oktober Workflow-Lockfiles als Public Preview vor. Entscheidend ist, wer den festgehaltenen Commit und spätere Änderungen prüft.
Verfügbarkeit zuerst prüfen
Die korrigierte Ankündigung nennt GitHub Enterprise Cloud, Enterprise Cloud mit Data Residency, Team und Free. Es bleibt eine Vorschau. Das offizielle Repository schließt GHES aus und warnt vor Änderungen vor Version 1.0. Datum und Erweiterungsversion dokumentieren.
Tag und Freigabe auseinanderhalten
Die Erweiterung erstellt .github/workflows/actions.lock für Actions, transitive Abhängigkeiten und wiederverwendbare Workflows eingebundener Workflows. Bewegliche Referenzen verändern dadurch nicht unbemerkt den ausgeführten Commit. Der festgehaltene Code ist damit jedoch nicht automatisch sicher.
Klein und nachvollziehbar beginnen
Unser Betriebsvorschlag: zunächst ein Test-Workflow ohne Produktionsgeheimnisse oder Deployment-Rechte. uses-Referenzen, Eigentümer und Zweck erfassen; Workflow- und Lockfile-Diff gemeinsam prüfen und dem tatsächlichen Lauf zuordnen. Eine erzeugte Datei rechtfertigt keine sofortige unternehmensweite Pflicht.
Updates brauchen Verantwortliche
Laut README prüft gh actions-lock --verify ohne Schreibzugriff. --verify-local prüft offline die Struktur und ersetzt keine Vertrauensprüfung. CI-Ergebnis und Codeprüfung getrennt dokumentieren; Zuständigkeit, Abbruch und Wiederherstellung festlegen. Für diesen Artikel wurde nichts installiert.
Dependabot aktualisiert laut Ankündigung bei eingebundenen Workflows den passenden Lockfile-Eintrag im selben Versions-PR. Auch generierte Änderungen müssen geprüft werden. Unser Vorschlag: Referenz und Commit gemeinsam betrachten und Änderungen an Berechtigungen oder externen Zugriffen kontrollieren.
Reproduzierbarkeit ist kein Sicherheitsurteil. Offiziell erwähnte Community-Rückmeldungen belegen weder eine Unfallreduktionsrate noch universelle Kompatibilität. Vor Einführung das aktuelle README lesen und Prüfung, Fixierung und Aktualisierung jeweils einer Person zuordnen.
Offizielle Quellen
Am 15. Oktober 2026 geprüft; Produktangaben und Betriebsvorschläge sind getrennt.