GitHub Workflows auf Sicherheitsrisiken prüfen

May 29, 2026 · 6 min read

GitHub Workflows auf Sicherheitsrisiken prüfen

Supply-Chain-Angriffe auf GitHub Actions haben sich von theoretischen Szenarien zu alltäglichen Vorfällen entwickelt. Die Kompromittierung von tj-actions/changed-files im März 2025 zeigte, wie schnell eine einzige manipulierte Action Secrets aus Tausenden von Repositories leaken kann. Ein Jahr später wiederholte sich das Muster beim Trivy-Action-Vorfall, bei dem Angreifer bösartigen Code per Force-Push in 76 von 77 Versions-Tags einschleusten.

Wenn Sie bereits Workflows im Produktionsbetrieb haben, hilft Ihnen diese Checkliste dabei, die häufigsten Schwachstellen zu identifizieren – ohne Ihre gesamte Pipeline neu gestalten zu müssen.

Wichtigste Erkenntnisse

Setzen Sie permissions: {} auf Workflow-Ebene und gewähren Sie jedem Job nur die minimal erforderlichen Berechtigungen.
Interpolieren Sie ${{ github.event.* }}-Werte niemals direkt in Shell-Befehle – übergeben Sie sie stattdessen über Umgebungsvariablen.
Pinnen Sie Actions von Drittanbietern auf vollständige Commit-SHAs und vermeiden Sie die Kombination von pull_request_target mit dem Auschecken von Fork-Code.
Ersetzen Sie statische Cloud-Credentials durch OIDC und verhindern Sie, dass Self-Hosted Runner in öffentlichen Repositories nicht vertrauenswürdigen Code ausführen.

Zuerst die GITHUB_TOKEN-Berechtigungen prüfen

Öffnen Sie eine beliebige Workflow-Datei und suchen Sie nach dem permissions-Block auf oberster Ebene. Fehlt dieser, gelten die Standardeinstellungen Ihrer Organisation – und Organisationen, die vor Februar 2023 erstellt wurden, haben häufig standardmäßig Lese- und Schreibzugriff.

Die Lösung ist unkompliziert:

permissions: {}  # deny all at workflow level

jobs:
  build:
    permissions:
      contents: read  # grant only what the job needs

Das Setzen von permissions: {} auf Workflow-Ebene zwingt Sie dazu, genau festzulegen, was jeder Job benötigt. Ein Job, der lediglich Code liest, sollte niemals einen GITHUB_TOKEN mit Schreibzugriff auf Ihr Repository besitzen.

Nach nicht vertrauenswürdigen Eingaben in Shell-Befehlen suchen

