Supply Chain Security im Mittelstand: Wenn der Angriff über den Lieferanten kommt

29. Mai 2026

Artikel teilen

Supply Chain Security, also die Absicherung der eigenen Informationssicherheit gegenüber Risiken aus der Lieferkette, zählt zu den anspruchsvollsten und am häufigsten unterschätzten Disziplinen der IT-Sicherheit im Mittelstand. Traditionelle Sicherheitsansätze konzentrieren sich auf den eigenen Perimeter: Firewall, Endpoint-Schutz, Zugangskontrolle. Doch Angreifer haben gelernt, diesen Perimeter zu umgehen, indem sie nicht das Zielunternehmen direkt angreifen, sondern über Lieferanten, Softwareanbieter oder externe Dienstleister eindringen, die legitimen Zugang zu dessen Systemen besitzen. Dieser Beitrag beschreibt Angriffsmuster, zeigt Analysemethoden auf und erläutert, wie mittelständische Unternehmen Third-Party-Risiken systematisch reduzieren können.

Warum Supply-Chain-Angriffe besonders gefährlich sind

Supply-Chain-Angriffe haben eine eigentümliche Qualität: Sie nutzen Vertrauen als Angriffsfläche. Wenn ein etablierter Softwareanbieter ein Update ausliefert, gehen Unternehmen davon aus, dass dieses Update legitim und sicher ist. Die automatische Installation von Updates ist ein empfohlenes Sicherheitsverfahren, weil es bekannte Schwachstellen schnell schließt. Genau diese berechtigte Vertrauensgrundlage macht den Supply-Chain-Angriff so wirkungsvoll: Das Schadprogramm kommt nicht als verdächtige E-Mail, sondern als reguläres Software-Update.

Öffentlich bekanntgewordene Vorfälle aus den vergangenen Jahren haben gezeigt, dass selbst gut gesicherte Organisationen durch Angriffe auf ihre Software-Lieferkette kompromittiert werden können. Für den Mittelstand kommt erschwerend hinzu, dass die Abhängigkeit von externen Software- und Dienstleistungsanbietern in der Regel hoch ist, während die Ressourcen für eine intensive Lieferantenprüfung begrenzt sind.

Angriffsmuster: Wie Angreifer die Lieferkette nutzen

Muster 1: Kompromittierter Software-Anbieter

Beim sogenannten Software-Supply-Chain-Angriff gelingt es Angreifern, in die Entwicklungs- oder Distributionsumgebung eines Software-Anbieters einzudringen und dort Schadcode einzuschleusen. Die kompromittierte Software wird dann über die normalen Update-Mechanismen an alle Kunden des Anbieters ausgeliefert. Die Schadwirkung kann dabei zunächst passiv bleiben, zum Beispiel durch stilles Ausspähen von Zugangsdaten oder Netzwerkstrukturen, und erst dann aktiviert werden, wenn der Angreifer entscheidet, die Kontrolle über bestimmte Zielsysteme zu nutzen.

Für den Mittelstand ist dieses Szenario besonders relevant bei ERP-Systemen, Cloud-Diensten, Remote-Support-Tools und Sicherheitssoftware. Ausgerechnet die Kategorie „Sicherheitssoftware“ ist ein prominentes Ziel, weil sie typischerweise mit erhöhten Systemberechtigungen ausgestattet ist.

Muster 2: Kompromittierter externer Dienstleister mit Systemzugang

Viele Mittelständler beauftragen externe IT-Dienstleister mit Wartungsaufgaben, Fernzugängen oder der Verwaltung von Systemen. Diese Dienstleister haben legitimen Zugang zu internen Systemen. Wenn der Dienstleister selbst angegriffen und kompromittiert wird, können die Angreifer diesen legitimen Zugang als Einfallstor nutzen, ohne selbst eine Schwachstelle im Zielsystem ausnutzen zu müssen. Sie melden sich einfach mit den gestohlenen Zugangsdaten des Dienstleisters an.

In der Praxis zeigt sich dieses Muster häufig bei Managed Service Providern (MSP), Steuerberatungsunternehmen mit Zugang zu ERP-Systemen, oder bei Lieferanten, die für den Bestellprozess Zugang zu internen Portalen haben.

Muster 3: Manipulierte Hardware aus der Lieferkette

