GitHub Actions hat sich in den letzten Jahren als eines der zentralen Werkzeuge für Automatisierung in der Softwareentwicklung etabliert. Der nahtlose Workflow ermöglicht es Entwicklerteams, Continuous Integration und Continuous Deployment (CI/CD) effizient zu gestalten. Doch gerade die wachsende Verbreitung dieses Features hat auch neue Sicherheitsherausforderungen mit sich gebracht. Angesichts mehrerer prominenter Supply-Chain-Angriffe ist es heute wichtiger denn je, GitHub Actions konsequent abzusichern und potenzielle Angriffspunkte im Voraus zu erkennen. Die Risiken bei GitHub Actions sind vielfältig.
Von der unachtsamen Handhabung von Zugriffsrechten über den Einsatz unsicherer Drittanbieteraktionen bis hin zu falsch konfigurierten Workflows – Angreifer suchen und finden regelmäßig Wege, um die automatisierten Abläufe in ihren Sinn zu manipulieren. Ein Beispiel aus der jüngeren Vergangenheit zeigt, wie ein Angreifer im Rahmen eines Supply-Chain-Angriffs einen Cryptominer in eine beliebte Python-Paketversion eingeschleust hat. Ebenso bekannt ist der Vorfall mit der "tj-actions", bei dem das kompromittierte Personal Access Token (PAT) für eine Kettenreaktion von Schadaktionen genutzt wurde. Diese Vorfälle unterstreichen die Notwendigkeit eines systematischen Sicherheitskonzepts für GitHub Actions, das über einfache Empfehlungen hinausgeht und die gesamte Pipeline berücksichtigt. Grundlegend für ein sicheres Setup von GitHub Actions ist ein klares Verständnis wichtiger Begriffe.
Workflows sind die Automatisierungsskripte, die eine definierte Abfolge von Jobs enthalten, welche wiederum Aktionen ausführen – kleinste, wiederverwendbare Einheiten in GitHub Actions. Diese werden über Events ausgelöst, also beispielsweise bei Code-Pushes, Pull-Requests oder manuellen Eingriffen. Gerade die Verbindung von Workflows und Actions, die oftmals von Drittanbietern bezogen werden, ist ein kritischer Hebelpunkt für Sicherheitsmaßnahmen. Ein wichtiger Ansatz besteht darin, die Berechtigungen in GitHub konsequent nach dem Prinzip der minimalen Rechte zu vergeben. Bis Anfang 2023 waren Workflow-Tokens standardmäßig mit Schreibrechten ausgestattet, was Missbrauch begünstigt.
Heutzutage sollten diese Berechtigungen unbedingt auf „read-only“ gesetzt werden, um unbeabsichtigte oder böswillige Codeänderungen zu verhindern. Wer auf spezifische Schreiboperationen angewiesen ist, sollte diese Rechte selektiv auf Job-Ebene definieren und strikt monitoren. Die Kontrolle darüber, welche Aktionen innerhalb eines Workflows ausgeführt werden dürfen, ist ein weiterer essenzieller Sicherheitsbaustein. GitHub bietet die Möglichkeit, nur verifizierte Aktionen zuzulassen – sei es direkt von GitHub gepflegt oder von Marketplace-Verifizierten Herausgebern. Dadurch wird die Angriffsfläche deutlich reduziert, da nicht vertrauenswürdige Aktionen oder solche mit mangelnder Auditierung ausgeschlossen werden.
Für besonders sensible Umgebungen empfiehlt es sich zusätzlich, eine genaue Allowlist spezifischer Aktionen zu verwenden. Die Governance und Kontrolle von Runnern, auf denen Workflows ausgeführt werden, ist ebenso von großer Bedeutung. Speziell bei der Verwendung von Self-Hosted Runnern, die auf unternehmenseigenen Maschinen laufen, besteht ein erhöhtes Risiko durch Persistenz und mögliche Manipulation der Laufzeitumgebung. Eine strategische Trennung nach Vertrauenszonen, die Verwendung von Runner-Gruppen und strenge Beschränkungen des Netzwerkausgangs können potenzielle Angreifer daran hindern, weitergehenden Schaden anzurichten. Ephemere Runner, die nach jedem Job neu erzeugt und wieder gelöscht werden, sind aus Sicherheitsgesichtspunkten meist die bessere Wahl.
Branch Protection Regeln sind bei der Sicherung der zentralen Entwicklungs-Zweige unverzichtbar. Sie verhindern, dass unautorisierten Quellcode ins Hauptprojekt gelangt, indem sie Anforderungen wie obligatorische Code-Reviews und Statuschecks durchsetzen. Allerdings sind auch hier nicht alle Risiken eliminiert; Angriffe wie das Einfügen schädlicher Commits nach der Review oder das Übernehmen bestehender Pull Requests sind mögliche Angriffsvektoren. Methoden wie das automatische Rücksetzen von Reviews bei neuen Commits oder die Erfordernis von separaten Genehmigungen können helfen, diese Angriffe zu verhindern, wobei Teams pragmatisch abwägen müssen, wie viel Flexibilität sie ihren Prozessen zugestehen wollen. Ein besonders gefährlicher Bereich betrifft die Handhabung von Geheimnissen (Secrets) innerhalb von GitHub Actions.
Da Secrets wie Zugangsdaten, Schlüssel oder Tokens üblicherweise zur Authentifizierung und für kritische Systemzugriffe eingesetzt werden, bieten sie für Angreifer einen Schlüssel zur Eskalation von Zugriffsrechten. GitHub unterscheidet zwischen Repository-, Organisations- und Umgebungs-Secrets. Die Empfehlung lautet, jeweils die kleinstmögliche Einheit zu nutzen und Secrets nur an genau definierte Jobs weiterzugeben. Die Arbeit mit Environment-Secrets inklusive erforderlicher Genehmigungen vor Freigabe stellt eine zusätzliche Sicherheitsschicht dar. Ebenso wichtig ist es, zu verhindern, dass Secrets in Forks oder Pull Requests ungewollt verfügbar sind.
Das explizite Übergeben von Secrets an einzelne Schritte im Workflow senkt das Risiko einer umfänglichen Exposition. Neben den organisatorischen und konfigurativen Maßnahmen gibt es bei der Erstellung von Workflows selbst mehrere Fallstricke. Insbesondere die Verwendung privilegierter Trigger wie pull_request_target oder workflow_run erlaubt es Workflows, mit erhöhten Rechten ausgeführt zu werden, was missbraucht werden kann, wenn nicht vertrauenswürdiger Code aus Forks ausgecheckt wird. Abgesehen davon muss die Verwendung dynamischer Parameter in Skript-Schritten sorgfältig geprüft werden, damit beispielsweise keine Eingaben aus Pull-Request-Titeln oder Issue-Kommentaren ungefiltert in Ausführungsskripte gelangen und so Command Injection erlaubt wird. Ein kritischer Aspekt beim Umgang mit Workflows ist das Speichern und Weiterreichen von Artefakten.
Unbeabsichtigtes Mitspeichern von Zugangsdaten oder Geheiminformationen in Artefakten kann zur Offenlegung sensibler Daten führen. Daher sollten Parameter wie persist-credentials bei actions/checkout sorgfältig und restriktiv verwendet werden, um keine automatisch mitgelieferten Credentials unnötig zu verteilen. Die Verwendung von Third-Party Actions bleibt ein zweischneidiges Schwert. Während sie wichtige Funktionalitäten und Zeiteinsparungen bieten, erhöhen sie gleichzeitig das Risiko für Supply-Chain-Angriffe. Maßnahmen wie das Hash-Pinning, also die genaue Angabe einer spezifischen Commit-Version statt unsicherer Tag-Nutzung, tragen dazu bei, ungewollte oder bösartige Codeänderungen zu verhindern.
Zusätzlich empfiehlt es sich, bei der Auswahl Dritter die Anzahl der Mitwirkenden, die Code-Komplexität sowie die Popularität und Wartungsqualität der Aktionen zu bewerten und stets darauf zu achten, dass Best Practices beim Versionieren und Sicherheitspatching eingehalten werden. Eine technische Innovation, die zunehmend an Bedeutung gewinnt, ist die Verwendung von OpenID Connect (OIDC) zur Authentifizierung von Workflows gegenüber Cloud-Anbietern. Dadurch lassen sich traditionelle, langlebige Geheimnisse minimieren und stattdessen kurzlebige, identitätsgebundene Zugangstoken verwenden, die automatische Zugriffsbeschränkungen und eine bessere Nachvollziehbarkeit ermöglichen. Am Ende bestehen die wichtigsten Empfehlungen darin, den Einsatz von Drittanbieter-Aktionen so klein wie möglich zu halten, die eingesetzten Aktionen durch Hash-Pinning exakt zu fixieren und gemischte Zugriffsrechte in der Workflow- und Repository-Administration systematisch zu begrenzen. Ebenso sollten die Identifikation und der Umgang mit Risiken eines Poisoned Pipeline Execution konsequent umgesetzt werden.
