Warum Entwickler-Ökosysteme zum bevorzugten Angriffsziel geworden sind

Anfang 2026 machte ein Vorfall Schlagzeilen, der vielen Entwicklern einen kalten Schauer über den Rücken jagte: Zwei KI-Extensions im Visual Studio Code Marketplace – ChatGPT – 中文版 (1,34 Millionen Installationen) und ChatMoss/CodeMoss (150.000 Installationen) – stahlen systematisch Quellcode, Credentials und Konfigurationsdateien von 1,5 Millionen Entwicklern und schickten die Daten an Server in China.

Die Kampagne, von Sicherheitsforschern MaliciousCorgi getauft, nutzte drei Mechanismen:

Echtzeit-Datei-Monitoring: Jede im Editor geöffnete Datei wurde Base64-kodiert und übertragen
Bulk-Harvesting: Bis zu 50 Dateien pro Workspace auf Server-Kommando
Verhaltens-Tracking: Unsichtbare iFrames mit chinesischen Analytics-Plattformen (Zhuge.io, GrowingIO, TalkingData, Baidu Analytics)

Was gestohlen wurde: Privater Quellcode, Cloud-Service-Credentials, .env-Dateien mit API-Keys, Konfigurationsdateien – kurz: das gesamte geistige Eigentum und die Infrastruktur-Zugänge von über einer Million Entwicklern.

Das Perfide: Die Extensions lieferten echten Nutzen. Sie funktionierten tatsächlich als KI-Coding-Assistenten. Die schädliche Logik war tief versteckt, undokumentiert, und lief parallel zum legitimen Feature-Set. Hohe Downloadzahlen sorgten für Vertrauen. Reviews waren positiv. Niemand schöpfte Verdacht – bis es zu spät war.

Dieser Fall ist kein Einzelfall. Er ist symptomatisch für ein grundlegendes Problem moderner Softwareentwicklung: 2025 wurden weltweit mehr als 16.000 neue schädliche Pakete in npm, PyPI und Maven Central identifiziert, ein Anstieg von 188 % im Jahresvergleich. Die Entwicklungsumgebung selbst ist Teil der Angriffsfläche geworden.

Die Zahlen sprechen eine klare Sprache

Die wirtschaftlichen Dimensionen sind beachtlich: Cybersecurity Ventures prognostiziert, dass Supply-Chain-Angriffe auf Software weltweit 60 Milliarden Dollar Schaden allein in 2025 verursachen werden. Bis 2031 soll diese Zahl auf 138 Milliarden Dollar steigen.

Gartner geht davon aus, dass bis Ende 2025 45 % aller Unternehmen weltweit Angriffe auf ihre Software-Supply-Chain erlebt haben werden – eine Verdreifachung gegenüber 2021. Dabei verursachen Supply-Chain-Angriffe heute das 17-fache der Kosten direkter Angriffe, mit durchschnittlich 4,91 Millionen Dollar pro Vorfall.

Die Frequenz nimmt zu: 2025 wurden durchschnittlich 26 Angriffe mit Supply-Chain-Bezug pro Monat registriert – doppelt so viele wie noch Anfang 2024.

VS Code: Ein Beispiel unter vielen

Visual Studio Code eignet sich gut als Beispiel, weil die Vorfälle gut dokumentiert sind und die Verbreitung enorm ist. Aber das grundlegende Problem ist ökosystemübergreifend.

Die wichtigsten Vorfälle 2025

TigerJack-Kampagne (Oktober 2025)
Mindestens 11 schädliche VS Code Extensions mit Spyware, Krypto-Minern und Remote-Backdoors. Über 17.000 Downloads, bevor Microsoft die Extensions entfernte. Zwei Extensions allein – „C++ Playground” und „HTTP Format” – kamen auf diese Downloadzahl.

GlassWorm (Oktober 2025)
Der erste selbst-replizierende Wurm für VS Code Extensions. Nutzte unsichtbare Unicode-Zeichen, um schädlichen Code vor Code-Reviews zu verstecken. Kommando-Infrastruktur auf der Solana-Blockchain. Sieben Extensions im OpenVSX Marketplace kompromittiert, insgesamt 35.800 Downloads.

BigBlack Publisher (Dezember 2025)
Malware stahl WLAN-Passwörter, las Zwischenablagen aus und kaperte Browser-Sitzungen. Microsoft entfernte die Extensions erst nach mehreren Tagen aktiver Verbreitung.

Prettier-Impersonation (November 2025)
Eine gefälschte Extension „prettier-vscode-plus” imitierte den legitimen Prettier Code Formatter – ein Tool, dem Millionen von Entwicklern vertrauen.

