← Zurück zum Blog
Supply Chain ⏱️ 12 Min. Lesezeit

Lieferkettensicherheit unter NIS2: Haftung für Schwachstellen Ihrer Lieferanten

NIS2 Artikel 21 führt eine revolutionäre Haftungsregelung ein: Sie sind für Cybersecurity-Schwachstellen Ihrer Lieferanten verantwortlich. Das betrifft nicht nur Ihre Cloud-Provider und Outsourcing-Partner—sondern auch jede einzelne Open-Source-Bibliothek in Ihrer Software. Ein detaillierter Leitfaden zur Third-Party-Liability im deutschen Rechtskontext.


⚖️ Was sagt NIS2 Artikel 21 genau?

Die NIS2-Richtlinie (EU 2022/2555), Artikel 21 verpflichtet wesentliche und wichtige Einrichtungen zur "Bewertung und Bewältigung der Risiken, die sich aus den Beziehungen zu Lieferanten und Dienstleistern ergeben."

📜 NIS2 Artikel 21 (Auszug, deutsche Fassung)

"Wesentliche und wichtige Einrichtungen ergreifen geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, um Risiken für die Sicherheit von Netz- und Informationssystemen zu bewältigen, einschließlich Maßnahmen zur Bewältigung der Risiken in Bezug auf die Beziehungen zwischen den Einrichtungen und ihren direkten Lieferanten oder Dienstleistern sowie zur Bewältigung der Risiken in Bezug auf die Lieferkette als Ganzes."

Quelle: Amtsblatt der Europäischen Union L 333/80, 27. Dezember 2022

Im Klartext: Wenn Ihr Lieferant kompromittiert wird und das zu einem Sicherheitsvorfall bei Ihnen führt, haften Sie.

Was zählt als "Lieferant" oder "Dienstleister"?

Das BSI interpretiert den Begriff weit. Erfasst sind:

Besonders brisant: Auch transitive Dependencies zählen. Wenn Ihre Software library-a verwendet, die wiederum library-b importiert, haften Sie für Schwachstellen in library-b—selbst wenn Sie nichts von deren Existenz wussten.

🧨 Warum das ein Paradigmenwechsel ist

Bisherige Rechtslage: "Caveat emptor"

Traditionell galt im IT-Recht: Caveat emptor ("Käufer, pass auf"). Wenn Sie Software eines Drittanbieters einsetzten und diese eine Schwachstelle hatte, war das Ihr Problem. Haftungsausschlüsse in Software-Lizenzen ("as-is", "no warranty") waren Standard und rechtlich weitgehend wirksam.

NIS2: Umkehr der Beweislast

NIS2 kehrt das um. Jetzt gilt: Sie müssen nachweisen, dass Sie angemessene Maßnahmen zur Risikobewältigung ergriffen haben. Bei einem Sicherheitsvorfall aufgrund einer Lieferantenschwachstelle reicht es nicht zu sagen: "Wir haben dem Anbieter vertraut."

Das BSI wird fragen:

Wenn Sie diese Fragen nicht mit "Ja" beantworten können, drohen Bußgelder—selbst wenn kein Sicherheitsvorfall eingetreten ist.

🇩🇪 Deutsche Umsetzung: NIS2UmsuCG und IT-SiG 3.0

Deutschland setzt NIS2 durch das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) und Änderungen am IT-Sicherheitsgesetz 3.0 (IT-SiG 3.0) um. Die Gesetze verschärfen die EU-Anforderungen teilweise noch:

⚠️ Verschärfungen im deutschen Right

📊 Reales Beispiel: SolarWinds-Szenario unter NIS2

Der SolarWinds-Hack von 2020 ist das Paradebeispiel für Supply-Chain-Angriffe. Angreifer kompromittierten den Update-Server von SolarWinds Orion, einer weit verbreiteten IT-Management-Software. 18.000 Organisationen installierten die trojanisierte Version—darunter US-Regierungsbehörden, Fortune-500-Unternehmen und kritische Infrastrukturbetreiber.

Was wäre unter NIS2 passiert?

