Die vollständige GitHub Actions Sicherheits-Checkliste

GitHub Actions wurde in letzter Zeit häufig bei vielen Lieferkettenangriffen ausgenutzt, und Workflow-Fehlkonfigurationen haben dabei eine große Rolle gespielt. Es ist gefährlich, allein zu gehen! Nehmen Sie diese (Checkliste).

Warum gibt es so viele Sicherheitsprobleme mit GitHub Actions?

GitHub Actions, das integrierte CI/CD- und Automatisierungssystem von GitHub, hat keine grundsätzlich schwache Sicherheit, bietet aber viele Möglichkeiten, sich selbst ins Knie zu schießen.

Die Plattform funktioniert wie konzipiert, aber die Standardeinstellungen sind im Allgemeinen auf Komfort und Flexibilität ausgelegt, nicht auf Sicherheit. pull_request_target existiert aus einem Grund, und veränderliche Tags sind sicherlich praktisch. Aber diese Designentscheidungen schufen eine Angriffsfläche, die erst später offensichtlich wurde.

GitHub Actions ist auch das Standard-CI/CD-System für die meisten Open-Source-Projekte, und die Übernahme eines Open-Source-Projekts ermöglicht Hackern den Zugang zu den am weitesten nachgelagerten Opfern. Workflows enthalten oft Anmeldeinformationen, die auf npm und PyPI veröffentlichen, sodass ein kompromittierter Workflow eine bösartige Version eines Pakets pushen kann, und jede Entwickelnde, die dieses Paket installiert, erhält es ebenfalls.

Ein weiterer Grund, warum wir immer wieder dieselben Vektoren bei Vorfällen sehen, ist, dass die Angriffsfläche seit Jahren in öffentlichen Forschungsarbeiten gut dokumentiert ist. Angreifer scannen manchmal einfach Repositories nach diesen Fehlkonfigurationen, um einfache Angriffsziele zu finden (siehe prt-scan). GitHub priorisiert im nächsten Jahr stärkere Schutzmaßnahmen, um Nutzer besser zu schützen, aber ein Großteil der Verantwortung liegt immer noch beim Nutzer, GitHub sicher und korrekt einzurichten.

Das Befolgen aller Best Practices macht Ihre Workflows nicht kugelsicher. Auch wenn Sie sich nicht vollständig vor einem kompromittierten Maintainer oder einem Zero-Day in der GitHub-Infrastruktur schützen können, können Sie viele der Vektoren schließen, die Angreifer in letzter Zeit aktiv ausnutzen, und Ihre Repos zu einem schwierigeren Ziel als die meisten anderen machen.

Best Practices, um Ihre GitHub Actions Workflows sicher zu halten

Beginnen Sie hier. Wenn Sie nur fünf Dinge von dieser Checkliste tun:

• Alle Drittanbieter-Aktionen an einen vollständigen Commit-SHA anheften
• Standard festlegen GITHUB_TOKEN Berechtigungen auf schreibgeschützt setzen
• Niemals pull_request_target in öffentlichen Repositories
• Niemals interpolieren ${{ github.* }} direkt in run: Schritte
• OIDC für Cloud-Zugangsdaten anstelle von langlebigen Secrets verwenden

Wir empfehlen Ihnen jedoch, die Checkliste im Detail zu lesen, wo wir alle unsere Sicherheitshinweise für GitHub Actions und deren Notwendigkeit erläutern. Sehen Sie sich auch die Tools am Ende an, die Ihnen helfen, diese Best Practices zu implementieren und durchzusetzen.

Trigger-Konfiguration

1. Verwenden Sie niemals pull_request_target in öffentlichen Repositorys

pull_request_target Es dient dazu, dass durch Fork-PRs ausgelöste Workflows mit Zugriff auf secrets des Basis-Repositorys ausgeführt werden können. Damit können Sie PRs von externen Mitwirkenden automatisch mit Labels versehen oder kommentieren. Die Idee ist gut, doch der Zugriff auf secrets dies gefährlich. Standardmäßig wird der Workflow vom Standardzweig des Basis-Repositorys aus ausgeführt, sodass kein Fork-Code ausgeführt wird, es sei denn, Sie checken ihn explizit aus. In diesem Standardzustand ist der Trigger sicher. Das Risiko entsteht erst durch die Kombination mit einem Checkout des Fork-Codes.

Im Gegensatz zum Standard- pull_request Trigger, pull_request_target wird im Kontext des Basis-Repositorys ausgeführt, unabhängig davon, woher der PR stammt. Jeder kann einen PR für ein öffentliches Repo erstellen. Wenn Ihr Workflow durch diesen PR ausgelöst wird – selbst wenn er nicht zusammengeführt wurde –, werden alle im Workflow secrets referenzierten secrets in die Runner-Umgebung geladen und sind für jeden Code zugänglich, der in diesem Runner ausgeführt wird. Dies wird als „Pwn-Request“ bezeichnet. Das Skript des Angreifers kann diese Geheimnisse ganz einfach mit einer Umgebungsabfrage wie os.environ.get('MY_SECRET') und ohne Spuren zu hinterlassen an einen Angreifer zurücksenden.

Wenn Sie es in einem privaten Repository benötigen, verlangen Sie, dass PRs von erstmaligen Mitwirkenden eine Genehmigung von einem Maintainer erhalten, bevor sie Workflows auslösen können. GitHub unterstützt dies nativ unter Einstellungen > Aktionen > Fork-Pull-Request-Workflows.