Das strukturelle Problem bei IDE-Extensions

Über 100 VS Code Extensions zeigten 2025 Supply-Chain-Schwachstellen durch geleakte Access-Tokens. Diese Tokens erlaubten Angreifern, bestehende Extensions direkt zu aktualisieren – mit potenzieller Reichweite auf eine installierte Basis von 150.000 Nutzern.

Die Zahl der erkannten schädlichen VS Code Extensions stieg von 27 im gesamten Jahr 2024 auf 105 in den ersten zehn Monaten 2025.

npm, PyPI & Co.: Das gleiche Muster auf Package-Ebene

Bei Paketmanagern ist das Problem schon länger bekannt, hat sich aber 2025 massiv verschärft.

Die Shai-Hulud-Kampagne

Eine mehrstufige Angriffswelle auf die JavaScript-Supply-Chain. Begann mit kompromittierten Maintainer-Accounts, entwickelte sich zu gezielten Angriffen und erreichte in Version 2.0 die Fähigkeit zur Selbst-Replikation sowie zum Credential-Austausch zwischen Opfern.

s1ngularity-Kampagne (August–November 2025)

Kompromittierte Nx-Pakete. Ergebnis: 2.349 Credentials von 1.079 Entwicklersystemen gestohlen. Die erbeuteten NPM-Tokens ermöglichten möglicherweise Folge-Angriffe.

Chalk & Debug: Der Phishing-Vorfall

Ein Maintainer der weitverbreiteten Pakete „chalk” und „debug” fiel auf eine Phishing-Mail herein. Angreifer konnten kompromittierte Versionen hochladen – Pakete mit Milliarden wöchentlicher Downloads insgesamt.

Typosquatting in großem Maßstab

287 populäre npm-Pakete wurden erfolgreich durch Typosquatting imitiert
Über 500 schädliche PyPI-Pakete in zwei koordinierten Wellen
PhantomRaven-Kampagne: 126 schädliche npm-Pakete mit Multi-Plattform-Infostehlern (Windows, Linux, macOS)
Pakete mit insgesamt 1,2 Milliarden wöchentlichen Downloads wurden seit 2022 durch Typosquatting-Kampagnen angegriffen

Statistiken zeigen: 18 von 40 historischen Typosquats hatten eine Levenshtein-Distanz von ≤2 zum Original. Ein weggelassener Buchstabe, ein vertauschtes Paar – das reicht.

GitHub Actions: CI/CD als Einfallstor

GitHub Actions haben sich 2025 als einer der attraktivsten und verwundbarsten Einstiegspunkte in die Software-Supply-Chain erwiesen.

CVE-2025-30066: tj-actions/changed-files

Der gravierendste Vorfall des Jahres. Die populäre GitHub Action „tj-actions/changed-files” wurde zwischen 10. und 14. März 2025 kompromittiert und betraf über 23.000 Repositories.

Angriffsmechanik:
Ein Base64-kodierter Payload druckte alle Credentials aus dem CI-Runner-Speicher ins Workflow-Log. Der Angreifer änderte bestehende Version-Tags, sodass am 15. März alle Versionen auf schädlichen Code zeigten.

Auswirkungen:

Diebstahl von CI/CD-Secrets (API-Keys, Cloud-Credentials, SSH-Keys)
Unbefugter Zugriff auf Quellcode, Infrastruktur, Produktionsumgebungen
Credential-Leaks in öffentlichen Repositories
Bei Coinbase: 70.000 betroffene Kunden durch kompromittierte GitHub Action

CVSS-Score: 8.6

Weitere Schwachstellen

Statische Taint-Analyse fand Code-Injection-Schwachstellen in über 4.300 Workflows von 2,7 Millionen analysierten
54 % aller JavaScript Actions enthalten mindestens eine Sicherheitsschwachstelle
Die meisten Schwachstellen stammen aus indirekten Abhängigkeiten

KI-Integration als neue Angriffsfläche

Der Shai-Hulud 2.0-Angriff demonstrierte eine neue Dimension: KI-Agenten, die in GitHub Actions integriert sind, verarbeiten nicht vertrauenswürdige Nutzereingaben und führen Shell-Befehle mit Zugriff auf hochprivilegierte Tokens aus. Prompt-Injection wird damit zu einem Supply-Chain-Risiko.

Pull Requests: Der unterschätzte Angriffsvektor

Pull Requests gelten oft als sicher, weil „ja jemand drüberschaut”. Die Realität 2025 sieht anders aus: Pwn Requests sind zu einem der effektivsten Einstiegspunkte geworden – und die Zahlen sind dramatisch.

