Anatomie eines Supply-Chain-Angriffs: Eine kurze Aufschlüsselung
Die moderne Softwareentwicklung basiert auf einem Geflecht von Abhängigkeiten, Drittanbieterdiensten und automatisierten Pipelines. Jeder Verbindungspunkt stellt einen potenziellen Einstiegspunkt für Angreifer dar, die dieses Vertrauen ausnutzen, um durch eine einzige Sicherheitsverletzung Tausende von Systemen zu kompromittieren. Das Verständnis, wie diese Angriffe ablaufen, ist entscheidend für Entwickler, die sichere Systeme aufbauen.
Wichtigste Erkenntnisse
- Supply-Chain-Angriffe nutzen Vertrauensbeziehungen zwischen Organisationen und ihren Abhängigkeiten aus
- Angreifer zielen auf Package-Repositories, Build-Systeme und nicht-menschliche Identitäten ab, um bösartigen Code zu verbreiten
- Prävention erfordert Zero-Trust-Prinzipien, Dependency-Management und kontinuierliche Überwachung
- Jede Abhängigkeit und Drittanbieter-Integration sollte als potenzieller Angriffsvektor betrachtet werden
Was sind Supply-Chain-Angriffe?
Ein Supply-Chain-Angriff tritt auf, wenn Angreifer Software oder Dienste kompromittieren, von denen andere Organisationen abhängig sind, und dadurch Vertrauensbeziehungen in Angriffsvektoren verwandeln. Anstatt Opfer direkt anzugreifen, infiltrieren Angreifer vorgelagerte Anbieter – Package-Repositories, Build-Systeme oder Lieferantennetzwerke – um bösartigen Code über legitime Kanäle zu verbreiten.
Im Gegensatz zu traditionellen Sicherheitsverletzungen, die Schwachstellen in der eigenen Infrastruktur eines Ziels ausnutzen, instrumentalisieren Supply-Chain-Angriffe das implizite Vertrauen zwischen Organisationen und ihren Abhängigkeiten. Wenn Entwickler ein Paket installieren, ein Update anwenden oder einen Drittanbieterdienst integrieren, gehen sie davon aus, dass es sicher ist. Angreifer nutzen genau diese Annahme aus.
Der Angriffs-Lebenszyklus: Vom Einstieg bis zur Auswirkung
Initialer Zugang über vertrauenswürdige Kanäle
Angreifer erlangen typischerweise initialen Zugang durch Kompromittierung von:
- Open-Source-Paketen über bösartige Beiträge oder Account-Übernahmen
- Build-Pipelines, in denen Code kompiliert und signiert wird
- Update-Mechanismen, die Software an Endbenutzer verteilen
- Lieferantensystemen mit privilegiertem Zugang zu Kundenumgebungen
Der SolarWinds-Angriff veranschaulichte diesen Ansatz beispielhaft. Angreifer injizierten die SUNBURST-Backdoor in den Build-Prozess von Orion und stellten sicher, dass der bösartige Code legitime digitale Signaturen erhielt. Über 18.000 Organisationen installierten dieses trojanisierte Update im Vertrauen auf den standardmäßigen Release-Prozess von SolarWinds.
Laterale Bewegung und Persistenz
Sobald Angreifer drin sind, nutzen sie ihren Brückenkopf, um den Zugang zu erweitern. Nicht-menschliche Identitäten – API-Keys, OAuth-Tokens, Service-Accounts – werden zu bevorzugten Zielen. Diese Credentials haben oft übermäßige Berechtigungen und unterliegen nicht der Überwachung, die auf Benutzerkonten angewendet wird.
Der Okta-Breach demonstriert dies perfekt. Angreifer stahlen Credentials aus Oktas Support-System und nutzten dann übersehene Service-Account-Tokens, um Monate später Kundensysteme zu kompromittieren. Trotz der Rotation von Tausenden von Credentials übersahen Organisationen kritische Tokens – genug für Angreifer, um wieder Zugang zu erlangen.
Persistenzmechanismen bei Supply-Chain-Breaches umfassen häufig:
- Backdoored Dependencies, die sich bei jedem Build neu installieren
- Modifizierte CI/CD-Konfigurationen, die bösartigen Code injizieren
- Kompromittierte Signaturzertifikate für zukünftige „legitime” Releases
Datenexfiltration und Auswirkungen
Die letzte Phase variiert je nach Motivation der Angreifer. Nationalstaatliche Akteure wie die hinter SolarWinds konzentrieren sich auf langfristige Spionage und exfiltrieren stillschweigend sensible Daten. Ransomware-Gruppen, wie beim Kaseya-Angriff zu sehen, priorisieren sofortige Störungen – sie verschlüsseln Systeme in 1.500 Unternehmen durch kompromittierte MSP-Infrastruktur.
Moderne Angriffsvektoren
Dependency Confusion und Paketmanipulation
Dependency-Confusion-Angriffe nutzen falsch konfigurierte Package-Manager aus, die öffentliche Repositories vor privaten prüfen. Angreifer veröffentlichen bösartige Pakete mit Namen, die internen Firmenpaketen entsprechen. Wenn Build-Systeme Abhängigkeiten abrufen, laden sie versehentlich die Version des Angreifers herunter.
Das npm-Ökosystem sieht sich ständigen Bedrohungen ausgesetzt durch:
- Typosquatting: Pakete mit Namen ähnlich zu beliebten Bibliotheken (z.B.
python-dateutilvs.python-dateutl) - Bösartige Updates: Legitime Pakete, die durch Maintainer-Account-Übernahmen kompromittiert wurden
- Protestware: Pakete, die absichtlich von ihren eigenen Maintainern sabotiert wurden
Kompromittierte Build-Pipelines
CI/CD-Systeme stellen hochwertige Ziele dar. Eine einzige Pipeline-Kompromittierung kann Malware in jeden Build injizieren, ohne den Quellcode zu berühren. Angreifer zielen ab auf:
- GitHub Actions Workflows, die mit Repository-Secrets ausgeführt werden
- Jenkins-Server mit veralteten Plugins oder schwacher Authentifizierung
- Container-Registries, die Basis-Images hosten, die organisationsweit verwendet werden
Der Codecov-Breach infizierte Kunden-CI/CD-Pipelines monatelang und sammelte Umgebungsvariablen und Credentials aus Build-Prozessen.
Ausnutzung nicht-menschlicher Identitäten
OAuth-Apps und Service-Accounts vermehren sich ohne Aufsicht. Untersuchungen zeigen, dass 1 von 10 OAuth-Apps, die mit Google Workspace verbunden sind, administrative Berechtigungen haben. Diese nicht-menschlichen Identitäten:
- Bleiben nach dem Ausscheiden von Mitarbeitern bestehen
- Verfügen nicht über Multi-Faktor-Authentifizierung
- Haben Berechtigungen über ihre tatsächlichen Bedürfnisse hinaus
- Erzeugen keine Warnmeldungen, wenn sie kompromittiert werden
Discover how at OpenReplay.com.
Präventionsprinzipien für Entwickler
Die Verteidigung gegen Supply-Chain-Angriffe erfordert einen Wechsel von Perimeter-Sicherheit zu Zero-Trust-Prinzipien:
Dependency-Management
- Exakte Versionen festlegen statt Bereiche zu verwenden
- Paketsignaturen und Checksummen verifizieren
- Private Registries mit strikten Zugriffskontrollen verwenden
- Software Bill of Materials (SBOM)-Tracking implementieren
Pipeline-Sicherheit
- Build-Umgebungen von Produktionsnetzwerken isolieren
- CI/CD-Secrets regelmäßig rotieren
- Artefakte mit Tools wie Sigstore signieren
- Mit TruffleHog nach Secrets im Code scannen
Identity Governance
- OAuth-App-Berechtigungen monatlich prüfen
- Just-in-Time-Zugriff für Service-Accounts implementieren
- API-Key-Nutzungsmuster überwachen
- Ungenutzte nicht-menschliche Identitäten sofort widerrufen
Fazit
Supply-Chain-Angriffe sind erfolgreich, weil sie grundlegende Annahmen über Vertrauen in der Softwareentwicklung ausnutzen. Dieselben Mechanismen, die schnelle Entwicklung ermöglichen – Package-Manager, automatisierte Pipelines, Drittanbieter-Integrationen – werden zu Waffen, wenn sie kompromittiert werden.
Schutz erfordert, jede Abhängigkeit, jeden Build-Prozess und jede Drittanbieter-Integration als potenziellen Angriffsvektor zu behandeln. Gehen Sie von einer Kompromittierung aus, verifizieren Sie kontinuierlich und begrenzen Sie den Explosionsradius durch geeignete Segmentierung und Least-Privilege-Zugriff. Die Frage ist nicht, ob Ihre Abhängigkeiten heute sicher sind, sondern ob Sie wissen werden, wann sie morgen kompromittiert werden.
Häufig gestellte Fragen
Überwachen Sie unerwartete Netzwerkverbindungen, Dateisystemänderungen oder neue Prozesse, die von Abhängigkeiten gestartet werden. Verwenden Sie regelmäßig Tools wie npm audit oder pip-audit. Verfolgen Sie Dependency-Updates und überprüfen Sie Changelogs. Richten Sie Warnmeldungen für ungewöhnliches Verhalten in Produktionssystemen ein, das auf kompromittierte Pakete hindeuten könnte.
Typosquatting verleitet Entwickler dazu, Pakete mit ähnlichen Namen wie legitime Pakete durch Rechtschreibfehler zu installieren. Dependency Confusion nutzt Package-Manager-Konfigurationen aus, um bösartige öffentliche Pakete anstelle privater interner Pakete zu installieren, indem identische Namen mit höheren Versionsnummern verwendet werden.
Nein, Open Source zu vermeiden ist weder praktikabel noch notwendig. Prüfen Sie stattdessen Abhängigkeiten sorgfältig, verwenden Sie nur das, was Sie benötigen, halten Sie sie aktuell und implementieren Sie Security-Scanning. Wählen Sie gut gewartete Projekte mit aktiven Communities und erwägen Sie die Verwendung kuratierter Registries oder Enterprise-Package-Manager mit zusätzlichen Sicherheitskontrollen.
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