Hardware-basierte Supply-Chain-Angriffe sind aufwändiger zu realisieren, aber im Bereich kritischer Infrastruktur und industrieller Steuerungssysteme dokumentiert. Dabei werden Hardwarekomponenten, zum Beispiel Netzwerkausrüstung oder industrielle Controller, bereits auf dem Weg vom Hersteller zum Kunden manipuliert, um eine versteckte Hintertür einzubauen. Für den typischen Mittelstand ist dieses Szenario weniger wahrscheinlich als Software-basierte Angriffe, aber bei Unternehmen mit industriellen Anlagen oder in sensitiven Branchen dennoch relevant.

Regulatorischer Rahmen: NIS2 und das Lieferkettenthema

Die europäische NIS2-Richtlinie, deren Umsetzung in nationales Recht in Deutschland mit dem NIS2UmsuCG erfolgte, legt betroffenen Organisationen ausdrücklich Pflichten im Bereich der Lieferkettensicherheit auf. Betroffene Einrichtungen müssen geeignete und verhältnismäßige technische und organisatorische Maßnahmen ergreifen, die unter anderem die „Sicherheit in der Lieferkette“ einschließen. Konkret bedeutet das: Unternehmen, die unter NIS2 fallen, können sich nicht mehr darauf beschränken, die eigene IT zu sichern; sie müssen auch die Sicherheitspraktiken ihrer relevanten Zulieferer berücksichtigen.

Ähnliche Anforderungen stellt im Finanzsektor die DORA-Verordnung (Digital Operational Resilience Act), die Finanzdienstleister verpflichtet, das Risiko aus IKT-Drittdienstleistern systematisch zu managen und zu dokumentieren. Auch wenn DORA unmittelbar auf Finanzunternehmen zielt, entsteht ein Ausstrahlungseffekt auf Zulieferer und Technologieanbieter dieser Unternehmen.

Für Mittelständler, die nicht direkt unter NIS2 fallen, empfiehlt sich dennoch eine freiwillige Auseinandersetzung mit den enthaltenen Anforderungen, nicht zuletzt weil Großunternehmen diese Anforderungen zunehmend vertraglich an ihre Zulieferer weitergeben.

Risikoanalyse der eigenen Lieferkette: Ein strukturierter Einstieg

Schritt 1: Kritische Drittparteien identifizieren

Der erste Schritt ist eine vollständige Inventur aller externen Parteien, die Zugang zu internen Systemen haben oder deren Leistungen für den Betrieb unverzichtbar sind. Diese Inventur ist in vielen mittelständischen Unternehmen nicht vorhanden oder unvollständig. Praktisch bietet sich die Nutzung einer einfachen Tabelle an, in der jede Drittpartei erfasst wird mit: Art des Zugangs (VPN, Web-Portal, physisch), Art der Daten oder Systeme, auf die zugegriffen wird, Zugangszeitraum (dauerhaft oder anlassbezogen), und vertragliche Grundlage.

Schritt 2: Risikoklassifizierung

Nicht jeder Lieferant stellt das gleiche Risiko dar. Eine pragmatische Klassifizierung unterscheidet zwischen drei Kategorien: kritische Drittparteien mit direktem Zugang zu sensitiven Systemen oder Daten (höchstes Risiko), wichtige Drittparteien mit indirektem Einfluss auf den Betrieb (mittleres Risiko) und Standardlieferanten ohne Systemzugang (geringes Risiko). Die Sicherheitsmaßnahmen und Prüfintensitäten richten sich nach dieser Kategorisierung.

Kategorie	Merkmale	Prüftiefe	Vertragliche Anforderungen
Kritisch	Direkter Systemzugang, Verarbeitung sensitiver Daten	Jährlich inkl. Audit-Recht	Sicherheits-SLA, Meldepflicht, Penetrationstest-Nachweis
Wichtig	Indirekter Einfluss, Zugang zu Teilsystemen	Alle 2 Jahre, Fragebogen	Datenschutzvertrag, Sicherheitszertifizierung
Standard	Kein Systemzugang, austauschbar	Einmalig bei Aufnahme	Standardkonditionen

Technische Maßnahmen zur Reduzierung von Supply-Chain-Risiken

Least-Privilege-Zugang für externe Parteien: Externe Dienstleister erhalten ausschließlich die Berechtigungen, die für ihre spezifische Aufgabe erforderlich sind, und auch das nur für den erforderlichen Zeitraum. Dauerhafte VPN-Zugänge mit weitreichenden Berechtigungen für externe Wartungsdienstleister sind ein erhebliches Risiko.

