Lieferkettensicherheit: Was sie ist, warum sie wichtig ist und wie man Lieferkettenrisiken managt

Lieferkettensicherheit adressiert die Cybersicherheitsrisiken, die durch das Netzwerk von Lieferanten, Anbietern und Dienstleistern einer Organisation entstehen. Da Organisationen zunehmend von komplexen Ökosystemen aus Drittsoftware, Cloud-Diensten und IT-Anbietern abhängen, ist die Lieferkette zu einem der am häufigsten ausgenutzten Angriffsvektoren geworden.

Für B2B-Unternehmen ist Lieferkettensicherheit sowohl eine Verteidigungspriorität als auch eine Compliance-Pflicht. NIS2, DORA und der Cyber Resilience Act schreiben alle spezifische Lieferkettensicherheitsmaßnahmen vor. Enterprise-Käufer bewerten routinemäßig die Lieferkettensicherheitspraktiken ihrer Anbieter vor Vertragsabschluss.

Dieser Leitfaden behandelt, was Lieferkettensicherheit ist, warum Angriffe zunehmen, zentrale Risikokategorien, regulatorische Anforderungen und wie man ein resilientes Lieferkettensicherheitsprogramm aufbaut.

Warum Lieferkettensicherheit wichtig ist

Die wachsende Bedrohung

Lieferkettenangriffe haben erheblich zugenommen, weil sie Angreifern einen Multiplikatoreffekt bieten — die Kompromittierung eines Lieferanten kann gleichzeitig Zugang zu allen Kunden dieses Lieferanten verschaffen.

Angriffsvektor	Beschreibung	Beispiel
Software-Lieferkette	Kompromittierung von Software-Updates oder Build-Systemen	SolarWinds Orion (2020)
Managed Service Provider	Ausnutzung des MSP-Zugangs zu Kundenumgebungen	Kaseya VSA (2021)
Open-Source-Abhängigkeiten	Einschleusung von Schadcode in weit verbreitete Bibliotheken	Log4Shell (2021)
Hardware-Lieferkette	Manipulation von Hardware während Fertigung oder Vertrieb	Kompromittierte Netzwerkgeräte
Cloud-Service-Provider	Ausnutzung von Cloud-Plattform-Schwachstellen oder -Fehlkonfigurationen	Cloud-Provider-API-Schlüsseldiebstahl
SaaS-Integrationen	Kompromittierung von SaaS-Anwendungen mit Zugang zu Kundendaten	OAuth-Token-Missbrauch

Warum traditionelle Sicherheit nicht ausreicht

Vertrauenswürdiger Zugang — Lieferanten haben oft privilegierten Zugang, der Perimeterkontrollen umgeht
Eingeschränkte Sichtbarkeit — Organisationen können die Sicherheitspraktiken von Lieferanten nicht direkt kontrollieren
Kaskadeneffekt — Eine einzelne Lieferanten-Kompromittierung kann Tausende nachgelagerte Organisationen betreffen
Abhängigkeitskomplexität — Moderne Software basiert auf tiefen Abhängigkeitsketten, die schwer zu auditieren sind
Regulatorische Exposition — Organisationen werden unter NIS2, DORA und anderen Vorschriften für Lieferkettenrisiken verantwortlich gemacht

Kategorien von Lieferkettenrisiken

Technologierisiken

Risikokategorie	Beispiele
Software-Schwachstellen	Ungepatchte Abhängigkeiten, bekannte CVEs in Drittanbieter-Bibliotheken
Schadcode-Einschleusung	Hintertüren in Software-Updates, kompromittierte Build-Pipelines
Konfigurationsschwächen	Unsichere Standardeinstellungen, übermäßig freizügiger API-Zugang
Daten-Exposition	Unzureichende Verschlüsselung, unsachgemäße Datenhandhabung durch Lieferanten
Zugriffskontrolllücken	Übermäßige Berechtigungen, gemeinsam genutzte Anmeldedaten, fehlende MFA

Operationelle Risiken