Stand: 18. Juni 2026, actions/checkout v7 blockiert standardmäßig gängige Pwn-Anfragen in pull_request_target Workflows, die das Abrufen von Fork-PR-Code verweigern, sofern Sie nicht ausdrücklich festlegen, dass allow-unsafe-pr-checkout: true.

In der Praxis: Der Trivy-Angriff vom März 2026 resultierte aus der Ausnutzung von pull_request_target. Die Ingenieure hielten es für sicher, da es nichts ausführen durfte, aber das war nicht ausreichend. Der PR sendete die Secrets an den Angreifer, der sie nutzte, um sich durch deren Konten zu bewegen. Kurz darauf begann ein Angreifer GitHub zu scannen. speziell für Repositories mit pull_request_target aktiviert und innerhalb eines Tages einige hundert PRs geöffnet.

2. Vermeiden Sie workflow_run in öffentlichen Repositorys

workflow_run ermöglicht das Verketten von Workflows, sodass ein nachgelagerter Workflow ausgelöst wird, wenn ein vorgelagerter abgeschlossen ist. Das Problem ist, dass der nachgelagerte Workflow mit Schreibberechtigungen und Secret-Zugriff ausgeführt wird, unabhängig davon, was den vorgelagerten Workflow ausgelöst hat, einschließlich eines Fork-PRs von einem externen Mitwirkenden.

Wenn ein vorgelagerter pull_request Workflow anfällig für Skript-Injection ist, kann ein Angreifer das Ausgabe-Artefakt über einen PR manipulieren. Der nachgelagerte Workflow konsumiert dann Angreifer-kontrollierten Inhalt in einem privilegierten Kontext mit Secret-Zugriff, sodass Angreifer-kontrollierter Inhalt aus einem nicht vertrauenswürdigen PR nun über einen zusätzlichen Hop einen Workflow mit Secret-Zugriff erreicht hat. Der Angriffspfad ist länger als pull_request_target erreicht aber dasselbe Ziel.

Die beste Lösung ist, dieses Muster zu vermeiden. Wenn ein Deployment nur bei Pushes auf `main` erfolgen soll, lösen Sie es direkt mit einem Push auf `main` aus, anstatt es über workflow_run. workflow_run, prüfen Sie github.event.workflow_run.event bevor Sie privilegierte Aktionen ausführen. Wenn der vorgelagerte Trigger ein pull_request und nicht ein Push von einem Maintainer war, brechen Sie ab, bevor Sie etwas deployen oder schreiben.

jobs:
  deploy:
    if: github.event.workflow_run.event == 'push'

Aikido markiert workflow_run Workflows kennzeichnen, die privilegierte Aktionen ohne die Ereignisprüfung ausführen, wenn Sie eine automatisierte Erkennung über Ihre Repository-Landschaft wünschen.

actions/checkout v7 verhindert außerdem unsichere Fork-PR-Checkouts in workflow_run Workflows, bei denen workflow_run.event ist ein pull_request* Veranstaltung, mit demselben allow-unsafe-pr-checkout: true Abmeldung.

3. Prüfen Sie Workflows, die andere privilegierte Trigger verwenden

Zusätzlich zu pull_request_target und workflow_run, achten Sie auf andere Trigger, die mit Zugriff auf Secrets ausgeführt werden. Dazu gehören issue_comment, issues, pull_request_review, und pull_request_review_comment. Da sie alle mit Secret-Zugriff ausgeführt werden, können sie von externen Mitwirkenden beeinflusst werden. Es gelten dieselben Regeln für Skript-Injections, nämlich niemals Werte aus diesen Ereignissen direkt in run: steps. Mehr dazu im nächsten Abschnitt.

4. Verhindern Sie, dass Fork-Workflows in den Cache Ihres Standard-Branches schreiben

Workflows, die ausgelöst werden durch pull_request_target und workflow_run Beide haben Schreibzugriff auf den Cache, der mit dem Standardzweig geteilt wird. Ein Mitwirkender, der eines dieser Ereignisse auslösen kann, kann diesen Cache manipulieren und Daten einspeisen, die nachfolgende, nicht damit in Zusammenhang stehende Workflows beeinflussen, die auf dem Standardzweig ausgeführt werden. Überprüfen Sie, was diese Workflows zwischenspeichern und verbrauchen, und vermeiden Sie es, zwischengespeicherte Daten aus privilegierten, forkübergreifenden Ausführungen als Eingabe für sensible Schritte zu verwenden.

Umgang mit nicht vertrauenswürdigen Eingaben

5. Verhindern Sie Skript-Injektionen, indem Sie alle Zweignamen, PR-Titel, Commit-Meldungen und Issue-Inhalte als nicht vertrauenswürdige Eingaben behandeln

Dies ist dasselbe Prinzip wie bei SQL-Injection. Benutzergesteuerte Werte, die in einem Shell-Befehl landen, werden als Code und nicht als Daten interpretiert, daher niemals interpolieren github.* Werte direkt in run: steps. Die Lösung besteht darin, den Wert zuerst einer Umgebungsvariablen zuzuweisen und diese Variable dann im Shell-Skript zu referenzieren:

# vulnerable
- run: echo "Branch is ${{ github.head_ref }}"

# safe
- run: echo "Branch is $BRANCH"
  env:
    BRANCH: ${{ github.head_ref }}

