GitHub Actions wurde Lieferkettenangriffe bei vielen Lieferkettenangriffe ausgenutzt, wobei Fehlkonfigurationen von Workflows eine große Rolle gespielt haben. Es ist gefährlich, auf sich allein gestellt zu sein! Nutze diese (Checkliste).
Warum gibt es bei GitHub Actions so viele Sicherheitsprobleme?
GitHub Actions, das in GitHub integrierte CI/CD- und Automatisierungssystem, weist zwar keine grundsätzlichen Sicherheitsmängel auf, bietet aber durchaus zahlreiche Möglichkeiten, sich selbst ins Knie zu schießen.
Die Plattform funktioniert wie vorgesehen, doch die Standardeinstellungen sind in der Regel auf Komfort und Flexibilität ausgelegt, nicht auf Sicherheit. pull_request_target Es gibt einen Grund dafür, und veränderbare Tags sind zweifellos praktisch. Doch diese Designentscheidungen schufen eine Angriffsfläche, die erst später offensichtlich wurde.
GitHub Actions ist zudem das Standard-CI/CD-System für die meisten Open-Source-Projekte, und die Übernahme eines Open-Source-Projekts verschafft Hackern Zugang zu den am stärksten betroffenen Opfern. Workflows enthalten oft Anmeldedaten für die Veröffentlichung auf npm und PyPI, sodass ein kompromittierter Workflow eine schädliche Version eines Pakets veröffentlichen kann, die dann auch jeder Entwickler erhält, der dieses Paket installiert.
Ein weiterer Grund dafür, dass bei Vorfällen immer wieder dieselben Angriffsvektoren auftauchen, ist, dass die Angriffsfläche seit Jahren in öffentlichen Forschungsarbeiten gut dokumentiert ist. Angreifer durchsuchen manchmal einfach Repositorys nach solchen Fehlkonfigurationen, um einfache Angriffsziele zu finden (siehe prt-scan). GitHub wird im kommenden Jahr den Schwerpunkt auf stärkere Schutzmaßnahmen legen, um die Nutzer besser zu schützen, doch ein Großteil der Verantwortung liegt nach wie vor beim Nutzer selbst, GitHub sicher und korrekt einzurichten.
Auch wenn Sie alle Best Practices befolgen, sind Ihre Arbeitsabläufe dadurch nicht absolut sicher. Zwar können Sie sich nicht vollständig vor einem kompromittierten Betreuer oder einer Zero-Day-Sicherheitslücke in der GitHub-Infrastruktur schützen, doch können Sie viele der Angriffsvektoren schließen, die Angreifer in letzter Zeit aktiv ausnutzen, und Ihre Repos damit zu einem schwereren Ziel machen als die meisten anderen.
Bewährte Verfahren für die Sicherheit Ihrer GitHub-Actions-Workflows
Fangen Sie hier an. Wenn Sie nur fünf Punkte aus dieser Checkliste erledigen:
- Alle Aktionen von Drittanbietern an einen vollständigen Commit-SHA binden
- Als Standard festlegen
GITHUB_TOKENRechte auf „Nur Lesen“ - Niemals
pull_request_targetin öffentlichen Repositorien - Niemals interpolieren
${{ github.* }}direkt inAusführen:Schritte - Verwenden Sie OIDC für Cloud-Anmeldedaten anstelle von langfristig gültigen secrets
Wir empfehlen Ihnen jedoch, die Checkliste sorgfältig durchzulesen, in der wir alle unsere Sicherheitshinweise zu GitHub Actions erläutern und erklären, warum diese wichtig sind. Werfen Sie auch einen Blick auf die Tools am Ende der Seite, die Ihnen bei der Umsetzung und Durchsetzung dieser Best Practices helfen werden.
Trigger-Konfiguration
1. Verwende „pull_request_target“ niemals in öffentlichen Repos
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 lassen sich PRs von externen Mitwirkenden automatisch mit Labels versehen oder kommentieren. Die Idee ist gut, doch der Zugriff auf secrets dies secrets einer Gefahr.
Im Gegensatz zum Standard Pull-Anfrage Auslöser, pull_request_target wird im Kontext des Basis-Repositorys ausgeführt, unabhängig davon, woher der Pull-Request stammt. Jeder kann einen Pull-Request für ein öffentliches Repository erstellen. Wenn Ihr Workflow durch diesen Pull-Request ausgelöst wird, 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 – selbst wenn der Pull-Request noch nicht zusammengeführt wurde. Das Skript des Angreifers kann diese Geheimnisse ganz einfach mit einer Umgebungsabfrage wie os.environ.get('MY_SECRET') und sie an einen Angreifer zurücksenden, ohne Spuren zu hinterlassen.
Wenn du dies in einem privaten Repo benötigst, kannst du festlegen, dass Pull-Anfragen von Erstmitwirkenden erst dann einen Workflow auslösen können, wenn sie von einem Betreuer genehmigt wurden. GitHub unterstützt dies standardmäßig unter „Einstellungen > Aktionen > Workflows für Pull-Anfragen von Forks“.
In der Praxis: Der Trivy im März 2026 erfolgte durch Ausnutzung einer Sicherheitslücke pull_request_target. Die Ingenieure hielten das für sicher, da auf dem Gerät keine Programme ausgeführt werden durften, doch das reichte nicht aus. Der PR übermittelte die secrets den Angreifer, der sie nutzte, um sich in die Konten einzuloggen. Kurz darauf gelang es einem Angreifer habe angefangen, GitHub zu durchsuchen speziell für Repos mit pull_request_target hat innerhalb von etwa einem Tag einige hundert PRs aktiviert und geöffnet.
2. Vermeiden Sie die Verwendung von `workflow_run` in öffentlichen Repositories
workflow_run ermöglicht es Ihnen, Workflows zu verketten, sodass ein nachgelagerter Workflow ausgelöst wird, sobald ein vorgelagerter abgeschlossen ist. Das Problem ist, dass der nachgelagerte Workflow mit Schreibrechten und Zugriff auf geheime Daten 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-Anfrage Der Workflow ist anfällig für Skript-Injektionen; ein Angreifer kann das Ausgabeartefakt über einen PR manipulieren. Der nachgelagerte Workflow verarbeitet dann die vom Angreifer kontrollierten Inhalte in einem privilegierten Kontext mit Zugriff auf geheime Daten, sodass die vom Angreifer kontrollierten Inhalte aus einem nicht vertrauenswürdigen PR nun über einen zusätzlichen Schritt einen Workflow mit Zugriff auf geheime Daten erreicht haben. Der Angriffspfad ist länger als pull_request_target aber führt zum selben Ergebnis.
Am besten ist es, dieses Muster zu vermeiden. Wenn eine Bereitstellung nur bei Pushes auf „main“ erfolgen soll, löse sie direkt durch einen Push auf „main“ aus, anstatt sie über workflow_run. Wenn du es wirklich brauchst workflow_run, überprüfen github.event.workflow_run.event bevor eine Aktion mit Sonderrechten ausgeführt wird. Wenn der vorgelagerte Auslöser ein Pull-Anfrage Anstatt auf die Aufforderung eines Betreuers zu warten, solltest du lieber vor der Bereitstellung oder dem Schreiben von Code aussteigen.
Jobs:
Bereitstellung:
wenn: github.event.workflow_run.event == 'push'
zizmor wird markieren workflow_run Workflows, die privilegierte Aktionen ohne Ereignisüberprüfung ausführen, wenn Sie eine automatisierte Erkennung in Ihrem gesamten Repository-Bestand wünschen.
3. Überprüfen Sie Arbeitsabläufe unter Verwendung anderer privilegierter Auslöser
Zusätzlich zu pull_request_target und workflow_runAchten Sie auf andere Trigger, die mit Zugriff auf secrets ausgeführt werden. Dazu gehören Kommentar abgeben, Themen, Pull-Request-Prüfung, und Kommentar zur Pull-Anfrage-Prüfung. Da sie alle mit geheimen Zugriffsrechten ausgeführt werden, können sie von externen Akteuren beeinflusst werden. Es gelten dieselben Regeln zur Skript-Injektion, nämlich Werte aus diesen Ereignissen niemals direkt in Ausführen: Schritte. Mehr dazu erfahren Sie im nächsten Abschnitt.
Umgang mit nicht vertrauenswürdigen Eingaben
1. Verhindern Sie Skript-Injektionen, indem Sie alle Zweignamen, PR-Titel, Commit-Meldungen und Issue-Texte als nicht vertrauenswürdige Eingaben behandeln
Das funktioniert nach dem gleichen Prinzip wie bei einer SQL-Injection. Vom Benutzer gesteuerte Werte, die in einen Shell-Befehl gelangen, werden als Code und nicht als Daten interpretiert; daher sollte man niemals interpolieren github.* Werte direkt in Ausführen: Schritte. Die Lösung besteht darin, den Wert zunächst einer Umgebungsvariablen zuzuweisen und diese Variable dann im Shell-Skript zu verwenden:
# 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 Zeichenkette, anstatt ihn beim Parsen 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].messageund ähnliche Kontextwerte. Ein guter SAST wie Aikido dies und liefert die Korrektur in einem Pull-Request.
In freier Wildbahn: In der Angriff auf Ultralytics, ein Angreifer benannte einen Zweig mit einem curl-Befehl, den ein Workflow direkt in einen Ausführen: Schritt, indem man ihn als Code ausführt. Der Nx/s1ngularity-Angriff, das zuerst von Aikido entdeckt wurde, kombinierte dies mit pull_request_target, wo ein PR an einen veralteten Branch einen anfälligen Workflow auslöste, der zu einem Datenleck führte GITHUB_TOKEN mit Lese- und Schreibrechten, die anschließend zur Veröffentlichung bösartiger npm-Pakete genutzt wurden.
2. Verwenden Sie für KI-Agenten in benutzerdefinierten Workflows schreibgeschützte Tokens und halten Sie die Rohdaten der Benutzereingaben aus den Eingabeaufforderungen heraus
KI-Agenten, die in GitHub-Actions-Workflows ausgeführt werden, verfügen über denselben geheimen Zugriff wie jeder andere Schritt. Wenn ein Agent im Rahmen seiner Eingabeaufforderung Issue-Titel, PR-Beschreibungen oder Commit-Meldungen verarbeitet, kann ein Angreifer Anweisungen in diesen Text einfügen und den Agenten dazu manipulieren, privilegierte Aktionen auszuführen, wie z. B. das Ändern von Dateien oder das Exfiltrieren von Daten über beliebige Tools, auf die er Zugriff hat. Da es keine Möglichkeit gibt, Prompt-Injection in LLMs zu verhindern, sollten Sie KI-Agenten keinen Zugriff über das Lesen hinaus gewähren und ihnen nicht erlauben, rohe Issue-Titel, PR-Beschreibungen oder Commit-Meldungen als Eingabe für die Eingabeaufforderung zu erhalten.
In der Praxis: Aikido haben dies anhand von PromptPwnd: Ein böswilliger Issue-Titel, der in einen Gemini-CLI-Workflow eingegeben wurde, führte dazu, dass der Agent Repository secrets Verwendung seines eigenen gh Zugriff auf das Tool.
3. Behandle von LLM generierte Ergebnisse als nicht vertrauenswürdige Eingaben
Wenn ein Workflow ein LLM verwendet, um einen Befehl, ein Skript oder einen Dateipfad zu generieren, und diese Ausgabe direkt an einen Ausführen: Dies birgt dasselbe Injektionsrisiko wie die Interpolation eines Zweignamens oder eines PR-Titels. Die Sicherheit der LLM-Ausgabe ist nicht gewährleistet, und ein Angreifer, der die Eingabeaufforderung beeinflussen kann, kann auch beeinflussen, was ausgeführt wird. Wie wir bereits im vorangegangenen Punkt zum Thema „Prompt-Injection“ besprochen haben, sollten Sie die LLM-Ausgabe zunächst einer Umgebungsvariablen zuweisen, sie nach Möglichkeit validieren und sie niemals direkt in einen Shell-Befehl einfügen.
4. Schreibe niemals nicht vertrauenswürdige Daten in GITHUB_ENV oder GITHUB_PATH
An GITHUB_ENV legt Umgebungsvariablen für alle nachfolgenden Schritte des Auftrags fest. Das Schreiben in GITHUB_PATH fügt Einträge dem System-PATH für alle nachfolgenden Schritte hinzu. Wenn nicht vertrauenswürdige Inhalte in eine dieser Dateien gelangen, kann ein Angreifer beliebige Umgebungsvariablen setzen, wie zum Beispiel NODE_OPTIONS die die Ausführung von Code auslösen. Sie könnten zudem eine Malware-Datei an den Anfang des PATH-Pfads einfügen, die anstelle eines vertrauenswürdigen Tools aufgerufen wird. Das anfällige Muster ist ein Arbeitsablauf, bei dem ein Artefakt heruntergeladen oder eine benutzergesteuerte Eingabe gelesen und direkt in $GITHUB_ENV ohne Bereinigung. Behandeln Sie alles, was in diese Dateien geschrieben wird, mit derselben Vorsicht wie ein Ausführen: Schritt.
Umgang mit Artefakten
5. Entpacken Sie die Dateien in ein temporäres Verzeichnis wie /tmp anstelle des Arbeitsbereichs, um ein Überschreiben der Workflow-Dateien zu vermeiden
Das direkte Entpacken eines Artefakts in den Arbeitsbereich könnte dazu führen, dass ein Archiv mit schädlichem Inhalt Workflow-Dateien, Skripte oder Tools überschreibt, auf die nachfolgende Schritte angewiesen sind. Das Entpacken in /tmp oder ein anderes isoliertes Verzeichnis sorgt dafür, dass der Inhalt der Artefakte von allem getrennt bleibt, was Ihr Workflow als vertrauenswürdig einstuft. GitHub unterstützt auch die Überprüfung von SHA256-Hashwerten falls Sie strengere Integritätsgarantien benötigen.
6. Geheime Dateien ausschließen (.env, Konfigurationsdateien, Anmeldedaten) aus hochgeladenen Artefakten und vermeiden Pfad: . Muster, die alles mit sich reißen
Der Pfad: . Muster in einem Aktionen/Artefakt hochladen Mit „step“ wird der gesamte Inhalt des Arbeitsverzeichnisses hochgeladen, was Folgendes beinhalten kann: .env Dateien, Konfigurationsdateien mit eingebetteten Anmeldedaten oder zwischengespeicherte secrets , die von anderen Schritten auf die Festplatte secrets . Geben Sie genau an, was Sie hochladen, damit Sie Ihre Anmeldedaten nicht versehentlich im Internet veröffentlichen. Geben Sie bestimmte Verzeichnisse oder Dateitypen an, anstatt den gesamten Arbeitsbereich zu erfassen, und fügen Sie .env, *.pemund ähnliche Dateien in Ihren .gitignore sowie Muster zum Ausschluss von Artefakten.
Veränderbare Aktionsreferenzen
7. 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, haben jedoch den Nachteil, dass sie nicht statisch sind. Tags und Branches sind veränderbar, was bedeutet, dass ein Repo-Besitzer sie jederzeit auf einen anderen Commit verweisen lassen kann, und bei Tags wie @main. Wenn man auf eine bestimmte Version verweist mit Verwendet: some-action@v3… erwarten wir, dass der Commit unverändert bleibt. Sollte jedoch das Konto des Action-Maintainers kompromittiert werden, kann ein Angreifer dieses Tag auf einen bösartigen Commit umleiten, und jeder nachgelagerte Workflow übernimmt diesen beim nächsten Durchlauf, ohne dass ein Pull Request oder ein anderer Hinweis darauf erfolgt. Um dies zu verhindern, empfiehlt es sich, stattdessen auf den vollständigen Commit-SHA zu verweisen: Verwendet: some-action@abc123def456....Das kann natürlich etwas mühsam sein, daher kannst du Dependabot, Renovate oder pinact verwenden, um festgelegte SHAs auf dem neuesten Stand zu halten. Native Lockfiles stehen auf der GHA-Roadmap, sodass sie hoffentlich bis 2027 verfügbar sein werden.
In der Praxis: Im März 2025 haben Angreifer 76 von 77 Versions-Tags in trivy zu bösartigen Commits, die einen Infostealer enthielten. Jeder Workflow, der diese Tags namentlich referenzierte, hat den bösartigen Code automatisch übernommen.
8. Maßnahmen Dritter vor der Übernahme prüfen
Bevor Sie ein Verwendungszwecke: Nehmen Sie sich zwei Minuten Zeit, um das Repository der Action zu überprüfen. Prüfen Sie, ob der Ersteller GitHub-verifiziert ist, wann das Repository zuletzt gepflegt wurde, wie viele Mitwirkende es hat und wie hoch seine Punktzahl auf der OpenSSF-Scorecard ist. Eine weit verbreitete Action von einem nicht verifizierten Einzelbetreuer ohne aktuelle Aktivitäten ist ein lohnendes Ziel für eine Kontoübernahme.
9. Bevorzugen Sie Aktionen mit weniger transitiven Abhängigkeiten
Je mehr Abhängigkeiten Sie haben, desto anfälliger sind Sie für Lieferkettenangriffe. Wählen Sie daher, sofern möglich, Aktionen mit weniger Abhängigkeiten. Eine Aktion kann selbst auf andere Aktionen verweisen, 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 freier Wildbahn: Die tj-Aktionen Kompromiss teilweise über diesen Mechanismus weitergegeben. Nachgelagerte Workflows, die an tj-actions/changed-files, aber geänderte Dateien transitiv referenziert reviewdog/action-setup durch ein veränderbares Tag, sodass, als „reviewdog“ kompromittiert wurde, jede nachgelagerte Pipeline den Schadcode ausführte.
Veränderliche Paketabhängigkeiten
10. Die Versionen der npm- und PyPI-Pakete explizit festlegen
Gleitkommazahlen wie ^1.2.0 oder >=2.0.0 bedeutet, dass Ihr Workflow zur Laufzeit die jeweils aktuellste passende Version installiert. Sollte ein Paket kompromittiert werden und eine neue schädliche Version innerhalb Ihres Versionsbereichs veröffentlicht werden, wird diese bei der nächsten Ausführung automatisch in Ihren Workflow übernommen. Festlegung auf bestimmte Versionen (1.2.3), sodass Ihr Workflow immer nur das installiert, was Sie ausdrücklich ausgewählt haben. Lassen Sie sich nicht auf den Bereich ein.
In freier Wildbahn: Die Ultralytics -Angriff zeigte, wie eine kompromittierte Paketversion, die auf PyPI veröffentlicht wurde, Workflows erreichen kann, die nicht festgepinnt sind. Die erste bösartige Version war stundenlang live, bevor sie entdeckt wurde – lange genug, um Builds zu beeinträchtigen, die nicht festgelegte Abhängigkeiten einbinden.
11. Legen Sie ein Mindestalter für die Veröffentlichung fest, sofern Ihr Paketmanager dies unterstützt (pnpm, yarn)
Selbst bei festgehaltenen Versionen kann ein neu veröffentlichtes schädliches Paket genau die Version haben, auf die Sie später aktualisieren möchten. Durch die Einstellung des Mindestalters für Veröffentlichungen wird Ihr Paketmanager angewiesen, Pakete abzulehnen, die vor weniger als einer bestimmten Zeit – in der Regel 72 Stunden – veröffentlicht wurden. So hat die Community Zeit, schädliche Veröffentlichungen zu erkennen und zu melden, bevor diese in Ihre Builds gelangen. pnpm und yarn unterstützen dies nativ, npm jedoch noch nicht. Aikido Chain kann diese Funktion für npm übernehmen (siehe unten).
12. Überprüfen Sie die Herkunft des Pakets anhand von Bescheinigungen, sofern diese verfügbar sind
Einige Paket-Registries unterstützen mittlerweile Herkunftsbescheinigungen, bei denen kryptografische Datensätze ein veröffentlichtes Paket mit dem spezifischen Quellcode-Commit und der Build-Pipeline verknüpfen, aus denen es erstellt wurde. Durch die Überprüfung dieser Bescheinigungen vor der Installation eines Pakets lässt sich sicherstellen, dass es tatsächlich aus dem angegebenen Quellcode erstellt wurde. npm unterstützt dies für Pakete, die über GitHub Actions veröffentlicht werden. Da es sich hierbei noch um eine relativ neue Praxis handelt, ist die Tool-Unterstützung noch nicht vollständig vorhanden; dennoch lohnt es sich, diese Funktion zu aktivieren, sofern Ihre Registry und Ihr Paketmanager dies unterstützen.
Secrets
13. Verweise auf secrets Umgebungsvariablen, niemals über Befehlszeilenargumente
Befehlszeilenargumente sind in Prozesslisten sichtbar, sodass andere Prozesse auf dem Runner, die Zugriff auf /proc lesen kann. Wenn man ein Geheimnis als Umgebungsvariable übergibt, bleibt es aus der Prozesstabelle heraus. Legen Sie das Geheimnis in Ihrem Workflow in einer Umgebung: Block und Referenz $SECRET_NAME im Shell-Befehl statt ${{ secrets.MY_SECRET }} inline.
In der Praxis: tj-actions gab secrets preis, secrets sie in das Protokoll ausgegeben wurden (das Echo-/Maskierungsproblem), und der Trivy führte zum Diebstahl eines PAT. Secrets geht es darum, den Zugriff auf secrets System einzuschränken, damit ein Angreifer im Falle eines Fehlers keine funktionierenden Anmeldedaten erbeuten kann.
14. Beschränken Sie die Sichtbarkeit von secrets Repo-Ebene nach Möglichkeit auf bestimmte GitHub-Umgebungen
Mit GitHub Environments können Sie secrets Deployment-Schutzregeln absichern, sodass ein Geheimnis wie PROD_DB_PASSWORD ist nur für Workflows verfügbar, die auf die Produktionsumgebung abzielen. Ohne diese Einstellung kann jeder Workflow im Repo alle Geheimnisse auf Repo-Ebene lesen. Du kannst dies unter „Einstellungen > Umgebungen“ konfigurieren.
15. Wenden Sie secrets Workflow auf Schritt-Ebene an, nicht auf Job-Ebene
Die Beschränkung secrets die einzelnen Schritte eines Jobs, die diese benötigen, wendet das Prinzip der geringsten Berechtigungen an, um den Schaden zu begrenzen, falls eine Aktion kompromittiert wird. Ein auf Job-Ebene deklariertes Geheimnis Umgebung: Der Block ist für jeden Schritt in diesem Job lesbar, einschließlich der Aktionen von Drittanbietern.
In freier Wildbahn: Im Shai-Hulud-Angriffwurden Tokens mit Workflow-Gültigkeitsbereich über mehrere Opfer hinweg wiederverwendet. Ein engerer Gültigkeitsbereich hätte den Ausbreitungsradius begrenzt.
16. 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-Anmeldedaten, die als secrets gespeichert sind, secrets unbefristet gültig. Werden sie also gestohlen, ist das Schadenspotenzial enorm. Mit OIDC kann dein Workflow direkt bei AWS, Azure oder GCP ein kurzlebiges Token anfordern, das auf den jeweiligen Auftrag beschränkt und nur wenige Minuten gültig ist. So gibt es keine Anmeldedaten, die ein Angreifer stehlen könnte. AWS, Azure und GCP unterstützen dies alle nativ. Die Einrichtung erfordert die Konfiguration einer Vertrauensbeziehung zwischen deinem Cloud-Anbieter und dem OIDC-Endpunkt von GitHub.
17. Für Workflow-Ausführungen, die Produktionsumgebungen nutzen, eine manuelle Freigabe verlangen
Konfigurieren Sie Ihre GitHub-Umgebung so, dass ein Workflow erst nach einer Überprüfung auf secrets einer Umgebung zugreifen secrets dort bereitgestellt werden darf. Dies ist vor allem für kleinere Teams oder solche, die nur selten neue Versionen veröffentlichen, sinnvoll. Für größere Teams ist OIDC mit kurzlebigen Anmeldedaten die skalierbarere Alternative.
18. Vermeiden Sie es, vertrauliche Werte auszugeben oder zu protokollieren, auch in der Debug-Ausgabe
GitHub maskiert bekannte geheime Werte in Protokollen, jedoch nur bei exakten Übereinstimmungen. Wenn ein geheimer Wert also Base64-kodiert oder auf zwei „echo“-Aufrufe verteilt wird, funktioniert die Maskierung nicht. Am sichersten ist es, secrets niemals auszugeben. Wenn Sie überprüfen müssen, ob ein geheimer Wert gesetzt ist, sollten Sie nach einer nicht leeren Zeichenkette suchen, anstatt den Wert auszugeben.
Läufer
19. Verwenden Sie keine selbst gehosteten Runner in öffentlichen Repositories
Jeder kann einen Pull Request für ein öffentliches Repository erstellen, was bedeutet, dass potenziell jeder einen Workflow-Lauf auslösen kann. Die Standard-Genehmigungseinstellungen von GitHub für Erst-Mitwirkende mindern dieses Risiko auf von GitHub gehosteten Runners, wo die Umgebung ohnehin kurzlebig und isoliert ist. Auf einem selbst gehosteten Runner bedeutet eine falsch konfigurierte oder zu freizügige Genehmigungs-Einstellung, dass derselbe PR die Code-Ausführung auf Ihrer Infrastruktur auslöst. GitHub empfiehlt, für öffentliche Repos von GitHub gehostete Runner zu verwenden und die Genehmigungsrichtlinie auf „Genehmigung für alle externen Mitwirkenden erforderlich“ zu verschärfen.
In der Praxis: Forscher führten einen Supply-Chain-Angriff auf PyTorch durch, indem sie einen trivialen PR einreichten, der einen Workflow auf einem selbst gehosteten Runner auslöste, wodurch sie Root-Zugriff auf den Rechner erhielten.
20. Verwenden Sie kurzlebige Runner anstelle von statischen, dauerhaften
Ein statischer Runner speichert den Status zwischen den Jobs, was bedeutet, dass ein kompromittierter Job schädliche Dateien, veränderte Binärdateien oder manipulierte Caches hinterlassen kann, die sich auf nachfolgende Ausführungen auf diesem Rechner auswirken. Kurzlebige Runner starten mit einem sauberen Zustand und werden nach jedem Job gelöscht. Verwenden Sie den „Actions Runner Controller“ für Kubernetes-basierte Setups oder übergeben Sie die --vergänglich Markierung bei der manuellen Registrierung eines Läufers.
In freier Wildbahn: Shai-Hulud registrierte persistente, selbst gehostete Runner in kompromittierten Repositories und nutzte diese als persistenten C2-Kanal, der für die Netzwerküberwachung unsichtbar war, da der gesamte Datenverkehr über github.com lief.
21. Den ausgehenden Datenverkehr des Runner-Netzwerks auf eine Zulassungsliste beschränken
Die wertvollste Aktion eines kompromittierten Workflows ist oft das Abziehen secrets einen vom Angreifer kontrollierten Server. Wenn man den ausgehenden Netzwerkzugriff auf die Domänen beschränkt, die Ihr Workflow tatsächlich benötigt, wird dies erheblich erschwert. Harden-Runner und bullfrog funktionieren beide auf von GitHub gehosteten Runners. Bei selbst gehosteten Runners erreichen Firewall-Regeln auf Netzwerkebene dasselbe.
Wenn Sie GitHub Enterprise mit selbst gehosteten Runners nutzen, bieten IP-Whitelists für Token eine zusätzliche Kontrollmöglichkeit in die andere Richtung. Sie schränken ein, von welchen IP-Adressen ein Token überhaupt genutzt werden darf, sodass ein gestohlenes Token nicht von der Infrastruktur eines Angreifers aus verwendet werden kann.
Token-Berechtigungen
22. Als Standard festlegen GITHUB_TOKEN Lesezugriff auf Organisationsebene oder Repository-Ebene
Der GITHUB_TOKEN ist bei jedem Workflow-Lauf automatisch verfügbar. Standardmäßig verfügt es über umfassende Lese- und Schreibrechte im gesamten Repository, sodass jeder kompromittierte Workflow in Ihr Repo schreiben, Releases erstellen oder PRs genehmigen kann. Legen Sie unter „Einstellungen > Aktionen > Allgemein“ die Standardeinstellung auf „Nur-Lese-Zugriff“ fest und erteilen Sie Schreibrechte dann ausdrücklich nur dort, wo sie benötigt werden.
23. Explizit deklarieren Berechtigungen: Blockierungen auf Workflow- oder Auftragsebene, um einzelne Aufträge einzuschränken
Das Festlegen einer schreibgeschützten Standardeinstellung auf Organisationsebene legt zwar die Standardeinstellung fest, doch benötigen manche Jobs natürlich erweiterte Berechtigungen. Wenn ein Job erweiterte Zugriffsrechte benötigt, definieren Sie eine Berechtigungen: auf Job-Ebene statt auf Workflow-Ebene sperren. Auf diese Weise gilt das Token mit erweiterten Rechten nur für diesen einen Job, und alle anderen Jobs im Workflow bleiben schreibgeschützt.
Jobs:
Bereitstellung:
Berechtigungen:
Inhalt: Lesen
ID-Token: SchreibenIn der Praxis: Die Angriffe „tj-actions“, Trivy und „prt-scan“ nutzten alle aus, dass Token über mehr Zugriffsrechte verfügten als nötig. Eine Verschärfung der Token-Berechtigungen verringert den Schadensumfang insgesamt.
Einstellungen für Organisation und Repository
24. Deaktivieren Sie die Möglichkeit für „Actions“, PRs zu genehmigen
Standardmäßig ermöglicht GitHub es Workflows, Pull-Anfragen mithilfe der GITHUB_TOKEN. Das bedeutet, dass ein kompromittierter Workflow seine eigenen schädlichen Änderungen genehmigen könnte, ohne dass ein Überprüfungsprozess durchlaufen wird. Deaktivieren Sie diese Option unter „Einstellungen“ > „Aktionen“ > „Allgemein“ > „GitHub Actions das Erstellen und Genehmigen von Pull-Anfragen erlauben“. (Manche Teams lassen diese Option für Dependabot aktiviert, doch ist es besser, Dependabot eigenes Bot-Konto mit ausdrücklichen Prüferberechtigungen zuzuweisen, anstatt die Workflow-Genehmigung für die gesamte Organisation zu aktivieren.)
25. Aktionsquellen auf verifizierte Ersteller oder bestimmte Repos beschränken
Die Standardeinstellung bei GitHub erlaubt es, jede im GitHub Marketplace veröffentlichte Aktion in Ihren Workflows zu verwenden. Die Beschränkung der Quellen auf verifizierte Ersteller oder eine bestimmte Zulassungsliste bedeutet, dass eine neu veröffentlichte bösartige Aktion nicht ohne ausdrückliche Genehmigung in Ihre Workflows übernommen werden kann. Stattdessen sollten Entwickler die Genehmigung bei demjenigen einholen, der für Ihre GitHub-Organisations-Einstellungen zuständig ist (in der Regel das Plattform- oder DevOps-Team), der sie dann zur Zulassungsliste hinzufügen kann. Konfigurieren Sie dies unter „Einstellungen“ > „Aktionen“ > „Allgemein“ > „Aktionen und wiederverwendbare Workflows zulassen“.
In freier Wildbahn: Die tj-actions-Sicherheitslücke betraf 23.000 Repos, unter anderem weil es für Teams keine Einschränkungen gab, welche Aktionen sie einziehen durften.
26. Achten Sie auf unerwartete Registrierungen selbst gehosteter Runner und neu erstellte öffentliche Repositorys in Ihrer Organisation
Mit einem gestohlenen Token kann ein Angreifer einen betrügerischen Runner registrieren, um eine dauerhafte Hintertür einzuschleusen. Außerdem erstellen Angreifer regelmäßig öffentliche Repos, um gestohlene Anmeldedaten dort abzuspeichern. Sowohl die Registrierung von Runners als auch die Erstellung von Repos sind Ereignisse, die Ihr Team sofort erkennen muss, doch GitHub gibt standardmäßig keine entsprechenden Warnmeldungen aus. Die Abhilfe besteht darin, dies manuell zu überwachen. Leiten Sie das Audit-Protokoll Ihrer Organisation an ein SIEM-System weiter und richten Sie Warnmeldungen ein für self_hosted_runners.register Ereignisse und die Erstellung von Repositorys. Ohne ein SIEM können Sie das Audit-Protokoll über die GitHub-API abrufen oder manuell unter „Einstellungen > Audit-Protokoll“ überprüfen.
In der Praxis: Beim Shai-Hulud-Angriff wurden kompromittierte Rechner als selbst gehostete Runner mit dem Namen SHA1HULUDregistriert, und gestohlene Anmeldedaten wurden verwendet, um öffentliche Repositorys zu erstellen, die als Speicherorte für die Exfiltration dienten. Eine Überwachung beider Aspekte hätte die Kampagne frühzeitig aufgedeckt.
27. Verwenden Sie „CODEOWNERS“, um eine sicherheitsbewusste Überprüfung von Änderungen an .github/workflows/
Workflow-Dateien sind Code, der mit Zugriff auf Ihre secrets Tokens ausgeführt wird. Ohne ausdrückliche Regeln zur Eigentümerschaft kann jeder Entwickler mit Schreibzugriff auf das Repo einen Workflow ändern und ihn ohne Sicherheitsüberprüfung zusammenführen. Fügen Sie einen CODEOWNERS-Eintrag hinzu, der auf .github/workflows/ an einen Prüfer oder ein Team, das die Sicherheitsaspekte versteht, und kombinieren Sie dies mit Regeln zum Schutz des Branches, die vor dem Merge die Genehmigung durch CODEOWNERS erfordern.
Schützen Sie GitHub-Actions-Workflows mit Aikido
Aikido erkennt unsichere GitHub-Actions-Workflows und hilft Entwicklern, diese zu beheben, bevor sie ausgenutzt werden.
Es erkennt Probleme wie:
- Unsachgemäße Verwendung von
pull_request_target - Skript-Injektion über nicht vertrauenswürdige
github.*Eingabe - Einfügen von Vorlagen und Eingabeaufforderungen in KI-gestützte Arbeitsabläufe
- Nicht angeheftete Aktionen von Drittanbietern
- Überprivilegiert
GITHUB_TOKENBerechtigungen - Risikobehafteter Umgang mit vertraulichen Informationen in Arbeitsabläufen
Aikido außerdem:
- Patch-PRs automatisch erstellen
- Erkennen Sie unsichere Arbeitsablaufmuster in verschiedenen Repositorys
- Markiere veränderbare GitHub-Action-Referenzen, die an einen vollständigen Commit-SHA angeheftet werden sollen
Aikido Chain trägt zum Schutz von Paketinstallationen bei, indem es:
- Bekannte schädliche npm- und PyPI-Pakete blockieren
- Durchsetzung der Richtlinien zum Mindestalter für Pakete
Beispielsweise Aikido nicht bereinigte Benutzereingaben in Ausführen: führt die einzelnen Schritte durch und schlägt automatisch das sicherere Muster für die Umgebungsvariable vor.
Hier kannst du kostenlos loslegen.
Bereit, GitHub-Actions-Workflows zu sichern
Halten Sie diese Checkliste griffbereit, während Sie an der Absicherung Ihrer GitHub-Actions-Workflows arbeiten. Versuchen Sie, die Punkte, die Sie umsetzen können und die nur wenige Minuten in Anspruch nehmen, bald zu erledigen, und teilen Sie diese Liste mit Ihren Teamkollegen, damit alle über die Änderungen informiert sind.
FAQ: Sicherheit bei GitHub Actions
Wie werden GitHub-Actions-Workflows am häufigsten ausgenutzt?
Skripteinbettung ist der häufigste Angriffsvektor. Angreifer fügen bösartigen Code in Zweignamen, PR-Titel oder Issue-Texte ein, und Workflows, die diese Werte direkt in Ausführen: Führen Sie diese Schritte als Shell-Befehle aus. Durch das Verknüpfen von Aktionen mit Commit-SHAs und die Verwendung von Umgebungsvariablen anstelle von Inline-Interpolation lassen sich die meisten dieser Sicherheitslücken schließen.
Was ist pull_request_target und warum ist das gefährlich?
pull_request_target ist ein Workflow-Trigger, der mit Zugriff auf secrets des Basis-Repositorys ausgeführt wird, selbst wenn der auslösende Pull-Request aus einem Fork stammt. Da jeder einen Pull-Request für ein öffentliches Repository erstellen kann, macht jeder Workflow, der diesen Trigger verwendet, seine secrets externe Mitwirkende zugänglich. Vermeiden Sie ihn in öffentlichen Repositorys gänzlich.
Was bedeutet „Aktionen an einen Commit-SHA heften“ und warum ist das wichtig?
Die meisten Workflows verweisen über Tags auf Aktionen von Drittanbietern, wie zum Beispiel Verwendet: some-action@v3. Tags sind veränderbar; wenn also das Konto eines Action-Betreibers gehackt wird, kann ein Angreifer dieses Tag unbemerkt auf bösartigen Code umleiten. Das Verweisen auf einen vollständigen Commit-SHA wie Verwendet: some-action@abc123... bedeutet, dass Ihr Workflow immer genau das ausführt, was Sie geprüft haben.
Sollte ich bei öffentlichen Repositorys selbst gehostete Runner verwenden?
Nein. Jeder kann einen Pull Request für ein öffentliches Repository erstellen und einen Workflow auslösen. Auf von GitHub gehosteten Runners ist das überschaubar, da die Umgebung kurzlebig und isoliert ist. Auf einem selbst gehosteten Runner kann eine falsch konfigurierte Genehmigungsrichtlinie dazu führen, dass externe Mitwirkende Code direkt auf Ihrer Infrastruktur ausführen können.
Was ist OIDC und warum ist es besser, als Cloud-Anmeldedaten als secrets zu speichern?
StatischeAnmeldedaten, die als secrets gespeichert secrets unbegrenzt gültig, sodass ein gestohlenes Secret auch lange nach dem Sicherheitsvorfall noch eine Gefahr darstellt. Mit OIDC kann Ihr Workflow ein kurzlebiges Token von AWS, Azure oder GCP anfordern, das auf diesen bestimmten Auftrag beschränkt und nur wenige Minuten gültig ist. Es gibt keine langlebigen Anmeldedaten, die gestohlen werden könnten.
