Unternehmen sichern ihre eigenen Systeme immer besser ab. Angreifer weichen deshalb auf einen leiseren Weg aus: Sie kompromittieren Software-Hersteller oder Dienstleister und lassen sich von dort mit gültigen Signaturen und legitimen Zugängen zu ihren eigentlichen Zielen tragen. Ein Supply-Chain-Angriff missbraucht damit das Wertvollste in jeder Geschäftsbeziehung: Vertrauen.
Was ist ein Supply-Chain-Angriff?
Ein Supply-Chain-Angriff (Lieferkettenangriff) richtet sich gegen ein Unternehmen über dessen Zulieferer. Statt die gut geschützte Zielorganisation direkt anzugreifen, kompromittiert der Angreifer ein schwächeres Glied in der Lieferkette und nutzt die bestehende Vertrauensbeziehung als Einfallstor: automatische Updates, signierten Code, Fernwartungszugänge oder Datenanbindungen.
Zwei Ausprägungen sind zu unterscheiden. Die Software-Lieferkette umfasst alles, woraus Anwendungen entstehen: Open-Source-Bibliotheken, Entwicklungswerkzeuge, Build-Systeme und Update-Mechanismen. Wird hier Schadcode eingeschleust, verteilt er sich über reguläre Releases an alle Kunden. Die Dienstleister-Lieferkette betrifft Firmen mit Zugang zu Systemen oder Daten: IT-Dienstleister, Wartungsfirmen, Cloud-Anbieter oder Zulieferer mit Netzkopplung. Hier wird ein legitimer Zugang zum Angriffsweg.
Transparenz beginnt bei der Inventur: Eine SBOM (Software Bill of Materials) listet wie eine Stückliste auf, aus welchen Komponenten eine Software besteht. Wird in einer Bibliothek eine Schwachstelle bekannt, lässt sich mit SBOMs schnell klären, welche Produkte und Systeme betroffen sind. Gefordert werden solche Stücklisten zunehmend auch regulatorisch, etwa im europäischen Cyber Resilience Act für Hersteller vernetzter Produkte. Für Einkauf und Betrieb wird die SBOM damit zum normalen Bestandteil von Ausschreibungen und Vertragsanhängen.
So läuft ein Angriff ab
Die meisten Fälle folgen einem wiederkehrenden Muster:
- Einbruch beim Zulieferer: Der Angreifer kompromittiert einen Software-Hersteller oder Dienstleister, häufig über gestohlene Zugangsdaten oder Schwachstellen in dessen Infrastruktur.
- Manipulation des Produkts: In Build-Systeme, Update-Server oder Code-Pakete wird Schadcode eingeschleust. Trägt er die gültige Signatur des Herstellers, wirkt er für Prüfmechanismen vertrauenswürdig.
- Verteilung über legitime Kanäle: Die Kunden installieren das manipulierte Update oder Paket im regulären Betrieb. Klassische Schutzmaßnahmen schlagen selten an, weil Quelle und Signatur stimmen.
- Selektive Aktivierung: Die eingebaute Hintertür meldet sich beim Angreifer. Der wählt aus den betroffenen Organisationen die lohnenden Ziele aus und beginnt dort mit Ausbreitung und Datenabfluss.
- Weg über Dienstleisterzugänge: Alternativ missbraucht der Angreifer Fernwartungszugänge oder stehende Netzkopplungen eines kompromittierten Dienstleisters und steht damit direkt im Kundennetz.
Auffällig ist die Geduld dieser Angriffe: Zwischen dem Einbruch beim Zulieferer und der Aktivierung beim Endziel können Monate liegen. Eine einmalige Sicherheitsprüfung des Lieferanten reicht deshalb selten aus. Entscheidend ist der laufende Blick darauf, was dessen Software und Zugänge im eigenen Netzwerk tatsächlich tun und mit wem sie kommunizieren.
Warum Schutz vor Supply-Chain-Angriffen wichtig ist
- Ein einziger kompromittierter Zulieferer kann viele Organisationen gleichzeitig treffen, die Auswahl der Opfer trifft der Angreifer nachgelagert.
- Der Schadcode kommt aus vertrauenswürdiger Quelle und passiert damit Kontrollen, die auf externe Angriffe ausgelegt sind.
- Moderne Anwendungen bestehen zu großen Teilen aus Fremdkomponenten, deren Herkunft und Pflegezustand selten vollständig bekannt sind.
- Fernwartungs- und Dienstleisterzugänge führen oft tief in interne Netze und werden seltener überwacht als externe Zugänge.
- Die NIS-2-Richtlinie verpflichtet betroffene Unternehmen ausdrücklich, Risiken in der Lieferkette zu bewerten und zu behandeln, Details erklärt unser Glossarartikel zu NIS-2 .
- Auch vertraglich wächst der Druck, weil Kunden Sicherheitsanforderungen zunehmend an ihre Lieferanten weiterreichen.
Typische Szenarien
- Ein manipuliertes Update einer verbreiteten IT-Management-Software installiert eine Hintertür bei allen Kunden, ausgenutzt wird sie bei ausgewählten Zielen.
- Ein beliebtes Open-Source-Paket wechselt den Betreuer, kurz darauf enthält eine neue Version Code, der Zugangsdaten ausleitet.
- Angreifer übernehmen die Fernwartungssoftware eines IT-Dienstleisters und verschlüsseln anschließend die Systeme von dessen Kunden.
- Über die Netzkopplung eines Logistikpartners gelangen Angreifer in das Produktionsnetz eines Herstellers.
- Eine kompromittierte Build-Pipeline signiert Schadcode mit dem offiziellen Zertifikat des Herstellers.
Supply-Chain-Angriff vs. direkter Angriff
Beim direkten Angriff sucht der Angreifer Schwachstellen in der Infrastruktur des Ziels, etwa exponierte Dienste oder ungepatchte Systeme. Dagegen helfen Perimeterschutz, Patching und eigene Härtung. Der Supply-Chain-Angriff umgeht diese Verteidigung, weil er über einen Kanal kommt, dem das Ziel technisch und organisatorisch vertraut. Für die Verteidigung heißt das: Prävention an der Außengrenze reicht nicht aus. Es braucht Transparenz über Abhängigkeiten und minimale Rechte für Dritte, dazu eine Architektur, die den Schaden begrenzt, wenn vertrauenswürdige Software oder Partner kompromittiert sind.
Schutz vor Supply-Chain-Angriffen bei KAEMI
Vollständig verhindern lässt sich die Kompromittierung eines Zulieferers von außen nicht. Umso wichtiger ist eine Architektur, die den Wirkradius begrenzt. Mit Zero Trust Mikrosegmentierung isoliert KAEMI Systeme und Dienstleisterzugänge so, dass eine Hintertür in einer einzelnen Software keinen Weg durch das gesamte Netzwerk öffnet: Jede Verbindung braucht eine explizite Freigabe, Wartungszugriffe bleiben auf das Nötigste beschränkt. Ergänzend stellt SASE/SSE sicher, dass externe Partner definierte Anwendungen erreichen statt ganzer Netzsegmente. So bleibt ein Lieferkettenvorfall ein begrenztes Ereignis statt eines Totalausfalls.