Wenn der Wert einer Umgebungsvariablen zugewiesen wird, liest die Shell ihn zur Laufzeit als String, anstatt ihn zur Parse-Zeit als Syntax zu interpretieren. Dies gilt für alles, was aus benutzergesteuerten Eingaben stammt: github.head_ref, github.event.pull_request.title, github.event.issue.body, github.event.commits[0].message, und ähnliche Kontextwerte. Ein guter SAST-Scanner wie Aikido wird dies erkennen und den Fix in einem Pull Request bereitstellen.

In der Praxis: Bei dem Ultralytics-Angriff, benannte ein Angreifer einen Branch mit einem curl-Befehl, den ein Workflow direkt in einen run: step, der als Code ausgeführt wurde. Der Nx/s1ngularity-Angriff, zuerst von Aikido Security entdeckt, kombinierte dies mit pull_request_target, wobei ein PR an einen veralteten Branch einen anfälligen Workflow auslöste, der ein GITHUB_TOKEN mit Lese-/Schreibberechtigungen, das dann verwendet wurde, um bösartige npm-Pakete zu veröffentlichen.

6. Verwenden Sie für KI-Agenten in benutzerdefinierten Workflows schreibgeschützte Tokens und nehmen Sie die Rohdaten der Benutzereingaben nicht in die Prompts auf.

AI-Agenten, die in GitHub Actions Workflows ausgeführt werden, haben denselben Secret-Zugriff wie jeder andere Step. Wenn ein Agent Issue-Titel, PR-Beschreibungen oder Commit-Nachrichten als Teil seines Prompts verarbeitet, kann ein Angreifer Anweisungen in diesen Text einfügen und den Agenten dazu manipulieren, privilegierte Aktionen auszuführen, wie das Modifizieren von Dateien oder das Exfiltrieren von Daten über alle Tools, auf die er zugreifen kann. Da es keine Möglichkeit gibt, Prompt Injection in LLMs zu verhindern, sollten AI-Agenten keinen Zugriff über das Lesen hinaus haben und es sollte ihnen nicht erlaubt sein, rohe Issue-Titel, PR-Beschreibungen oder Commit-Nachrichten als Prompt-Eingabe zu erhalten.

In der Praxis: Aikido-Forscher demonstrierten dies mit PromptPwnd: ein bösartiger Issue-Titel, der in einen Gemini CLI-Workflow eingespeist wurde, veranlasste den Agenten, Repository-Secrets in einen öffentlichen Issue-Thread zu schreiben, indem er seinen eigenen gh Tool-Zugriff nutzte.

7. Von LLM generierte Ergebnisse als nicht vertrauenswürdige Eingaben behandeln

Wenn ein Workflow ein LLM verwendet, um einen Befehl, ein Skript oder einen Dateipfad zu generieren und diese Ausgabe direkt an einen run: Schritt übergibt, entsteht dasselbe Injektionsrisiko wie beim Interpolieren eines Branch-Namens oder PR-Titels. Die LLM-Ausgabe ist nicht garantiert sicher, und ein Angreifer, der den Prompt beeinflussen kann, kann auch beeinflussen, was ausgeführt wird. Wie wir im vorherigen Punkt zur Prompt-Injection besprochen haben, weisen Sie die LLM-Ausgabe zuerst einer Umgebungsvariablen zu, validieren Sie sie, wo immer möglich, und leiten Sie sie niemals direkt in einen Shell-Befehl.

8. Schreibe niemals nicht vertrauenswürdige Daten in GITHUB_ENV oder GITHUB_PATH

Das Schreiben in GITHUB_ENV setzt Umgebungsvariablen für alle nachfolgenden Schritte im Job. Das Schreiben in GITHUB_PATH fügt Einträge dem System-PATH für alle nachfolgenden Schritte hinzu. Wenn nicht vertrauenswürdiger Inhalt eine dieser Dateien erreicht, kann ein Angreifer beliebige Umgebungsvariablen setzen, wie z.B. NODE_OPTIONS , die die Code-Ausführung auslösen. Sie könnten auch ein Malware-Binary am Anfang des PATHs injizieren, das anstelle eines vertrauenswürdigen Tools aufgerufen wird. Das anfällige Muster ist ein Workflow, der ein Artefakt herunterlädt oder benutzergesteuerte Eingaben liest und diese direkt in $GITHUB_ENV ohne Sanitization schreibt. Behandeln Sie alles, was in diese Dateien geschrieben wird, mit der gleichen Vorsicht wie einen run: Schritt.

Artefakt-Handhabung

9. Entpacken Sie die Artefakte in ein temporäres Verzeichnis, z. B. /tmp , anstatt in den Workspace, um das Überschreiben von Workflow-Dateien zu vermeiden

Das direkte Extrahieren eines Artefakts in den Workspace könnte es einem Archiv mit bösartigem Inhalt ermöglichen, Workflow-Dateien, Skripte oder Tools zu überschreiben, von denen nachfolgende Schritte abhängen. Das Extrahieren in /tmp oder ein anderes isoliertes Verzeichnis hält Artefaktinhalte von allem fern, was Ihr Workflow als vertrauenswürdig behandelt. GitHub unterstützt auch die SHA256-Digest-Verifizierung , wenn Sie stärkere Integritätsgarantien benötigen.