Durchsuchen Sie Ihre Workflow-Dateien nach ${{ github.event innerhalb von run:-Blöcken. Dies ist das häufigste Muster für Script-Injection:

# Riskant: Angreifer kontrolliert den PR-Titel
- run: echo "Checking ${{ github.event.pull_request.title }}"

Die sichere Alternative besteht darin, nicht vertrauenswürdige Werte über eine intermediäre Umgebungsvariable zu übergeben:

- name: Check PR title
  env:
    TITLE: ${{ github.event.pull_request.title }}
  run: echo "Checking $TITLE"

Der Wert wird über die Umgebung übergeben statt direkt in das Shell-Skript interpoliert. Dadurch können Shell-Metazeichen in der Eingabe nicht ausbrechen und Befehle ausführen. Achten Sie außerdem auf Schreibvorgänge in GITHUB_ENV und GITHUB_PATH in Steps, die benutzerkontrollierte Inhalte verarbeiten – Angreifer können diese nutzen, um Umgebungsvariablen oder bösartige Binärdateien in spätere Steps einzuschleusen.

pull_request_target-Verwendung überprüfen

pull_request_target wird mit Zugriff auf Secrets des Basis-Branches ausgeführt, was es für Workflows nützlich macht, die Kommentare zu PRs aus Forks hinterlassen müssen. Das Risiko liegt nicht im Trigger selbst – sondern in der Kombination mit dem Auschecken des Fork-Codes:

# Gefährliche Kombination
on: pull_request_target
jobs:
  test:
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # führt Angreifer-Code aus
      - run: npm test  # mit Zugriff auf Ihre Secrets

Wenn Sie pull_request_target verwenden, stellen Sie sicher, dass kein Step Code aus dem PR-Branch ausführt. GitHub hat dies Ende 2025 teilweise entschärft, aber der Trigger bleibt in Kombination mit Fork-Checkouts ein hohes Risiko.

Pinning von Actions Dritter überprüfen

Die Kompromittierung von tj-actions/changed-files funktionierte, weil Teams auf veränderliche Tags wie @v35 verwiesen. Tag-Werte können stillschweigend überschrieben werden. Das Pinnen auf vollständige Commit-SHAs verhindert dies:

# Anfällig
- uses: tj-actions/changed-files@v35

# Sicher
- uses: tj-actions/changed-files@d6babd6899969df1a11d14c368283ea4436bca78

GitHub bietet inzwischen Richtlinien auf Organisationsebene, um SHA-Pinning durchzusetzen und Workflows mit ungepinnten Actions fehlschlagen zu lassen. Prüfen Sie Settings → Actions → General auf Organisationsebene. Pinning allein ist nicht ausreichend – erwägen Sie zusätzlich eine Wartezeit von 7–14 Tagen, bevor Sie neue Action-Versionen übernehmen, da die meisten Supply-Chain-Kompromittierungen innerhalb einer Woche entdeckt werden.

Exposition von Self-Hosted Runnern bewerten

Self-Hosted Runner sind standardmäßig persistent. Ein kompromittierter Workflow kann Backdoors installieren, die zwischen Jobs bestehen bleiben. Die entscheidende Frage ist, ob öffentliche Repositories Ihre Self-Hosted Runner verwenden – falls ja, kann jeder Contributor einen PR einreichen, der beliebigen Code auf Ihrer Infrastruktur ausführt.

Überprüfen Sie Ihre Runner-Gruppen unter Settings → Actions → Runners und stellen Sie sicher, dass öffentliche Repositories ausgeschlossen sind. Für sicherheitskritische Workloads empfehlen sich Just-in-Time (JIT) Runner, die nach jedem Job zerstört werden.

Langlebige Cloud-Credentials durch OIDC ersetzen

Wenn sich Ihre Workflows bei AWS, Azure oder GCP über statische, als Secrets gespeicherte Credentials authentifizieren, sind diese Credentials für jede Action und jeden Step in diesem Job zugänglich. OpenID Connect (OIDC) beseitigt dieses Problem, indem zur Laufzeit kurzlebige, job-spezifische Tokens ausgestellt werden. Kein Secret, das gestohlen werden könnte, keine Credentials, die manuell rotiert werden müssen.

Weitere empfehlenswerte Prüfungen

Artifact-Handling: Setzen Sie persist-credentials: false bei actions/checkout, sofern nachgelagerte Steps das Token nicht explizit benötigen. Dies verhindert, dass das Checkout-Token in der lokalen Git-Konfiguration für spätere Workflow-Steps verfügbar bleibt.
Umgebungsschutz: Deployment-Secrets sollten in GitHub Environments mit erforderlichen Reviewern gespeichert werden – nicht als einfache Repository-Secrets.
Artifact-Attestierungen: Für veröffentlichte Pakete bieten GitHubs Artifact-Attestierungen eine verifizierbare Verknüpfung zwischen einem Build und seinem Quell-Workflow.
OpenSSF Scorecards: Die Scorecards Action kann so konfiguriert werden, dass automatisierte Prüfungen auf Token-Berechtigungen, gepinnte Actions und Script-Injection durchgeführt werden – nützlich, um Regressionen automatisch zu erkennen.

Wo anfangen

Führen Sie eine Suche in .github/workflows/ nach folgenden Mustern durch: fehlende oder auf write-all gesetzte permissions-Blöcke, ${{ innerhalb von run:-Steps, pull_request_target-Trigger sowie Action-Referenzen ohne vollständige SHA. Diese vier Prüfungen decken die risikoreichsten Probleme in den meisten Repositories auf – ohne dass neue Tools erforderlich sind.

Fazit

Die Absicherung von GitHub Actions erfordert keine vollständige Neuentwicklung der Pipeline – die meisten realen Vorfälle lassen sich auf eine überschaubare Anzahl wiederkehrender Fehler zurückführen: zu weit gefasste Token-Berechtigungen, unsichere Interpolation nicht vertrauenswürdiger Eingaben, veränderliche Action-Referenzen und Runner, die nicht vertrauenswürdigem Code ausgesetzt sind. Die oben beschriebenen Prüfungen verschaffen Ihnen eine solide Sicherheitsbasis. Ergänzen Sie diese Basis durch automatisiertes Scanning mit OpenSSF Scorecards oder vergleichbaren Tools, und Sie erkennen Regressionen, bevor sie den Produktionsbetrieb erreichen.

FAQs

GitHubs Code-Suche unterstützt organisationsweite Abfragen. Suchen Sie nach Begriffen wie 'pull_request_target', 'permissions: write-all' oder 'github.event.pull_request.title', eingeschränkt auf den Pfad '.github/workflows'. Für eine tiefergehende Analyse können Tools wie Octoscan, zizmor und die OpenSSF Scorecards Action gesamte Repositories scannen und automatisch über Token-Berechtigungen, ungepinnte Actions und Injection-Schwachstellen berichten.

Nein, aber es macht Updates explizit. Sie entscheiden selbst, wann Sie die SHA aktualisieren, nachdem Sie die Änderungen zwischen den Versionen geprüft haben. Tools wie Dependabot und Renovate können automatisch Pull Requests öffnen, die gepinnte SHAs aktualisieren – so profitieren Sie von der Sicherheit des Pinnens ohne den Wartungsaufwand. Eine Verzögerung von 7–14 Tagen vor dem Mergen dieser Updates reduziert die Angriffsfläche durch frisch kompromittierte Releases zusätzlich.

Für AWS, Azure, GCP und die meisten großen Anbieter: ja. OIDC-Tokens sind kurzlebig, auf einen bestimmten Workflow-Run beschränkt und können nicht für eine spätere Verwendung exfiltriert werden. Die Einrichtung erfordert die Konfiguration einer Vertrauensbeziehung bei Ihrem Cloud-Anbieter, eliminiert jedoch den Rotationsaufwand und begrenzt den Schaden im Falle einer Workflow-Kompromittierung. Statische Secrets bleiben nur dann eine valide Fallback-Option, wenn OIDC nicht unterstützt wird.

Der pull_request-Trigger wird im Kontext des Forks ausgeführt und hat keinen Zugriff auf Secrets des Basis-Repositories – damit ist er sicher für die Ausführung von Tests auf nicht vertrauenswürdigem Code. Der pull_request_target-Trigger wird im Kontext des Basis-Repositories mit Zugriff auf Secrets ausgeführt und ist für Aufgaben wie das Labeln von PRs vorgesehen. Die gefährliche Kombination, die es zu vermeiden gilt, ist pull_request_target zusammen mit dem Auschecken des Fork-Codes.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.