Angenommen, ein deutsches Energieunternehmen (wesentliche Einrichtung unter NIS2) hätte SolarWinds Orion im Einsatz gehabt:

Szenario-Phase NIS2-Anforderung Potenzielle Konsequenz bei Nicht-Erfüllung
Vor dem Angriff Lieferantenbewertung: Ist SolarWinds Orion in der Lieferantenliste? Wurde deren Sicherheitszertifizierung geprüft? Bußgeld wegen unzureichender Lieferanten-Dokumentation (bis zu €10 Mio.)
Während der Kompromittierung Anomalie-Erkennung: Hätte das Unternehmen die Backdoor-Kommunikation erkennen müssen? Bußgeld wegen unzureichender Security-Monitoring (bis zu €10 Mio.)
Nach Bekanntwerden 24-Stunden-Meldepflicht: Wurde der Vorfall fristgerecht an BSI gemeldet? Bußgeld wegen versäumter Meldepflicht (bis zu €10 Mio.)
Forensik Incident Response: Kann das Unternehmen nachweisen, welche Daten exfiltriert wurden? DSGVO-Bußgeld wegen unzureichender Datenschutz-Folgenabschätzung (bis zu 4% des Jahresumsatzes)
Langfristig Lessons Learned: Wurden Lieferanten-Risikoprozesse angepasst? Öffentliche Bekanntmachung durch BSI, Reputationsschaden

Gesamthaftung: Bis zu €10 Millionen (NIS2) + bis zu 4% des Jahresumsatzes (DSGVO) + zivilrechtliche Schadensersatzforderungen betroffener Kunden.

💻 Der unterschätzte Risikofaktor: Open-Source-Dependencies

Die meisten deutschen Unternehmen unterschätzen massiv, wie viele Drittanbieter-Komponenten in ihrer Software stecken. Eine typische moderne Webanwendung hat:

📦 Durchschnittliche Dependency-Anzahl (2026)

Tech-Stack Direkte Dependencies Transitive Dependencies Gesamt
React/Node.js 47 1.263 ~1.310
Python/Django 32 418 ~450
Java/Spring Boot 28 537 ~565
.NET Core 19 284 ~303

Quelle: Snyk State of Open Source Security 2026

Das bedeutet: Eine durchschnittliche Node.js-Anwendung hat über 1.300 "Lieferanten"—von denen die meisten anonyme Open-Source-Maintainer sind, die keinerlei Sicherheitsgarantien geben.

Log4Shell als Warnung

Die Log4Shell-Schwachstelle (CVE-2021-44228) in der Java-Logging-Bibliothek Log4j zeigte die Dimension des Problems: Eine einzige Zeile Code in einer weit verbreiteten Library betraf schätzungsweise 3 Milliarden Geräte weltweit. Unter NIS2 wären alle betroffenen deutschen Organisationen meldepflichtig gewesen—und hätten nachweisen müssen, dass sie ihre Dependencies kennen und überwachen.

✅ Praktische Umsetzung: Supply-Chain-Security-Programm

Phase 1: Inventarisierung (Woche 1-2)

  1. Lieferantenliste erstellen
    • Alle IT-Dienstleister, Cloud-Provider, SaaS-Anbieter
    • Alle Hardware-Lieferanten (inkl. Firmware-Hersteller)
    • Alle externen Entwicklerteams und Consultants
  2. Software Bill of Materials (SBOM) generieren
    • Tools: syft, cyclonedx-cli, OWASP Dependency-Track
    • Format: CycloneDX oder SPDX (ISO/IEC 5962:2021 Standard)
    • Erfassen Sie alle direkten und transitiven Dependencies

Phase 2: Risikobewertung (Woche 3-4)

Für jeden Lieferanten/jede Dependency bewerten Sie:

Risikofaktor Bewertungskriterien
Kritikalität Läuft die Komponente in kritischen Systemen? Hat sie Zugriff auf sensible Daten?
Bekannte Schwachstellen CVE-Datenbank-Check: Gibt es offene Critical/High-Severity-CVEs?
Maintenance-Status Wann war der letzte Update? Ist die Library veraltet ("deprecated")?
Maintainer-Vertrauen Wer maintained die Library? Einzelperson oder Organisation? Track Record?
Lizenzrisiko GPL-Lizenzen können rechtliche Risiken haben (nicht direkt NIS2, aber relevant)