10. Geheime Dateien ausschließen (.env, Konfigurationsdateien, Anmeldeinformationen) aus hochgeladenen Artefakten und vermeiden Sie path: . Muster, die alles erfassen

Der path: . Muster in einem actions/upload-artifact Schritt lädt alles im Arbeitsverzeichnis hoch, was Folgendes umfassen kann: .env Dateien, Konfigurationsdateien mit eingebetteten Anmeldeinformationen oder zwischengespeicherte Secrets, die von anderen Schritten auf die Festplatte geschrieben wurden. Seien Sie explizit darüber, was Sie hochladen, um Ihre Anmeldeinformationen nicht versehentlich im Internet zu veröffentlichen. Listen Sie spezifische Verzeichnisse oder Dateitypen auf, anstatt den gesamten Arbeitsbereich zu erfassen, und fügen Sie .env, *.pem, und ähnliche Dateien zu Ihren .gitignore und Artefakt-Ausschlussmustern hinzu.

Veränderliche Action-Referenzen

11. Verknüpfen Sie alle Aktionen von Drittanbietern mit einem vollständigen Commit-SHA, nicht mit einem Tag oder einem Branch.

Tags sind als Kurzform nützlich, der Nachteil ist jedoch, dass sie nicht statisch sind. Tags und Branches sind veränderlich, was bedeutet, dass ein Repo-Besitzer sie jederzeit auf einen anderen Commit umleiten kann, und dies wird bei Tags wie @main. Beim Referenzieren einer spezifischen Version mit uses: some-action@v3, erwarten wir, dass der Commit derselbe bleibt. Wenn jedoch das Konto des Action-Maintainers kompromittiert wird, kann ein Angreifer diesen Tag auf einen bösartigen Commit umleiten, und jeder nachgeschaltete Workflow übernimmt diesen beim nächsten Lauf ohne einen PR oder andere Anzeichen. Um dies zu verhindern, ist es Best Practice, stattdessen an den vollständigen Commit-SHA zu pinnen: uses: some-action@abc123def456..... Dies kann natürlich etwas lästig sein, daher können Sie Dependabot, Renovate oder pinact verwenden, um gepinnte SHAs auf dem neuesten Stand zu halten. Native Lockfiles sind in der GHA-Roadmap, daher ist es hoffentlich bis 2027 verfügbar.

In der Praxis: Im März 2025 leiteten Angreifer 76 von 77 Versionstags in aquasecurity/trivy-action auf bösartige Commits um, die einen Infostealer enthielten. Jeder Workflow, der diese Tags namentlich referenzierte, zog den bösartigen Code automatisch ein.

12. Maßnahmen Dritter vor der Übernahme prüfen

Bevor Sie eine uses: Zeile hinzufügen, verbringen Sie zwei Minuten im Repo der Action. Prüfen Sie, ob der Ersteller GitHub-verifiziert ist, wann das Repo zuletzt gewartet wurde, wie viele Mitwirkende es hat und wie hoch der OpenSSF Scorecard-Wert ist. Eine weit verbreitete Action von einem nicht verifizierten einzelnen Maintainer ohne aktuelle Aktivität ist ein hochwertiges Ziel für eine Kontoübernahme.

13. Bevorzugen Sie Aktionen mit weniger transitiven Abhängigkeiten

Mehr Abhängigkeiten machen Sie anfälliger für Lieferkettenangriffe. Wählen Sie daher, wenn möglich, Aktionen mit weniger Abhängigkeiten. Eine Aktion kann selbst andere Aktionen referenzieren, und diese transitiven Abhängigkeiten werden zur Laufzeit aufgelöst. Das SHA-Pinning Ihrer direkten Abhängigkeit schützt Sie nicht, wenn diese ihre eigenen Abhängigkeiten mutabel einbindet.

In der Praxis: Der tj-actions Kompromittierung verbreitete sich teilweise durch diesen Mechanismus. Nachgelagerte Workflows waren an tj-actions/changed-files, aber changed-files transitiv referenzierte reviewdog/action-setup über einen mutablen Tag, sodass, als reviewdog kompromittiert wurde, jede nachgelagerte Pipeline den bösartigen Code ausführte.

Mutable Paketabhängigkeiten

14. Die Versionen der npm- und PyPI-Pakete explizit festlegen

Floating-Versionsbereiche wie ^1.2.0 oder >=2.0.0 bedeuten, dass Ihr Workflow zur Laufzeit die neueste passende Version installiert. Wenn ein Paket kompromittiert wird und eine neue bösartige Version innerhalb Ihres Bereichs veröffentlicht wird, zieht Ihr Workflow diese beim nächsten Lauf automatisch ein. Pinnen Sie auf exakte Versionen (1.2.3), damit Ihr Workflow nur das installiert, was Sie explizit ausgewählt haben. Verwenden Sie keine Versionsbereiche.

In der Praxis: Der Ultralytics-Angriff zeigte, wie eine kompromittierte Paketversion, die auf PyPI veröffentlicht wurde, Workflows erreichen kann, die nicht gepinnt sind. Die erste bösartige Veröffentlichung war stundenlang live, bevor sie entdeckt wurde, lang genug, um Builds zu beeinträchtigen, die Floating-Abhängigkeiten einziehen.

15. Legen Sie ein Mindestalter für die Veröffentlichung fest, sofern Ihr Paketmanager dies unterstützt (pnpm, yarn)

