GitHub Actions sicher konfigurieren: Secrets schützen, Rechte minimieren, Supply-Chain-Risiken senken

Ein Pull Request aus einem Fork sieht auf den ersten Blick harmlos aus: Ein neuer Test, ein kleiner Bugfix, vielleicht eine aktualisierte Abhängigkeit. Sobald dein Workflow aber Code aus diesem Pull Request mit Zugriff auf Secrets, Schreibrechte oder einen selbst gehosteten Runner ausführt, kann daraus ein direkter Angriffsweg in eure Build- und Release-Umgebung werden. Genau deshalb gehören GitHub-Actions-Workflows in dieselbe Sicherheitsbetrachtung wie Produktionscode und Infrastruktur.

CI/CD-Pipelines sind ein attraktives Ziel für Angriffe auf die Software-Lieferkette. Wer eine Pipeline kontrolliert, kann Quellcode verändern, Artefakte manipulieren, Zugangsdaten auslesen oder unerwünschte Releases erzeugen. Die gute Nachricht: Viele Risiken lassen sich mit wenigen, konsequent umgesetzten Maßnahmen deutlich reduzieren.

Infografik zu GitHub Actions sicher konfigurieren: Secrets schützen, Rechte minimieren, Supply-Chain-Risiken senken (KI-generiert).

Warum GitHub Actions besonders schützenswert sind

Ein GitHub-Workflow verbindet oft mehrere sensible Bereiche:

• Quellcode und Pull Requests
• Paketregistries und Container-Registries
• Cloud-Konten und Deployments
• API-Token, Zertifikate und SSH-Schlüssel
• externe Actions aus öffentlichen Repositories
• Build-Artefakte und Release-Dateien

Damit wird die Pipeline zur Vertrauensbrücke zwischen Entwicklung, Repository und produktiver Umgebung. Ein Fehler in der Workflow-Konfiguration kann weitreichendere Folgen haben als eine einzelne Schwachstelle in einer Anwendung.

Besonders kritisch sind Workflows, die automatisch bei Pull Requests, Tags oder manuellen Ausführungen starten. Prüfe deshalb nicht nur den YAML-Code selbst, sondern immer auch den Auslöser, die Rechte, die verwendeten Actions, die Secrets und die Runner-Umgebung.

Third-Party-Actions unveränderlich pinnen

GitHub Actions werden häufig über Versions-Tags eingebunden, etwa mit actions/checkout@v4. Das ist bequem, aber nicht unveränderlich. Ein Tag kann auf einen anderen Commit verschoben werden. Wird das Repository einer Action kompromittiert oder ein Tag fehlerhaft aktualisiert, kann dein Workflow beim nächsten Lauf anderen Code ausführen als bisher.

Für besonders vertrauenswürdige und kritische Workflows solltest du externe Actions deshalb auf einen vollständigen Commit-Hash pinnen. Der Hash referenziert einen konkreten, unveränderlichen Stand.

Statt einer beweglichen Referenz wie actions/checkout@v4 verwendest du einen vollständigen Commit-SHA. Ergänze den Eintrag mit einem Kommentar, der die lesbare Version dokumentiert. So bleibt der Workflow wartbar und zugleich nachvollziehbar.

Beim Pinnen solltest du diese Regeln beachten:

• Pinne insbesondere Actions mit Zugriff auf Secrets, Token, Artefakte oder Deployment-Ziele.
• Verwende vollständige Commit-Hashes statt verkürzter Hashes.
• Prüfe, ob die Action tatsächlich vom erwarteten Herausgeber stammt.
• Reduziere die Zahl externer Actions auf das notwendige Maß.
• Aktualisiere gepinnte Actions bewusst und prüfe Änderungen vor der Übernahme.
• Dokumentiere intern, welche Actions für welche Zwecke freigegeben sind.

Auch bekannte Actions verdienen diese Prüfung. Bekanntheit ersetzt keine technische Absicherung. Bei kleineren oder wenig gepflegten Actions solltest du besonders kritisch sein: Werden Releases gepflegt? Ist der Quellcode nachvollziehbar? Werden Berechtigungen erklärt? Gibt es eine klare Sicherheitskommunikation?

Wenn eine Action nur wenige Zeilen Shell-Code ausführt, kann es sicherer und transparenter sein, die benötigten Schritte direkt im Workflow abzubilden. Das gilt aber nicht pauschal: Eigene Skripte müssen ebenso gepflegt, geprüft und abgesichert werden.

GITHUB_TOKEN nach dem Least-Privilege-Prinzip begrenzen

GitHub stellt Workflows automatisch ein GITHUB_TOKEN bereit. Dieses Token kann, abhängig von Repository-Einstellungen und Workflow-Konfiguration, auf Repository-Inhalte, Pull Requests, Issues, Packages oder Deployments zugreifen. Häufig sind diese Rechte weiter gefasst, als ein einzelner Job sie benötigt.