Multi-Faktor-Authentifizierung (MFA) für alle externen Zugänge: Auch wenn ein Dienstleister-Account kompromittiert wird, verhindert MFA die sofortige Ausnutzbarkeit. Dies ist eine der wirksamsten Einzelmaßnahmen gegen Account-Kompromittierungen.

Session-Monitoring bei externen Zugriffen: Zugriffe externer Parteien sollten protokolliert, im Idealfall aufgezeichnet und regelmäßig ausgewertet werden. Viele Sicherheitsvorfälle durch kompromittierte Dienstleisterzugänge werden zu spät erkannt, weil Monitoring-Mechanismen fehlen.

Netzwerksegmentierung: Externe Zugänge sollten in segmentierten Netzwerkbereichen enden, aus denen kein uneingeschränkter Zugang zum internen Netz besteht. Lateral Movement, also die Ausbreitung eines Angreifers von einem Zugangspunkt auf andere Systeme, wird durch konsequente Segmentierung erheblich erschwert.

Software Bill of Materials (SBOM): Eine SBOM ist eine strukturierte Auflistung aller in einer Software enthaltenen Komponenten, Bibliotheken und deren Versionen. Sie ermöglicht es, bei Bekanntwerden einer neuen Schwachstelle sofort zu überprüfen, ob eingesetzte Software die betroffene Komponente enthält. Softwareanbieter, die keine SBOM bereitstellen können oder wollen, sollten bei kritischen Anwendungen mit Vorsicht bewertet werden.

Vertragsgestaltung: Sicherheitsanforderungen in die Lieferkette einbetten

Technische Maßnahmen auf der eigenen Seite greifen nicht, wenn der Lieferant selbst unsicher aufgestellt ist. Deshalb ist die Vertragsgestaltung ein entscheidendes Instrument der Supply Chain Security. Für kritische Drittparteien sollten Verträge mindestens folgende Klauseln enthalten:

Sicherheitsstandards: Verpflichtung des Lieferanten zur Einhaltung definierter Sicherheitsstandards, zum Beispiel ISO 27001 oder branchenspezifische Normen.
Meldepflichten bei Sicherheitsvorfällen: Der Lieferant ist verpflichtet, sicherheitsrelevante Vorfälle unverzüglich zu melden, insbesondere wenn sie eigene Systeme oder Daten des Auftraggebers betreffen könnten. Eine Meldefrist von 24 bis 48 Stunden ist branchenüblich für kritische Vorfälle.
Audit-Recht: Das eigene Unternehmen behält sich das Recht vor, Sicherheitspraktiken des Lieferanten durch eigene Prüfer oder beauftragte Dritte zu auditieren.
Subunternehmerregelungen: Der Lieferant darf nur mit vorheriger Zustimmung Subunternehmer einsetzen, die ihrerseits vergleichbaren Sicherheitsanforderungen unterliegen.
Datenlöschung bei Vertragsende: Klare Regelungen darüber, wie und wann der Lieferant Daten des Unternehmens nach Vertragsende löscht oder zurückgibt.

„Sicherheitsverträge mit Lieferanten sind kein bürokratisches Beiwerk. Sie sind das schriftliche Fundament einer Risikoüberwälzung und eines geteilten Sicherheitsverständnisses. Ein Lieferant, der standardmäßige Sicherheitsklauseln ablehnt, gibt damit ein wichtiges Signal.“ (Sinngemäße Aussage aus IT-Sicherheitsberatung)

Kontinuierliche Überwachung: Supply Chain Security als laufender Prozess

Supply Chain Security ist kein Einmalprojekt. Lieferketten verändern sich, neue Anbieter kommen hinzu, bestehende Anbieter ändern ihre Sicherheitspraktiken, neue Schwachstellen werden bekannt. Ein nachhaltiges Third-Party-Risk-Management beinhaltet deshalb regelmäßige Überprüfungszyklen, Bewertungsrunden für neue Lieferanten, und die Auswertung von Sicherheitsmeldungen zu eingesetzten Softwareprodukten.