Selbst bei gepinnten Versionen kann ein neu veröffentlichtes bösartiges Paket eine exakte Version haben, auf die Sie später upgraden möchten. Einstellungen für das Mindestalter von Veröffentlichungen weisen Ihren Paketmanager an, Pakete abzulehnen, die vor weniger als einer bestimmten Zeit (typischerweise 72 Stunden) veröffentlicht wurden. Dies gibt der Community Zeit, bösartige Veröffentlichungen zu erkennen und zu melden, bevor sie Ihre Builds erreichen. pnpm und yarn unterstützen dies nativ, npm jedoch noch nicht. Aikido Safe Chain kann dies für npm abdecken (siehe unten).

16. Überprüfen Sie die Herkunft der Pakete anhand von Bescheinigungen, sofern diese verfügbar sind

Einige Paket-Registries unterstützen jetzt Provenienz-Attestierungen, kryptografische Aufzeichnungen, die ein veröffentlichtes Paket mit dem spezifischen Quell-Commit und der Build-Pipeline verknüpfen, die es erzeugt haben. Das Verifizieren von Attestierungen vor der Installation eines Pakets bestätigt, dass es aus der beanspruchten Quelle erstellt wurde. npm unterstützt dies für Pakete, die über GitHub Actions veröffentlicht werden. Dies ist noch eine neuere Praxis, und die Tooling-Unterstützung ist noch nicht vollständig vorhanden, aber es lohnt sich, dies zu aktivieren, wo Ihre Registry und Ihr Paketmanager es unterstützen.

Secrets-Handhabung

17. Verweise auf secrets Umgebungsvariablen, niemals über Befehlszeilenargumente

Kommandozeilenargumente sind in Prozesslisten sichtbar, sodass andere Prozesse auf dem Runner mit Zugriff auf /proc diese lesen können. Die Übergabe eines Secrets als Umgebungsvariable hält es aus der Prozesstabelle fern. Legen Sie in Ihrem Workflow das Secret in einem env: Block fest und referenzieren Sie $SECRET_NAME im Shell-Befehl anstatt ${{ secrets.MY_SECRET }} inline.

In der Praxis: tj-actions exfiltrierte Secrets, indem sie diese im Log ausgaben (das Echo-/Maskierungs-Problem), und der Trivy-Angriff führte zu einem gestohlenen PAT. Beim Umgang mit Secrets geht es darum, den Zugriff auf Secrets im gesamten System zu begrenzen, damit im Falle eines Fehlers ein Angreifer keine funktionierenden Anmeldeinformationen entwenden kann.

18. Beschränken Sie secrets Repo-Ebene nach Möglichkeit auf bestimmte GitHub-Umgebungen.

GitHub Environments ermöglichen es, Secrets hinter Deployment-Schutzregeln zu verbergen, sodass ein Secret wie PROD_DB_PASSWORD nur für Workflows zugänglich ist, die auf die Produktionsumgebung abzielen. Ohne dies kann jeder Workflow im Repository jedes Secret auf Repository-Ebene lesen. Sie können dies unter Einstellungen > Environments einrichten.

19. Definieren Sie secrets Workflow auf Schritt-Ebene und nicht auf Job-Ebene

Die Beschränkung von Secrets auf die einzelnen Schritte eines Jobs, die diese benötigen, wendet das Prinzip der geringsten Rechte an, um den potenziellen Schaden zu begrenzen, falls eine Aktion kompromittiert wird. Ein Secret, das in einem Job-Level- env: Block deklariert ist, ist für jeden Schritt in diesem Job lesbar, einschließlich Drittanbieter-Aktionen.

In der Praxis: Beim Shai-Hulud attack wurden Tokens mit Workflow-Scope über mehrere Opfer hinweg wiederverwendet. Ein engerer Scope hätte den potenziellen Schaden eingedämmt.

20. Verwenden Sie OIDC, um kurzlebige Cloud-Anmeldedaten anstelle von langlebigen statischen secrets zu erhalten, secrets der Cloud-Anbieter dies unterstützt (AWS, Azure, GCP)

Statische Cloud-Anmeldeinformationen, die als GitHub Secrets gespeichert sind, sind unbegrenzt gültig, sodass im Falle eines Diebstahls das Fenster für Schäden weit offen steht. OIDC ermöglicht es Ihrem Workflow, direkt einen kurzlebigen Token von AWS, Azure oder GCP anzufordern, der auf den Job beschränkt und nur für Minuten gültig ist, sodass keine Anmeldeinformationen für einen Angreifer zum Stehlen vorhanden sind. AWS, Azure und GCP unterstützen dies alle nativ. Die Einrichtung erfordert die Konfiguration einer Vertrauensbeziehung zwischen Ihrem Cloud-Anbieter und GitHubs OIDC-Endpunkt.

21. Beschränken Sie die Regeln für vertrauenswürdige npm-Publisher auf eine bestimmte Workflow-Datei und einen geschützten Zweig, nicht auf das gesamte Repository.

In den Trusted Publishing-Einstellungen von npm geben Sie den genauen Workflow-Dateinamen an (z.B. release.yml) und Branch (z.B. Haupt) anstatt dem gesamten Repo zu vertrauen. Kombinieren Sie dies mit Branch-Schutzregeln, die PRs erfordern und Force Pushes blockieren, sodass kein Workflow außerhalb dieses Pfades ein Publish-Token anfordern kann.