Lege Berechtigungen deshalb explizit fest. Beginne möglichst restriktiv mit permissions: {} und erteile dann nur die Rechte, die ein konkreter Job benötigt. Ein Build-Job, der ausschließlich Code auscheckt und Tests ausführt, braucht in vielen Fällen nur Leserechte auf Repository-Inhalte.

Die folgende Übersicht hilft bei der Einordnung:

Aufgabe im Workflow	Typische minimale Berechtigung
Quellcode auschecken	contents: read
Kommentare in Pull Requests schreiben	pull-requests: write
Release erstellen oder Tag schreiben	contents: write
Pakete aus einer Registry lesen	packages: read
Pakete veröffentlichen	packages: write
OIDC-Token für Cloud-Zugriff anfordern	id-token: write

Vergib Rechte nach Möglichkeit auf Job-Ebene. Dadurch erhält ein Test-Job nicht automatisch dieselben Berechtigungen wie ein Release-Job. Das begrenzt den Schaden, falls ein einzelner Schritt manipuliert wird oder eine Abhängigkeit unerwartetes Verhalten zeigt.

Prüfe außerdem die Standardberechtigung für Workflows in den Repository- oder Organisationseinstellungen. Wenn du standardmäßig Leserechte setzt und zusätzliche Schreibrechte nur gezielt im Workflow vergibst, verhindert ihr viele Fehler bereits durch sichere Voreinstellungen.

Wichtig ist die Abgrenzung: Das GITHUB_TOKEN ist nicht dasselbe wie ein klassisches Personal Access Token. Verwende persönliche Tokens nicht als bequemen Ersatz, wenn eine fein begrenzte GitHub-Berechtigung oder ein kurzlebiger Cloud-Zugang ausreicht.

Secrets sicher speichern und ihren Einsatz begrenzen

Secrets gehören in GitHub Secrets, nicht in Repository-Dateien, Workflow-Dateien, Issues oder Build-Skripte. Das klingt selbstverständlich, scheitert in der Praxis aber oft an Debug-Ausgaben, unbedachten Shell-Befehlen oder Konfigurationsdateien.

Nutze Repository-Secrets nur dann, wenn ein Geheimnis wirklich für genau dieses Repository gilt. Für gemeinsam genutzte Werte können Organisations-Secrets passend sein. Begrenze dabei, welche Repositories das Secret verwenden dürfen. Für besonders sensible Deployment-Zugangsdaten bieten sich Umgebungs-Secrets an, die an eine konkrete GitHub-Umgebung gekoppelt sind.

Achte beim Umgang mit Secrets auf folgende Punkte:

• Übergib Secrets nur an Schritte, die sie wirklich benötigen.
• Vermeide globale Umgebungsvariablen für sensible Werte.
• Gib keine vollständigen Umgebungsvariablen, Konfigurationsdateien oder Debug-Informationen aus.
• Prüfe Skripte auf Befehle wie set -x, die Argumente und Variablen protokollieren können.
• Rotiere Secrets nach Verdacht auf Offenlegung sofort.
• Verwende getrennte Zugangsdaten für Test, Staging und Produktion.
• Begrenze Secrets durch Rechte, IP-Regeln oder Ressourcenzugriffe auch außerhalb von GitHub.

GitHub versucht, bekannte Secret-Werte in Logs zu maskieren. Darauf darfst du dich aber nicht verlassen. Abgewandelte, kodierte oder zusammengesetzte Werte können dennoch sichtbar werden. Protokolliere daher grundsätzlich keine Zugangsdaten und keine Antworten von APIs, die Tokens enthalten könnten.

Wo es technisch möglich ist, empfehlen wir kurzlebige Identitäten statt langlebiger Secrets. Für Cloud-Deployments ist OpenID Connect, kurz OIDC, oft die bessere Wahl: GitHub stellt dabei zeitlich begrenzte Identitätsinformationen bereit, und die Cloud-Plattform prüft definierte Bedingungen wie Repository, Branch, Umgebung oder Workflow. Du vermeidest damit statische Cloud-Schlüssel in GitHub Secrets.

Pull-Request-Workflows strikt vom Vertrauensbereich trennen

Der häufigste Konfigurationsfehler betrifft die Wahl des Workflow-Auslösers. Bei pull_request läuft der Workflow im Kontext des Pull Requests. Bei Pull Requests aus Forks stehen Secrets in der Regel nicht zur Verfügung, und das Token ist eingeschränkt. Das ist ein wichtiger Schutzmechanismus.

Besondere Vorsicht ist bei pull_request_target erforderlich. Dieser Auslöser läuft im Sicherheitskontext des Ziel-Repositorys, nicht im Kontext des Forks. Er wird häufig eingesetzt, um etwa Labels oder Kommentare zu verwalten. Problematisch wird es, wenn du anschließend Code aus dem Pull Request auscheckst oder ausführst.

