Wie härtet man GitHub-Actions-Workflows sicherheitstechnisch ab?
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.
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.
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
- ✓Das Repository ist öffentlich oder nimmt Beiträge von externen Personen entgegen
Passt nicht
- ✗Es handelt sich um ein rein internes, privates Repository mit sehr wenigen vertrauenswürdigen Beitragenden