Für den Mittelstand, der keine eigene Sicherheitsabteilung unterhält, bieten sich spezialisierte Managed Security Service Provider an, die Third-Party-Risk-Management als Dienstleistung anbieten. Alternativ kann eine einfache Eigenstruktur aufgebaut werden: vierteljährliche Überprüfung der Lieferantenliste auf Veränderungen, jährliche Fragebogen-basierte Selbstauskunft kritischer Lieferanten, und anlassbezogene Neubewertung bei Bekanntwerden von Sicherheitsvorfällen beim Lieferanten.

FAQ

Was ist der Unterschied zwischen Supply Chain Security und klassischer Lieferantenbewertung?
Klassische Lieferantenbewertung prüft Qualität, Liefertreue und Wirtschaftlichkeit. Supply Chain Security fokussiert ausschließlich auf die Informationssicherheitspraktiken eines Lieferanten und das Risiko, das durch die Geschäftsbeziehung für die eigene IT-Sicherheit entsteht. Beide Prozesse können kombiniert werden, erfordern aber unterschiedliche Fachexpertise.

Sind kleinere Lieferanten per se risikoärmer?
Nein. Die Unternehmensgröße ist kein verlässlicher Indikator für das Sicherheitsniveau. Kleinere Dienstleister haben häufig weniger Ressourcen für IT-Sicherheit und sind damit potenziell leichter zu kompromittieren. Das Risiko für das eigene Unternehmen bestimmt sich nicht aus der Größe des Lieferanten, sondern aus dem Zugangsniveau und der Kritikalität der verarbeiteten Daten und Systeme.

Wie geht man vor, wenn ein wichtiger Lieferant Sicherheitsanforderungen ablehnt?
Zunächst sollte geklärt werden, ob die Anforderungen verhältnismäßig sind und ob es sachliche Gründe für die Ablehnung gibt. Wenn ein Lieferant grundlegende Anforderungen wie Meldepflichten oder Mindestsicherheitsstandards ablehnt, ist das ein belastbares Kriterium für eine erhöhte Risikeinstufung, die gegebenenfalls zur Lieferantenalternativensuche führen sollte. Bei unverzichtbaren Lieferanten ohne Alternative sollten kompensatorische eigene Schutzmaßnahmen verstärkt werden.

Müssen alle Lieferanten ein ISO-27001-Zertifikat vorweisen?
Eine ISO-27001-Zertifizierung ist ein starkes Signal für reife Sicherheitspraktiken, aber kein absolutes Kriterium. Für kritische Lieferanten ist ein Zertifikat oder ein gleichwertiger unabhängiger Nachweis (SOC-2-Bericht, TISAX-Nachweis) empfehlenswert. Von kleineren Dienstleistern kann stattdessen eine dokumentierte Selbstauskunft mit Nachweis grundlegender Maßnahmen als Minimum akzeptiert werden.

Was ist eine SBOM und wofür wird sie konkret benötigt?
Eine Software Bill of Materials (SBOM) listet alle Komponenten auf, aus denen eine Software besteht, einschließlich Open-Source-Bibliotheken und deren Versionsstände. Sobald eine kritische Schwachstelle in einer Komponente bekannt wird, ermöglicht eine SBOM eine sofortige Überprüfung, ob eingesetzte Produkte betroffen sind. Ohne SBOM müssen betroffene Produkte manuell recherchiert werden, was im Ernstfall Zeit kostet.

Wie können Unternehmen prüfen, ob ein Software-Update authentisch ist?
Seriöse Softwareanbieter signieren ihre Updates kryptografisch. Die Überprüfung der Signatur vor der Installation stellt sicher, dass das Update tatsächlich vom angegebenen Anbieter stammt und nicht auf dem Transportweg manipuliert wurde. In vielen Fällen übernimmt dies die Update-Software automatisch. Unternehmen sollten sicherstellen, dass eingesetzte Software mit aktivierter Signaturprüfung betrieben wird, und bei Lieferanten nachfragen, ob Update-Signaturen eingesetzt werden.

Hinweis der Redaktion: Dieser Beitrag beschreibt regulatorische Rahmenbedingungen zu NIS2 und verwandten Regelwerken in allgemeiner Form. Er stellt keine Rechts- oder Compliance-Beratung dar. Für verbindliche Aussagen zur eigenen Betroffenheit und zu Umsetzungspflichten empfehlen wir die Konsultation eines auf IT-Recht spezialisierten Rechtsanwalts.