Ein unsicheres Muster wäre: pull_request_target startet, der Workflow lädt den Head-Commit des externen Pull Requests und führt danach Tests, Skripte oder Paketinstallationen mit Zugriff auf Secrets aus. Ein Angreifer kann dann Build-Skripte, Konfigurationsdateien oder Testcode so verändern, dass Geheimnisse abfließen oder schreibende Repository-Aktionen ausgelöst werden.

Halte dich für Pull Requests aus Forks an diese Leitlinien:

• Nutze für Build und Test unprivilegierter Änderungen bevorzugt pull_request.
• Verwende pull_request_target nur für klar begrenzte Metadaten-Aktionen.
• Checke in einem privilegierten pull_request_target-Workflow keinen fremden PR-Code aus.
• Starte Deployments nicht automatisch aufgrund eines externen Pull Requests.
• Erlaube manuelle Freigaben nur für nachvollziehbare, geprüfte Änderungen.
• Trenne Kommentar-, Label- und Prüfautomatisierung von Release- und Deployment-Workflows.

Auch workflow_run verlangt Aufmerksamkeit. Dieser Auslöser kann nach Abschluss eines anderen Workflows laufen und wird oft für privilegierte Folgeprozesse genutzt. Wenn ein unprivilegierter Workflow Artefakte erzeugt und ein privilegierter Folgeworkflow diese ungeprüft verarbeitet, kann Artefakt-Manipulation zur Rechteausweitung führen. Prüfe Herkunft, Inhalt und Integrität von Artefakten, bevor ein privilegierter Job sie übernimmt.

Runner absichern und Ausführungsumgebung klein halten

GitHub-gehostete Runner sind für viele Standardfälle eine gute Ausgangsbasis, weil sie pro Job neu bereitgestellt werden. Selbst gehostete Runner sind dagegen dauerhaft, oft stärker vernetzt und deshalb deutlich sensibler.

Auf einem selbst gehosteten Runner können zurückgebliebene Dateien, Caches, Zugangsdaten oder Prozesse späteren Jobs zugänglich sein. Ein bösartiger Pull Request darf deshalb niemals beliebigen Code auf einem Runner ausführen, der Zugriff auf interne Netze, Produktionssysteme oder wertvolle Secrets besitzt.

Wenn ihr selbst gehostete Runner benötigt, setzt auf klare Trennung:

• Verwende getrennte Runner-Gruppen für untrusted Builds und privilegierte Deployments.
• Gib Pull Requests aus Forks keinen Zugriff auf interne Runner.
• Bereinige Arbeitsverzeichnisse, Caches und temporäre Dateien zuverlässig.
• Betreibe Runner möglichst kurzlebig und automatisiert neu erzeugbar.
• Beschränke Netzwerkzugriffe auf benötigte Ziele.
• Aktualisiere Runner-Software und installierte Werkzeuge zeitnah.

Zusätzlich solltest du Shell-Schritte wie Anwendungscode behandeln. Verwende keine unkontrollierten Eingaben direkt in Shell-Befehlen. Werte aus Branch-Namen, Commit-Nachrichten, Issue-Titeln oder Pull-Request-Beschreibungen können Inhalte enthalten, die bei unsauberer Übergabe Befehle beeinflussen. Übergib solche Werte kontrolliert über Umgebungsvariablen und achte auf korrektes Quoting.

Sicherheitsprüfung als fester Teil des Workflow-Lebenszyklus

Eine sichere Pipeline entsteht nicht durch eine einmalige Bereinigung. Neue Actions, geänderte Berechtigungen, zusätzliche Umgebungen und neue Deployment-Wege verändern das Risiko laufend. Nimm Workflow-Dateien deshalb in Code Reviews besonders ernst.

Unsere kompakte Prüfliste für Reviews:

• Sind alle externen Actions auf vollständige Commit-Hashes gepinnt?
• Ist das GITHUB_TOKEN standardmäßig und je Job minimal berechtigt?
• Werden Secrets nur gezielt und nicht global bereitgestellt?
• Sind Pull-Request-Workflows von privilegierten Release-Prozessen getrennt?
• Verarbeitet kein privilegierter Workflow ungeprüfte Artefakte oder fremden Code?
• Sind selbst gehostete Runner von externen Beiträgen isoliert?
• Gibt es nachvollziehbare Freigaben für produktive Deployments?
• Werden Änderungen an Workflows von Personen mit Security-Verständnis geprüft?

Bei uns behandeln wir GitHub Actions in Security-Trainings als praktische Angriffs- und Verteidigungsfläche: von fehlerhaften Token-Rechten über gefährliche PR-Auslöser bis zur Absicherung von Build-Umgebungen. Passende Seminare und Termine findest du bei uns auf cmt.de.