In der Praxis: Beim Mini Shai-Hulud TanStack-Angriff im Mai 2026 pushte ein Angreifer einen verwaisten Commit ohne übergeordnete Historie in das TanStack/router-Repo. Da die npm Trusted Publisher-Regel dem gesamten Repository vertraute, anstatt einem spezifischen Workflow auf einem geschützten Branch, löste der Commit einen Workflow aus, der erfolgreich ein Publish-Token prägte. Der Angreifer nutzte es, um innerhalb von sechs Minuten bösartige Versionen von 84 Paketen im gesamten TanStack-Ökosystem zu veröffentlichen.

22. Für Workflow-Ausführungen, die Produktionsumgebungen nutzen, eine manuelle Genehmigung vorschreiben

Konfigurieren Sie Ihre GitHub Environment so, dass eine Überprüfung eines Workflows erforderlich ist, bevor dieser auf die Secrets einer Umgebung zugreifen oder dorthin deployen kann. Dies ist realistischer für kleinere Teams oder solche, die selten deployen. Für größere Teams ist die skalierbarere Version davon OIDC mit kurzlebigen Anmeldeinformationen.

23. Vermeiden Sie es, geheime Werte auszugeben oder zu protokollieren, auch in der Debug-Ausgabe.

GitHub maskiert bekannte Secret-Werte in Logs, aber nur bei exakten Übereinstimmungen. Wenn also ein Secret base64-kodiert oder über zwei Echo-Aufrufe aufgeteilt wird, funktioniert die Maskierung nicht. Die sicherste Regel ist, Secrets überhaupt niemals auszugeben. Wenn Sie überprüfen müssen, ob ein Secret gesetzt ist, prüfen Sie auf einen nicht-leeren String, anstatt den Wert auszugeben.

Runner

24. Verwenden Sie keine selbst gehosteten Runner in öffentlichen Repos

Jeder kann einen Pull Request (PR) für ein öffentliches Repository öffnen, was bedeutet, dass jeder potenziell einen Workflow-Lauf auslösen kann. GitHubs Standard-Genehmigungseinstellungen für Erstbeitragende mindern dies bei GitHub-gehosteten Runnern, wo die Umgebung ohnehin kurzlebig und isoliert ist. Auf einem selbstgehosteten Runner bedeutet eine falsch konfigurierte oder übermäßig permissive Genehmigungseinstellung, dass derselbe PR Codeausführung auf Ihrer Infrastruktur auslöst. GitHub empfiehlt die Verwendung von GitHub-gehosteten Runnern für öffentliche Repositories und die Genehmigungsrichtlinie zu verschärfen auf „Genehmigung für alle externen Mitwirkenden erforderlich“.

In der Praxis: Forscher führten einen Supply-Chain-Angriff auf PyTorch aus, indem sie einen trivialen PR einreichten, der einen Workflow auf einem selbstgehosteten Runner auslöste und Root-Zugriff auf die Maschine erlangte.

25. Verwenden Sie kurzlebige Runner anstelle von statischen, dauerhaften Runners

Ein statischer Runner behält den Zustand zwischen Jobs bei, was bedeutet, dass ein kompromittierter Job bösartige Dateien, modifizierte Binärdateien oder manipulierte Caches hinterlassen kann, die nachfolgende Ausführungen auf dieser Maschine beeinträchtigen. Ephemere Runner starten sauber und werden nach jedem Job zerstört. Verwenden Sie den Actions Runner Controller für Kubernetes-basierte Setups oder übergeben Sie das --ephemeral Flag, wenn Sie einen Runner manuell registrieren.

In der Praxis: Shai-Hulud registrierte persistente selbstgehostete Runner in kompromittierten Repos und nutzte sie als persistenten C2-Kanal, der für die Netzwerküberwachung unsichtbar war, da der gesamte Datenverkehr über github.com floss.

26. Den ausgehenden Datenverkehr des Runner-Netzwerks auf eine Zulassungsliste beschränken

Die wertvollste Aktion eines kompromittierten Workflows ist oft die Exfiltration von Secrets an einen vom Angreifer kontrollierten Server. Das Beschränken des ausgehenden Netzwerkzugriffs auf nur die Domains, die Ihr Workflow tatsächlich benötigt, erschwert dies erheblich. Harden-Runner und bullfrog funktionieren beide auf GitHub-gehosteten Runnern. Für selbstgehostete Runner erreichen Firewall-Regeln auf Netzwerkebene dasselbe.

Wenn Sie GitHub Enterprise mit selbstgehosteten Runnern verwenden, bieten Token-IP-Positivlisten eine Kontrolle in die andere Richtung. Dies schränkt ein, welche IPs überhaupt ein Token verwenden können, sodass ein gestohlenes Token nicht von der Infrastruktur eines Angreifers verwendet werden kann.

Token-Berechtigungen

27. Als Standard festlegen GITHUB_TOKEN Berechtigungen auf Organisationsebene oder Repository-Ebene auf Nur-Lese-Zugriff setzen

Der GITHUB_TOKEN Es ist in jeder Workflow-Ausführung automatisch verfügbar. Standardmäßig verfügt es über umfassende Lese- und Schreibzugriffe im gesamten Repository, sodass jeder kompromittierte Workflow in Ihr Repo schreiben, Releases erstellen oder PRs genehmigen kann. Setzen Sie die Standardeinstellung unter Einstellungen > Aktionen > Allgemein auf Nur-Lese-Zugriff und erteilen Sie Schreibberechtigungen explizit nur dort, wo sie benötigt werden.

