Platform Engineering & DevOps
Wie härtet man GitHub-Actions-Workflows sicherheitstechnisch ab?
GitHub-Actions-Workflows werden häufig mit weitreichenderen Berechtigungen und größerem Vertrauen in Third-Party-Actions konfiguriert, als für die eigentliche Aufgabe notwendig wäre — ein verbreitetes, aber vermeidbares Risiko.
Nextise Wissen · · 6 Minuten Lesezeit
Direkte Antwort
Die wichtigsten Hardening-Maßnahmen für GitHub Actions sind minimale Token-Berechtigungen pro Workflow (statt Standard-Vollzugriff), das Pinnen von Third-Party-Actions auf einen konkreten Commit-Hash statt einer veränderlichen Versionsangabe, und strikte Kontrolle darüber, welche Workflows bei Pull Requests von Forks Zugriff auf Secrets bekommen.
Eine Third-Party-Action, die auf eine bewegliche Versionsangabe statt einen festen Commit verweist, kann sich nachträglich ändern, ohne dass der eigene Workflow davon etwas mitbekommt.
Minimale Token-Berechtigungen statt Standardrechten
Der von GitHub bereitgestellte `GITHUB_TOKEN` hat standardmäßig oft weitreichendere Berechtigungen als für den jeweiligen Workflow nötig. Diese Berechtigungen sollten explizit auf das Minimum reduziert werden, das der Workflow tatsächlich braucht (etwa nur Lesezugriff, wenn keine Schreibaktion nötig ist).
Diese Einschränkung begrenzt den Schaden, falls eine im Workflow genutzte Action kompromittiert wird oder sich fehlerhaft verhält — ein Workflow mit reinen Leserechten kann selbst im schlimmsten Fall keinen Code ins Repository schreiben.
Third-Party-Actions auf Commit-Hash statt Versions-Tag pinnen
Eine Third-Party-Action, die über einen Versions-Tag (etwa `@v2`) statt einen konkreten Commit-Hash eingebunden wird, kann sich nachträglich ändern, wenn der Tag vom Maintainer auf einen anderen Commit verschoben wird — im schlimmsten Fall durch einen kompromittierten Maintainer-Account.
Das Pinnen auf einen konkreten Commit-Hash stellt sicher, dass exakt der geprüfte Code ausgeführt wird, unabhängig davon, was der Maintainer später ändert, auch wenn dies bedeutet, Updates manuell und bewusst durchzuführen.
Secrets-Zugriff bei Pull Requests von Forks kontrollieren
Workflows, die bei Pull Requests von externen Forks automatisch mit Zugriff auf Secrets laufen, können missbraucht werden, um diese Secrets durch geschickt platzierten Code im Pull Request abzugreifen.
GitHub bietet dafür spezifische Trigger-Typen und Umgebungs-Schutzregeln, die sicherstellen, dass Secrets nur nach manueller Freigabe durch eine berechtigte Person für Pull Requests von externen Beitragenden verfügbar werden, statt automatisch bei jedem Fork-Pull-Request.
Wann passt es — wann nicht?
Passt gut, wenn …
- Das Repository ist öffentlich oder nimmt Beiträge von externen Personen entgegen
Ein anderer Ansatz ist nötig, wenn …
- Es handelt sich um ein rein internes, privates Repository mit sehr wenigen vertrauenswürdigen Beitragenden
Wissen allein reicht nicht — wir zeigen, wie es im Betrieb funktioniert.
Unsere Seminare verbinden die Konzepte aus dem Wissen-Hub mit konkreter Praxis. Ihr Team lernt direkt an eigenen Aufgaben — praxisnah, kompakt, sofort anwendbar.
Schulungen entdeckenLassen Sie uns über Ihr nächstes Training sprechen.
Unser Team steht Ihnen rund um die Uhr zur Verfügung und freut sich auf Ihre Anfrage. Einfach anrufen oder eine Nachricht hinterlassen – wir kümmern uns schnellstmöglich um Ihre Anfrage, ob es um eine Schulung, einen Vortrag oder eine Präsentation geht. Jetzt loslegen!
Selina Schmid
Leiterin Kodschul