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 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, klärt sich mit SBOMs schnell, welche Produkte und Systeme betroffen sind. Regulatorisch werden solche Stücklisten zunehmend gefordert, 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.
Ablauf eines Angriffs
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, stufen Prüfmechanismen ihn als vertrauenswürdig ein.
- 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 das Risiko ernst zu nehmen ist
- Ein einziger kompromittierter Zulieferer kann viele Organisationen gleichzeitig treffen; die Auswahl der Opfer trifft der Angreifer nachgelagert.
- Der Schadcode stammt 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 erläutert der Glossareintrag zu NIS-2.
- Auch vertraglich wächst der Druck, weil Kunden Sicherheitsanforderungen zunehmend an ihre Lieferanten weiterreichen.
Typische Praxisfälle
- 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.
Abgrenzung zum direkten 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 genügt nicht. 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.
Schadensbegrenzung in der Praxis
Die Kompromittierung eines Zulieferers lässt sich von außen nicht verhindern – umso wichtiger ist eine Architektur, die den Wirkradius begrenzt. Segmentierung isoliert 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 stellen Zero-Trust-Zugriffsmodelle sicher, dass externe Partner definierte Anwendungen erreichen statt ganzer Netzsegmente. In der Praxis übernehmen spezialisierte Managed-Service-Provider Aufbau und Betrieb solcher Kontrollen, etwa mit gemanagter Zero-Trust-Mikrosegmentierung. Ein Lieferkettenvorfall bleibt so ein begrenztes Ereignis statt eines Totalausfalls.
Häufige Fragen
Was ist eine SBOM und wozu dient sie?
Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Stückliste, die alle Komponenten einer Software samt Version aufführt, inklusive Open-Source-Bibliotheken. Wird eine Schwachstelle in einer Komponente bekannt, zeigt die SBOM sofort, welche Anwendungen betroffen sind. Ohne diese Transparenz dauert die Betroffenheitsanalyse nach einem Vorfall oft Tage. Kunden und Regulierer verlangen SBOMs zunehmend von Herstellern.
Worin unterscheiden sich Software- und Dienstleister-Lieferkette?
Die Software-Lieferkette betrifft den Code selbst: Bibliotheken, Build-Systeme und Update-Wege, über die Schadcode in Produkte gelangt und sich an alle Kunden verteilt. Die Dienstleister-Lieferkette betrifft Zugänge: IT-Dienstleister, Wartungsfirmen oder Partner mit Netzkopplung, deren legitime Verbindungen Angreifer übernehmen. Beide Wege umgehen den Perimeter, verlangen aber unterschiedliche Gegenmaßnahmen – von SBOM und Update-Kontrolle bis zu streng begrenzten Fernzugängen.
Was verlangt NIS-2 beim Thema Lieferkette?
NIS-2 verpflichtet betroffene Unternehmen, die Sicherheit ihrer Lieferkette aktiv zu managen. Dazu gehören die Bewertung der Sicherheitsniveaus direkter Zulieferer und Dienstleister, vertragliche Sicherheitsanforderungen sowie die Berücksichtigung von Schwachstellen einzelner Anbieter im eigenen Risikomanagement. Die Pflicht wirkt in die Breite: Auch Firmen, die selbst nicht unter NIS-2 fallen, bekommen die Anforderungen von ihren Kunden weitergereicht.
Wie lässt sich die eigene Betroffenheit bei einem bekannt gewordenen Lieferkettenvorfall feststellen?
Grundlage ist ein aktuelles Inventar: Welche Software, Versionen und Dienstleisterzugänge sind im Einsatz? SBOMs beschleunigen den Abgleich mit Herstellerangaben erheblich. Anschließend gilt es, die Advisories des Herstellers und einschlägige Warnungen etwa des BSI zu prüfen und in Protokollen nach den veröffentlichten Kompromittierungsindikatoren zu suchen. Ohne Inventar bleibt eine aufwendige manuelle Suche, während das Zeitfenster für Angreifer offen steht.
Welche Maßnahmen begrenzen den Schaden eines Supply-Chain-Angriffs?
Sinnvoll ist die Annahme, dass einzelne Komponenten oder Partner kompromittiert werden können – und die Begrenzung der Folgen: Netzwerksegmentierung hält betroffene Systeme isoliert, Dienstleisterzugänge erhalten minimale Rechte über kontrollierte Übergänge, Updates werden gestaffelt ausgerollt statt überall gleichzeitig. Ergänzend helfen Monitoring auf ungewöhnliche Verbindungen und geübte Notfallprozesse, damit die Trennung betroffener Systeme schnell gelingt.