---
title: "Lieferkettensicherheit: Risiken erkennen und steuern"
description: "Ein praxisnaher Leitfaden zur Lieferkettensicherheit — was sie ist, warum Lieferkettenangriffe zunehmen, zentrale Risikokategorien, wie man Drittparteien-Risiken bewertet und steuert, regulatorische Anforderungen unter NIS2 und DORA und wie B2B-Unternehmen resiliente Lieferketten aufbauen."
canonical: https://www.orbiqhq.com/de/glossar/supply-chain-security
html: https://www.orbiqhq.com/de/glossar/supply-chain-security
publisher: Orbiq GmbH
language: en
---
# Lieferkettensicherheit: Risiken erkennen und steuern

Ein praxisnaher Leitfaden zur Lieferkettensicherheit — was sie ist, warum Lieferkettenangriffe zunehmen, zentrale Risikokategorien, wie man Drittparteien-Risiken bewertet und steuert, regulatorische Anforderungen unter NIS2 und DORA und wie B2B-Unternehmen resiliente Lieferketten aufbauen.


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](/de/glossar/drittparteien-risikomanagement) — Aufbau eines umfassenden TPRM-Programms
- [Lieferanten-Risikobewertung](/de/glossar/lieferanten-risikobewertung) — Bewertung der Sicherheitslage von Lieferanten
- [NIS2 Compliance](/de/glossar/nis2-compliance) — Erfüllung der NIS2-Lieferkettensicherheitsanforderungen
- [DORA Compliance](/de/glossar/dora-compliance) — DORA-Pflichten zum IKT-Drittparteien-Risikomanagement
- [Incident Response](/de/glossar/incident-response) — Koordination der Incident Response in der Lieferkette

---

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