Die pull_request_target-Falle

CI/CD-Systeme wie GitHub Actions, GitLab CI und CircleCI führen routinemäßig nicht vertrauenswürdigen Code aus Fork-Pull-Requests aus – mit Zugriff auf privilegierte Secrets. Das Phänomen heißt Poisoned Pipeline Execution (PPE).

Das Problem liegt im pull_request_target-Trigger:

Workflows mit diesem Trigger haben Zugriff auf alle Repository-Secrets
Das GITHUB_TOKEN hat standardmäßig Lese- und Schreibrechte
Wenn ein Workflow Code aus einem Fork auscheckt, sind alle Secrets exponiert

Microsoft vergab für Schwachstellen dieser Art einen CVSS-Score von 9.3 (kritisch).

Sicherheitsforscher fanden verwundbare pull_request_target-Workflows in Projekten von:

Google, Microsoft, NVIDIA und weiteren Fortune-500-Unternehmen
Spotipy (CVE-2025-47928, als kritisch eingestuft)
MITRE CAR (Cyber Analytics Repository)
Hochrangigen Open-Source-Projekten mit über 10.000 GitHub Stars

Das war kein isoliertes Problem, sondern ein systematisches Muster. CI/CD-Systeme sind standardmäßig so konfiguriert, dass sie nicht vertrauenswürdigen Code mit privilegierten Rechten ausführen.

Konkrete Angriffe über Pull Requests

Ethcode VS Code Extension (Juni 2025)
Ein GitHub-Nutzer „Airez299” öffnete am 17. Juni 2025 einen Pull Request gegen das Ethcode-Repository. Der Account war am gleichen Tag erstellt worden, hatte keine vorherige Aktivität – ein klassischer Wegwerf-Account. Der PR enthielt schädlichen Code, der 6.000+ Entwickler infizierte.

GhostAction (September 2025)
Am 5. September 2025 entdeckte GitGuardian einen massiven Supply-Chain-Angriff: 327 GitHub-Nutzer über 817 Repositories betroffen. Angreifer injizierten schädliche Workflows, die 3.325 Secrets exfiltrierten, darunter PyPI-, npm- und DockerHub-Tokens.

S1ngularity (August 2025)
Einer der schwersten GitHub-Supply-Chain-Kompromittierungen. Angreifer infiltrierten das Nx Build System und injizierten KI-gestützte Malware in weit verbreitete Pakete. Der Angriff nutzte kompromittierte Maintainer-Accounts und manipulierte Pull Requests.

Wie die Angriffe funktionieren

Code-Injection über PR-Metadaten:
Workflow-Dateien verwenden PR-Titel oder Commit-Messages in Shell-Befehlen. Angreifer injizieren Schadcode über diese Metadaten.
Dependency Confusion:
PR fügt schädliche Pakete mit Namen hinzu, die internen Dependencies ähneln. Package Manager laden die öffentliche (schädliche) Version mit höherer Versionsnummer.
Obfuskierte Malware:
Schädlicher Code ist absichtlich verschleiert, um bei manuellen Reviews nicht aufzufallen. Base64-Encoding, Unicode-Tricks, verschachtelte Dependencies.
Backdoor-Injection:
Angreifer platzieren Backdoors, die auch nach Schließung der ursprünglichen Schwachstelle bestehen bleiben und Remote-Zugriff ermöglichen.

Das Ausmaß des Problems

Die Statistiken für 2025 sind alarmierend:

Supply-Chain-Angriffe verdoppelt: Von 154 Events (2024) auf 297 in 2025 (+93%)
Ransomware-Angriffe: +52% auf 6.604 Angriffe
Third-Party-Breaches: Machen jetzt 30% aller Vorfälle aus (Verizon DBIR)
Software Supply Chain Failures: Höchste Inzidenzrate in OWASP Top 10 mit 5,19%
Supply Chain Attacks auf Developer Tools: +633% im Jahresvergleich

Warum Code Reviews versagen

Automatisiertes Vertrauen:
Viele Projekte mergen automatisch nach erfolgreichen CI-Checks – ohne menschliche Review.

Review-Fatigue:
Open-Source-Maintainer sind überlastet. Bei hunderten PRs pro Woche sinkt die Aufmerksamkeit.

Technische Verschleierung:
Base64-Encoding, unsichtbare Unicode-Zeichen (wie bei GlassWorm), Code-Splitting über mehrere Dateien – alles macht Reviews ineffektiv.

Vertrauensvorschuss bei bekannten Contributoren:
Kompromittierte Accounts etablierter Contributors werden nicht hinterfragt.