Phase 3: Vertragliche Absicherung (Woche 5-6)

Für kommerzielle Lieferanten:

Für Open-Source-Dependencies (wo Verträge nicht möglich sind):

Phase 4: Kontinuierliches Monitoring (laufend)

  1. Automatisiertes Schwachstellen-Scanning
    • Tägliche Scans aller Dependencies gegen CVE-Datenbanken
    • Integration in CI/CD-Pipeline (Builds schlagen fehl bei Critical-CVEs)
    • Tools: Snyk, Dependabot, OWASP Dependency-Check, KENSAI
  2. Lieferanten-Monitoring
    • Vierteljährliche Security-Questionnaires an kritische Lieferanten
    • Tracking von Security-Incidents bei Lieferanten (Breach-Datenbanken)
  3. Incident-Response-Planung
    • Was passiert, wenn ein kritischer Lieferant kompromittiert wird?
    • Können Sie innerhalb von 48 Stunden auf eine alternative Lösung umsteigen?

🚧 Häufige Fehler und wie Sie sie vermeiden

❌ Die 5 größten Supply-Chain-Security-Fehler

  1. "Wir scannen nur bei Major-Releases" → Falsch. CVEs können jederzeit veröffentlicht werden. Tägliches Scanning ist NIS2-Standard.
  2. "Open-Source ist kostenlos, also nicht unser Problem" → Falsch. NIS2 macht keinen Unterschied zwischen kommerziell und Open Source. Sie haften für beides.
  3. "Wir haben einen Cloud-Provider mit ISO27001" → Nicht ausreichend. Sie müssen nachweisen, dass Ihre spezifische Konfiguration sicher ist—Zertifikate des Providers reichen nicht.
  4. "Wir dokumentieren Lieferanten in Excel" → Unzureichend für hunderte Dependencies. Sie benötigen automatisierte SBOM-Tools.
  5. "Wir patchen innerhalb von 30 Tagen" → Zu langsam. NIS2 verlangt "angemessene" Zeiträume—bei Critical-CVEs bedeutet das 24-72 Stunden.

💰 Kosten vs. Haftungsrisiko

Viele Organisationen schrecken vor den Kosten eines vollständigen Supply-Chain-Security-Programms zurück. Eine Kosten-Nutzen-Rechnung:

💵 Beispielrechnung: Mittelständisches Softwareunternehmen (150 Mitarbeiter)

Position Kosten/Jahr
SBOM-Tools & Scanning (KENSAI Business) €11.880
Lieferanten-Audits (externe Consultants) €25.000
Personalaaufwand (0,5 FTE Security Engineer) €45.000
Vertragliche Anpassungen (Rechtsberatung) €8.000
Gesamt €89.880

Haftungsrisiko bei Nicht-Compliance: Bußgeld bis zu €10 Millionen (NIS2) + DSGVO-Strafen + Schadensersatzforderungen. ROI der Compliance: >11.000%

Automatisiertes Supply-Chain-Scanning in 60 Sekunden

KENSAI scannt Ihre gesamte Codebasis und generiert ein NIS2-konformes SBOM (Software Bill of Materials). Sie erhalten eine vollständige Liste aller Dependencies mit Schwachstellenbewertung und priorisierten Handlungsempfehlungen—inkl. Lieferanten-Risiko-Report für das BSI.

Supply-Chain-Scan starten →

🔮 Ausblick: Verschärfungen ab 2027

Die EU-Kommission arbeitet bereits an weiterführenden Regulierungen:

Organisationen, die jetzt ein robustes Supply-Chain-Security-Programm aufbauen, sind für diese zukünftigen Anforderungen bereits gut aufgestellt.

📚 Ressourcen


Kennen Sie Ihre Lieferkette.
KENSAI Supply Chain Security Team
2. März 2026