Risikokategorie	Beispiele
Lieferantenausfall	Anbieter geht in Insolvenz, Diensteinstellung
Konzentrationsrisiko	Übermäßige Abhängigkeit von einem einzelnen Lieferanten für kritische Dienste
Geografisches Risiko	Lieferanten in Rechtsräumen mit unterschiedlichen Datenschutzstandards
Subunternehmer-Risiko	Die eigene Lieferkette des Lieferanten führt zusätzliche Risiken ein
Verfügbarkeitsrisiko	Lieferantenausfälle beeinträchtigen die Geschäftskontinuität

Regulatorische Anforderungen

NIS2 — Lieferkettensicherheit

NIS2 Artikel 21(2)(d) verlangt von wesentlichen und wichtigen Einrichtungen, Maßnahmen zur Lieferkettensicherheit umzusetzen:

Bewertung der Sicherheitslage von direkten Lieferanten und Dienstleistern
Bewertung lieferantenspezifischer Schwachstellen
Bewertung der Gesamtqualität und Resilienz von Produkten und Diensten
Bewertung der Cybersicherheitspraktiken von Lieferanten einschließlich sicherer Entwicklungsverfahren
Teilnahme an koordinierten Sicherheitsrisikobewertungen für kritische Lieferketten

Sanktionen: Bis zu 10 Millionen EUR oder 2% des weltweiten Jahresumsatzes.

DORA — IKT-Drittparteien-Risikomanagement

DORA Artikel 28-30 schreiben ein umfassendes IKT-Drittparteien-Risikomanagement vor:

Anforderung	DORA-Artikel
IKT-Drittparteien-Risikostrategie	Artikel 28 — Strategie und Richtlinie für IKT-Drittparteien-Risiko pflegen
Vorvertragliche Bewertung	Artikel 28 — Risiken vor Vertragsschluss bewerten
Vertragliche Anforderungen	Artikel 30 — Spezifische Sicherheitsklauseln in IKT-Verträge aufnehmen
Konzentrationsrisiko	Artikel 29 — Abhängigkeit von kritischen Anbietern überwachen und steuern
Register der Vereinbarungen	Artikel 28 — Register aller IKT-Drittparteien-Vereinbarungen führen
Exit-Strategien	Artikel 28 — Exit-Pläne für kritische IKT-Dienste entwickeln

ISO 27001 — Lieferantenbeziehungen

ISO 27001 Anhang A enthält spezifische Kontrollen für die Lieferantensicherheit:

Kontrolle	Beschreibung
A.5.19	Informationssicherheit in Lieferantenbeziehungen
A.5.20	Berücksichtigung der Informationssicherheit in Lieferantenvereinbarungen
A.5.21	Management der Informationssicherheit in der IKT-Lieferkette
A.5.22	Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten
A.5.23	Informationssicherheit bei der Nutzung von Cloud-Diensten

Aufbau eines Lieferkettensicherheitsprogramms

Schritt 1: Lieferanten inventarisieren und klassifizieren

Alle Drittparteien-Beziehungen identifizieren (Software, Dienste, Infrastruktur, Datenverarbeitung)
Lieferanten nach Kritikalität klassifizieren: kritisch, hoch, mittel, niedrig
Datenflüsse und Zugriffsebenen für jeden Lieferanten dokumentieren
Abhängigkeiten und Single Points of Failure dokumentieren

Schritt 2: Lieferantenrisiken bewerten

Bewertungsmethode	Anwendungsfall
Sicherheitsfragebögen	Erstbewertung und regelmäßige Überprüfungen
Zertifizierungsprüfung	ISO 27001, SOC 2 oder andere relevante Zertifizierungen verifizieren
Penetrationstestberichte	Technische Sicherheitslage bewerten
Kontinuierliche Überwachung	Laufende Verfolgung von Sicherheitslage-Änderungen
Vor-Ort-Audits	Kritische Lieferanten mit risikoreichen Zugriffen
Trust-Center-Prüfung	Self-Service-Zugang zur Sicherheitsdokumentation des Lieferanten

Schritt 3: Vertragliche Anforderungen definieren

In Lieferantenvereinbarungen aufnehmen:

Sicherheitskontrollanforderungen gemäß Ihrem Compliance-Framework
Fristen für Vorfallmeldung (24-72 Stunden, abgestimmt auf NIS2/DORA)
Recht auf Auditierung oder Erhalt unabhängiger Prüfberichte
Datenschutzpflichten einschließlich Residenz und Verschlüsselung
Genehmigung und Sicherheitsanforderungen für Subunternehmer
Business Continuity und Exit-Bestimmungen
Haftung und Freistellung bei Sicherheitsverletzungen

Schritt 4: Kontinuierliche Überwachung implementieren

Sicherheitslage von Lieferanten durch automatisierte Tools und regelmäßige Reviews überwachen
Sicherheitsratings, Breach-Offenlegungen und Schwachstellenberichte verfolgen
Compliance-Status und Zertifizierungserneuerungen der Lieferanten überprüfen
Konzentrationsrisiko bei kritischen Diensten überwachen
Regelmäßigen Review-Rhythmus etablieren: vierteljährlich für kritische Lieferanten, jährlich für andere

Schritt 5: Auf Lieferkettenvorfälle vorbereiten

Incident-Response-Verfahren für Lieferketten-Kompromittierungen definieren
Kommunikationskanäle mit kritischen Lieferanten für Sicherheitsvorfälle einrichten
Eskalationspfade und Entscheidungsbefugnisse dokumentieren
Tabletop-Übungen zur Simulation von Lieferkettenangriffen durchführen
Exit-Pläne und alternative Lieferanten für kritische Dienste vorhalten

Software-Lieferkettensicherheit

Zentrale Praktiken

Praktik	Beschreibung
SBOM-Management	Software Bill of Materials mit allen Komponenten und Abhängigkeiten pflegen
Abhängigkeitsscan	Drittanbieter-Bibliotheken kontinuierlich auf bekannte Schwachstellen scannen
Code-Signierung	Softwareintegrität durch kryptographische Signaturen verifizieren
Build-Pipeline-Sicherheit	CI/CD-Pipelines gegen Manipulation und unbefugten Zugriff absichern
Artefakt-Verifizierung	Herkunft und Integrität von Software-Artefakten validieren
Lizenz-Compliance	Open-Source-Lizenzen verfolgen, um rechtliches Risiko zu managen

SLSA-Framework

Supply chain Levels for Software Artifacts (SLSA) bietet ein Reifegradmodell:

Stufe	Anforderungen
Stufe 1	Dokumentation des Build-Prozesses, Herkunftsnachweis-Generierung
Stufe 2	Gehostete Quell- und Build-Plattformen, authentifizierter Herkunftsnachweis
Stufe 3	Gehärtete Build-Plattform, nicht fälschbarer Herkunftsnachweis

Wie Orbiq die Lieferkettensicherheit unterstützt

Trust Center: Veröffentlichen Sie Ihre Lieferkettensicherheitslage — Lieferantenmanagement-Richtlinien, Bewertungsprozesse und Compliance-Status für Käufer-Self-Service
KI-gestützte Fragebögen: Automatische Beantwortung von Lieferkettensicherheitsfragen in Lieferantenbewertungen anhand Ihrer dokumentierten Kontrollen
Kontinuierliches Monitoring: Verfolgen Sie Lieferanten-Compliance und Sicherheitslage-Änderungen in Ihrem Lieferanten-Ökosystem
Evidenz-Management: Zentralisieren Sie Lieferantenbewertungen, Verträge, Zertifizierungen und Prüfberichte als Compliance-Nachweise

Weiterführende Informationen

Drittparteien-Risikomanagement — Aufbau eines umfassenden TPRM-Programms
Lieferanten-Risikobewertung — Bewertung der Sicherheitslage von Lieferanten
NIS2 Compliance — Erfüllung der NIS2-Lieferkettensicherheitsanforderungen
DORA Compliance — DORA-Pflichten zum IKT-Drittparteien-Risikomanagement
Incident Response — Koordination der Incident Response in der Lieferkette

Dieser Leitfaden wird vom Orbiq-Team gepflegt. Letzte Aktualisierung: März 2026.