Transitive Dependencies:
Eine Änderung in package.json ist schnell übersehen. Niemand prüft die Dependencies der Dependencies.

Warum Entwickler besonders attraktive Ziele sind

Aus Angreifer-Sicht bieten kompromittierte Entwickler-Tools mehrere strategische Vorteile:

Zugriff auf proprietären Code
Intellectual Property, Geschäftslogik, Algorithmen – alles offen im Editor.
Zugang zu internen Systemen
Entwickler haben typischerweise weitreichende Berechtigungen in Infrastruktur und Datenbanken.
Tokens, API-Keys, Zertifikate
Lokale Entwicklungsumgebungen enthalten oft produktionsrelevante Credentials.
Automatische Skalierung
Ein erfolgreicher Angriff verbreitet sich über Teams, Projekte und Organisationen hinweg.
Vertrauensvorschuss
Tools, die „beim Arbeiten helfen”, werden selten hinterfragt.

Die kompromittierten VS Code Extensions waren in der Lage:

Quellcode und Intellectual Property zu stehlen
Kryptowährung zu minen
Tastatureingaben in Echtzeit zu erfassen
Credentials zu sammeln (NPM, GitHub, Git)
Remote-Backdoors und VNC-Server zu installieren
WLAN-Passwörter und Browser-Sitzungen zu exfiltrieren
49 verschiedene Kryptowährungs-Wallet-Extensions anzugreifen

Das systemische Problem

Es ist kein individuelles Fehlverhalten und kein Versagen einzelner Plattformen. Es ist ein strukturelles Merkmal moderner Softwareentwicklung:

Geschwindigkeit schlägt Kontrolle
DevOps-Kultur bedeutet schnelle Iteration. Tools werden installiert, weil sie Produktivität versprechen – nicht, weil sie geprüft wurden.

Bequemlichkeit schlägt Prüfung
npm install, code --install-extension, GitHub Actions aus dem Marketplace – alles mit einem Befehl. Die Einstiegshürde ist bewusst niedrig gehalten.

Tooling wird implizit vertraut
Hohe Downloadzahlen erzeugen Legitimität. Eine Extension mit 17.000 Downloads wirkt sicher. Ein npm-Paket mit Millionen wöchentlicher Downloads erst recht.

Abhängigkeiten von Abhängigkeiten
Eine durchschnittliche moderne Web-App hat Hunderte transitiver Abhängigkeiten. Niemand prüft sie alle.

Maintainer sind Menschen
Phishing funktioniert. Passwörter werden wiederverwendet. Tokens werden geleakt. Burnout führt zu nachlässigen Reviews.

Was realistisch hilft (ohne Illusionen)

Komplette Sicherheit gibt es nicht. Aber ein paar Grundsätze sind praktisch umsetzbar:

1. Tooling als Teil der Supply Chain begreifen

Entwicklungsumgebungen, Extensions, CLI-Tools, GitHub Actions – alles gehört zur Supply Chain. Behandeln Sie sie entsprechend:

SBOM (Software Bill of Materials) für Entwicklungs-Tools
CISA hat im August 2025 aktualisierte Mindestanforderungen für SBOMs veröffentlicht. Tools und Adoption erlauben heute mehr Transparenz als noch 2021. Die EU Cyber Resilience Act verlangt SBOMs in standardisiertem, maschinenlesbarem Format.
Regelmäßige Audits
Nicht nur einmal prüfen, sondern kontinuierlich. Was heute sicher ist, kann morgen kompromittiert sein.

2. Nicht alles installieren, nur weil es praktisch ist

Weniger Extensions = kleinere Angriffsfläche
Jede zusätzliche Extension erhöht das Risiko. Fragen Sie sich: Ist der Produktivitätsgewinn das Risiko wert?
Popularität ≠ Sicherheit
Hohe Downloadzahlen sind kein Sicherheitsnachweis. Sie machen ein Tool lediglich zu einem lohnenderen Ziel.

3. Phishing-resistente MFA für alle Maintainer-Accounts

GitHub empfiehlt ausdrücklich: Aktivieren Sie phishing-resistente MFA auf allen Accounts, besonders für Paketmanager wie npm, PyPI, RubyGems oder NuGet, sowie für E-Mail- und Social-Media-Accounts, die für Account-Takeover oder Phishing genutzt werden könnten.

Technologie-Standard:
Hardware-Security-Keys mit FIDO2/WebAuthn (z.B. YubiKeys, Google Titan Keys) sind der Goldstandard. Sie bieten phishing-resistente Authentifizierung, die selbst gegen ausgefeilte Angriffe schützt.