28. Explizit deklarieren permissions: Blöcke auf Workflow- oder Job-Ebene deklarieren, um einzelne Jobs einzuschränken

Das Setzen einer Nur-Lese-Standardeinstellung auf Organisationsebene erstellt die Standardeinstellung, aber einige Jobs benötigen natürlich mehr Berechtigungen. Wenn ein Job erhöhte Zugriffsrechte benötigt, deklarieren Sie einen permissions: Block auf Job-Ebene statt auf Workflow-Ebene. Auf diese Weise ist das Token mit erhöhten Rechten nur auf diesen Job beschränkt, und jeder andere Job im Workflow bleibt Nur-Lese-Zugriff.

jobs:
  deploy:
    permissions:
      contents: read
      id-token: write

In der Praxis: Die Angriffe auf tj-actions, Trivy und prt-scan profitierten alle davon, dass Tokens mehr Zugriffsrechte hatten, als nötig waren. Eine Verschärfung der Token-Berechtigungen reduziert den potenziellen Schaden (Blast Radius) in allen Bereichen.

Organisations- und Repo-Einstellungen

29. Die Möglichkeit deaktivieren, dass „Actions“ PRs genehmigen können

. Dies bedeutet, dass ein kompromittierter Workflow seine eigenen bösartigen Änderungen genehmigen könnte, ohne einen Überprüfungsprozess zu durchlaufen. GITHUB_TOKENStandardmäßig erlaubt GitHub Workflows, Pull Requests mithilfe des. Dies bedeutet, dass ein kompromittierter Workflow seine eigenen bösartigen Änderungen genehmigen könnte, ohne einen Überprüfungsprozess zu durchlaufen. Deaktivieren Sie dies unter Einstellungen > Aktionen > Allgemein > „GitHub Actions das Erstellen und Genehmigen von Pull Requests erlauben.“ (Einige Teams lassen dies für Dependabot Auto-Merge aktiviert, aber es ist besser, Dependabot ein dediziertes Bot-Konto mit expliziten Prüferberechtigungen zu geben, anstatt die Workflow-Genehmigung für die gesamte Organisation zu aktivieren.)

30. Aktionsquellen auf verifizierte Ersteller oder bestimmte Repos beschränken

Die Standardeinstellung in GitHub erlaubt die Verwendung jeder im GitHub Marketplace veröffentlichten Action in Ihren Workflows. Das Beschränken der Quellen auf verifizierte Ersteller oder eine spezifische Positivliste bedeutet, dass eine neu veröffentlichte bösartige Action nicht ohne explizite Genehmigung in Ihre Workflows übernommen werden kann. Stattdessen sollten Entwickelnde die Genehmigung von demjenigen anfordern, der Ihre GitHub-Org-Einstellungen besitzt (normalerweise das Plattform- oder DevOps-Team), der sie zur Positivliste hinzufügen kann. Konfigurieren Sie dies unter Einstellungen > Aktionen > Allgemein > „Actions und wiederverwendbare Workflows erlauben.“

In der Praxis: Die tj-actions-Kompromittierung betraf 23.000 Repos, teilweise weil Teams keine Beschränkung hatten, welche Actions sie einbinden konnten.

31. Überwachen Sie Ihre Organisation auf unerwartete Registrierungen von selbst gehosteten Runners und neu erstellte öffentliche Repositories.

Ein gestohlenes Token ermöglicht es einem Angreifer, einen bösartigen Runner zu registrieren, um eine persistente Backdoor zu platzieren. Angreifer erstellen auch routinemäßig öffentliche Repositories, um gestohlene Anmeldeinformationen abzulegen. Sowohl die Registrierung von Runnern als auch die Erstellung von Repositories sind Ereignisse, die Ihr Team sofort sehen muss, aber GitHub warnt standardmäßig nicht davor. Der Workaround besteht darin, dies manuell zu überwachen. Streamen Sie das Audit-Log Ihrer Organisation an ein SIEM und lassen Sie sich warnen bei self_hosted_runners.register Ereignissen und Repository-Erstellung. Ohne ein SIEM können Sie das Audit-Log über die GitHub API abfragen oder manuell unter Einstellungen > Audit-Log überprüfen.

In der Praxis: Bei dem Shai-Hulud-Angriff wurden kompromittierte Maschinen als selbstgehostete Runner mit dem Namen SHA1HULUD registriert, und gestohlene Anmeldeinformationen wurden verwendet, um öffentliche Repositories als Exfiltrations-Buckets zu erstellen. Die Überwachung beider hätte die Kampagne frühzeitig erkannt.

32. Verwenden Sie „CODEOWNERS“, um eine sicherheitsbewusste Überprüfung von Änderungen an .github/workflows/

Workflow-Dateien sind Code, der mit Zugriff auf Ihre Secrets und Tokens ausgeführt wird. Ohne explizite Eigentumsregeln kann jede Entwickelnde mit Schreibzugriff auf das Repository einen Workflow ändern und ohne Sicherheitsüberprüfung mergen. Fügen Sie einen CODEOWNERS-Eintrag hinzu, der auf .github/workflows/ eine überprüfende Person oder ein Team verweist, das die Sicherheitsaspekte versteht, und kombinieren Sie dies mit Branch-Protection-Regeln, die eine CODEOWNERS-Genehmigung vor dem Merge erfordern.

