GitHub Actions: Vertrauensgrenzen im Workflow prüfen

Originalquelle: GitHub Changelog · Datum der Meldung: 2026-11-02

Bestätigte Nachricht

GitHub kündigt die standardmäßige Sperre von pull_request_target in öffentlichen Repositories für 2026-12-02 an; private und interne Repositories sind ausgenommen.

Redaktionelle Einordnung

Die technische GitHub-Dokumentation erklärt, dass dieses Ereignis im Kontext des Basis-Repositorys läuft. Nicht vertrauenswürdigen Code darin auszuführen kann sensible Zugriffe gefährden. Unsere redaktionelle Einschätzung: Eine Ausnahme nur für einen weiterhin grünen CI-Status ist nicht automatisch die richtige Antwort. Zuerst muss feststehen, was jeder Workflow tatsächlich tut und ob genau diese Aufgabe die Befugnisse dieses Ausführungskontexts benötigt. Der bekannte Name eines Triggers ersetzt dieses Verständnis nicht.

Wir empfehlen, die Prüfung eingehender Inhalte von zur Veröffentlichung berechtigten Abläufen zu trennen. Ein hypothetisches Beispiel: Einen Pull Request zu kennzeichnen ist eine andere Entscheidung, als ein von ihm geliefertes Skript auszuführen. Prüfende sollten sowohl die Herkunft des Codes als auch die in jeder Stufe verwendete Berechtigung kennen. Das ist eine Prüfmethode und weder eine Änderung fremder Repository-Einstellungen noch die Behauptung, jede Verwendung dieses Triggers sei unsicher.

Vor der Entscheidung prüfen

• Abhängige Workflows erfassen und jeweils eine für die Wartung verantwortliche Person benennen.
• Checkout-Pfade gemeinsam mit allen erreichbaren Berechtigungen und Geheimnissen prüfen.
• Vor dem angekündigten Termin die Standardrichtlinie und den tatsächlichen Bedarf einer Ausnahme bewerten.

Praktische Schlussfolgerung

Auch Teams privater Repositories können die Meldung als Anlass zur Prüfung ihrer Vertrauensgrenzen nutzen, obwohl diese Änderung sie ausnimmt. Erfolg bedeutet, notwendige Arbeit mit möglichst geringen Befugnissen zu erhalten und neue Kontrollen nicht ohne Begründung zu umgehen.

Weiterführende Quelle · Passender Beitrag