Trusted Publishing statt Tokens:
Nutzen Sie npm Trusted Publishing anstelle von Tokens. Trusted Publishing ist auch für PyPI, RubyGems und NuGet verfügbar.

Regulatory Requirements:
Unter NIST SP 800-63-4 muss AAL2 eine phishing-resistente Option anbieten, AAL3 verlangt sie mit nicht-exportierbarem Key. Bei Microsoft sind 92 % der Produktivitäts-Accounts durch phishing-resistente Methoden geschützt.

4. Abhängigkeiten pinnen und überwachen

GitHub Actions: Pinnen Sie Actions auf spezifische Commits statt auf Tags
Tags können nachträglich geändert werden. Commit-Hashes nicht.
Package Manager: Verwenden Sie Lock-Files und prüfen Sie Updates
package-lock.json, Pipfile.lock, Gemfile.lock – und bei Updates: Changelogs lesen.
NIST-Empfehlung: Digitale Provenance durch authentifizierte Attestations
Effektiver gegen fortgeschrittene Angriffe auf CI/CD-Pipelines als reine Version-Pinning.

5. Berechtigungen minimieren

GitHub Actions: Standardmäßig read-only
Vergeben Sie Schreibrechte nur dort, wo absolut nötig.
IDE-Extensions: Überprüfen Sie angeforderte Berechtigungen
Eine Syntax-Highlighting-Extension braucht keinen Netzwerkzugriff.

6. Sensible Projekte isolieren

Separate Entwicklungsumgebungen
Für Projekte mit hohem Schutzbedarf: eigene VM, eigenes Profil, minimale Tool-Ausstattung.
Keine produktiven Credentials in Entwicklungsumgebungen
Was nicht da ist, kann nicht gestohlen werden.

7. Im Team Standards definieren

Zugelassene Tools dokumentieren
Nicht jeder installiert, was ihm gefällt. Definieren Sie einen Baseline-Toolstack.
Review-Prozess für neue Tools
Wer eine neue Extension oder Library nutzen will, durchläuft einen Freigabeprozess.
Incident-Response-Plan
Was passiert, wenn ein genutztes Tool kompromittiert wird? Wer wird informiert? Welche Systeme müssen überprüft werden?

8. Die 7-Tage-Regel

GitHub-Analysen zeigen: Eine 7-tägige Wartezeit für neue Paketversionen hätte 8 von 10 großen Supply-Chain-Angriffen 2025 verhindert. Automatische Updates sind bequem – aber riskant.

Der Blick nach vorn: 2026 und darüber hinaus

Erwartungen für 2026:

Schnellere Angriffe: Initial Access wird schneller erreicht
Breitere Auswirkungen: Ein kompromittiertes Tool betrifft mehr Systeme gleichzeitig
Schwerere Eindämmung: Selbst-replizierende Mechanismen wie bei GlassWorm und Shai-Hulud 2.0 machen Incident Response komplexer

Technologische Entwicklungen:

KI-Integration erhöht Angriffsfläche: Prompt Injection in CI/CD-Pipelines
Blockchain-basierte C2-Infrastruktur: Schwerer zu blockieren als klassische Server
Automatisierte Exploit-Chains: Von Credential-Theft bis Lateral Movement

Regulatorische Entwicklungen:

EU Cyber Resilience Act: SBOM-Pflicht für Softwarehersteller
NIST SP 800-63-4: Phishing-resistente MFA als Standard
CISA-Guidance: Erhöhte Anforderungen an Software-Transparenz

Das Entwickler-Ökosystem ist die neue Frontlinie

Der bekannt gewordene VS Code-Vorfall ist kein Sonderfall, sondern ein Symptom. Er zeigt nicht, dass ein bestimmtes Tool unsicher ist, sondern dass Entwickler-Ökosysteme insgesamt zu einem strategischen Angriffsziel geworden sind.

60 Milliarden Dollar Schaden. 16.000 neue schädliche Pakete. 23.000 kompromittierte Repositories. 45 % aller Unternehmen betroffen. Das sind keine abstrakten Zahlen – das ist die neue Realität.

Wer das verstanden hat, schaut nicht mehr nur auf einzelne Plugins oder Pakete. Er betrachtet das gesamte Umfeld, in dem Software entsteht: IDE, Extensions, Package Manager, CI/CD, Dependencies, Credentials, Prozesse.

Die Frage ist nicht mehr: „Ist dieses spezifische Tool sicher?”
Die Frage ist: „Wie behandeln wir Entwicklungs-Tooling als kritischen Teil unserer Supply Chain?”

Und diese Frage verlangt nach strukturellen Antworten – nicht nach individuellen Tool-Entscheidungen.