33. Einschränken oder deaktivieren pull_request_target auf Organisations- oder Repo-Ebene, falls du es nicht benötigst

Mit den Schutzmaßnahmen für die Ausführung von Workflows auf GitHub können Administratoren verhindern, dass bestimmte Ereignisse Workflows in einem Repository oder einer Organisation auslösen. Wenn keines Ihrer Repositories pull_request_target… ist es besser, das Ereignis vollständig zu entfernen, als sich darauf zu verlassen, dass jeder einzelne Workflow-Ersteller es sicher einsetzt. Konfigurieren Sie dies in den Einstellungen für den Schutz bei der Workflow-Ausführung für Ihr Repo oder Ihre Organisation. Bei Repos, die diese Funktion benötigen, können Sie über dieselben Einstellungen einschränken, welche Akteure das Ereignis auslösen dürfen.

Schützen Sie GitHub Actions Workflows mit Aikido

Aikido erkennt unsichere GitHub Actions Workflows und hilft Entwickelnden, diese zu beheben, bevor sie ausgenutzt werden.

Es erkennt Probleme wie:

• Unsichere Verwendung von pull_request_target
• Script-Injection durch nicht vertrauenswürdige github.* Eingaben
• Template- und Prompt-Injection in KI-gestützten Workflows
• Ungepinnte Drittanbieter-Aktionen
• Überprivilegierte GITHUB_TOKEN Berechtigungen
• Risikobehafteter Umgang mit Secrets in Workflows

Aikido kann außerdem:

• Automatisch Fix-PRs erstellen
• Unsichere Workflow-Muster repositoryübergreifend erkennen
• Veränderliche GitHub Action-Referenzen kennzeichnen, die an einen vollständigen Commit-SHA gepinnt werden sollten

Aikido Safe Chain hilft, Paketinstallationen zu schützen, indem es:

• Bekannte bösartige npm- und PyPI-Pakete blockiert
• Mindestalter-Richtlinien für Pakete durchsetzt

Zum Beispiel erkennt Aikido unsanitisierte Benutzereingaben in run: Schritten und schlägt automatisch das sicherere Umgebungsvariablenmuster vor.

Hier kostenlos starten.

Sie sind bereit, GitHub Actions-Workflows zu sichern

Halten Sie diese Checkliste griffbereit, während Sie an der Sicherung von GitHub Actions Workflows arbeiten. Versuchen Sie, die Punkte, die Sie in wenigen Minuten erledigen können, bald einzurichten, und teilen Sie dies mit Ihren Teamkollegen, damit alle mit den Änderungen einverstanden sind.

‍FAQ: GitHub Actions-Sicherheit

Was ist die häufigste Methode, wie GitHub Actions Workflows ausgenutzt werden?

​Skript-Injection ist der häufigste Vektor. Angreifer platzieren bösartigen Code in Branch-Namen, PR-Titeln oder Issue-Bodies, und Workflows, die diese Werte direkt in run: Schritte ausführen sie als Shell-Befehle. Das Anheften von Actions an Commit-SHAs und die Verwendung von Umgebungsvariablen anstelle von Inline-Interpolation schließt den Großteil dieser Angriffsfläche.

Was ist pull_request_target und warum ist es gefährlich?

​pull_request_target ist ein Workflow-Trigger, der mit Zugriff auf die Secrets des Basis-Repositorys ausgeführt wird, selbst wenn der auslösende PR von einem Fork stammt. Da jeder einen PR gegen ein öffentliches Repository öffnen kann, macht jeder Workflow, der diesen Trigger verwendet, seine Secrets externen Mitwirkenden zugänglich. Vermeiden Sie ihn vollständig in öffentlichen Repositorys.

Was bedeutet „Actions an einen Commit-SHA anheften“ und warum ist das wichtig?

​Die meisten Workflows referenzieren Drittanbieter-Actions über Tags, wie uses: some-action@v3. Tags sind veränderlich, wenn also das Konto eines Action-Maintainers kompromittiert wird, kann ein Angreifer diesen Tag stillschweigend auf bösartigen Code umleiten. Das Anheften an einen vollständigen Commit-SHA wie uses: some-action@abc123... bedeutet, dass Ihr Workflow immer genau das ausführt, was Sie überprüft haben.

Sollte ich selbst gehostete Runner in öffentlichen Repositorys verwenden?

‍Nein. Jeder kann einen PR gegen ein öffentliches Repository öffnen und einen Workflow auslösen. Auf GitHub-gehosteten Runnern ist das handhabbar, da die Umgebung ephemer und isoliert ist. Bei einem selbst gehosteten Runner bedeutet eine falsch konfigurierte Genehmigungsrichtlinie, dass externe Mitwirkende Code direkt auf Ihrer Infrastruktur ausführen können.

Was ist OIDC und warum ist es besser, als Cloud-Anmeldeinformationen als Secrets zu speichern?

‍Statische Anmeldeinformationen, die als GitHub Secrets gespeichert sind, sind unbegrenzt gültig, sodass ein gestohlenes Secret lange nach der Kompromittierung gefährlich bleibt. OIDC ermöglicht es Ihrem Workflow, ein kurzlebiges Token von AWS, Azure oder GCP anzufordern, das auf diesen spezifischen Job zugeschnitten und nur wenige Minuten gültig ist. Es gibt keine langlebigen Anmeldeinformationen zu stehlen.

​