Supply Chain Security 2026: So schützen Unternehmen ihre Software-Lieferkette

2 Min. Lesezeit

Software-Lieferketten sind 2026 eines der größten Einfallstore für Cyberangriffe. Log4Shell, SolarWinds und MOVEit haben gezeigt: Wer seine Zulieferer nicht prüft, riskiert die eigene Sicherheit. So schützen Unternehmen ihre Software Supply Chain.

Das Wichtigste in Kürze

Supply-Chain-Angriffe stiegen 2025 um 78 Prozent gegenüber dem Vorjahr
Ein kompromittiertes Open-Source-Paket kann Tausende Unternehmen gleichzeitig treffen
NIS2 verpflichtet Unternehmen zur Absicherung ihrer gesamten Lieferkette
Software Bill of Materials (SBOM) wird zum Pflichtdokument
Automatisierte Dependency-Scans und Signaturprüfung reduzieren das Risiko erheblich

62 %

der Cyberangriffe 2024 nutzten die Software-Lieferkette als Einfallstor

Quelle: Sonatype State of the Software Supply Chain, 2024

Warum Supply Chain Security 2026 so kritisch ist

Die Angriffsfläche moderner Software wächst exponentiell. Durchschnittlich besteht eine Enterprise-Anwendung zu 80 Prozent aus Open-Source-Komponenten. Jede dieser Komponenten kann kompromittiert werden – und mit ihr alle nachgelagerten Systeme. Der XZ-Utils-Vorfall 2024 zeigte eindrücklich, wie ein einzelner Maintainer eine der meistgenutzten Linux-Bibliotheken hätte kompromittieren können. Vertiefend dazu: Supply Chain Security.

Gleichzeitig verschärft NIS2 die Anforderungen: Unternehmen in kritischen Sektoren müssen nachweisen, dass sie nicht nur eigene Systeme absichern, sondern auch die Sicherheit ihrer Zulieferer und Software-Lieferketten systematisch bewerten.

„Supply Chain Security ist kein optionales Add-on mehr. Wer seine Abhängigkeiten nicht kennt, kennt seine Angriffsfläche nicht.“CISA, Software Supply Chain Security Guidance 2024

Die häufigsten Angriffsvektoren

Dependency Confusion: Angreifer registrieren Pakete mit identischen Namen in öffentlichen Registries und schleusen so Schadcode in Build-Pipelines ein.

Typosquatting: Minimal abweichende Paketnamen (z.B. „requestes“ statt „requests“) werden mit Malware versehen und massenhaft heruntergeladen.

Kompromittierte Build-Systeme: Wie bei SolarWinds wird der Build-Prozess selbst manipuliert – das fertige Produkt enthält Schadcode, ohne dass der Quellcode verändert wurde.

Maintainer-Übernahme: Angreifer übernehmen verwaiste Open-Source-Projekte und fügen subtile Backdoors ein, die erst Monate später aktiviert werden.

Software Bill of Materials (SBOM) als Fundament

Eine SBOM listet alle Komponenten einer Software auf – vergleichbar mit einer Zutatenliste bei Lebensmitteln. Sie ermöglicht es, bei Bekanntwerden einer Schwachstelle innerhalb von Minuten statt Wochen zu prüfen, ob eigene Systeme betroffen sind.

Formate wie CycloneDX und SPDX haben sich als Standards etabliert. Tools wie Syft, Trivy oder Grype generieren SBOMs automatisch aus Container-Images und Repositories. Der EU Cyber Resilience Act wird SBOMs für alle Produkte mit digitalen Elementen verpflichtend machen.

Fünf Maßnahmen für eine sichere Supply Chain

1. Dependency-Scanning automatisieren: Jeder Commit durchläuft automatische Schwachstellenscans. Tools wie Dependabot, Snyk oder Renovate erkennen verwundbare Pakete in Echtzeit.

2. Signaturprüfung einführen: Nur signierte und verifizierte Pakete gelangen in die Build-Pipeline. Sigstore und Cosign bieten hier Open-Source-Lösungen.

3. SBOM generieren und pflegen: Für jede Anwendung wird eine aktuelle Komponentenliste geführt und bei jedem Release aktualisiert.

4. Lieferanten-Assessment durchführen: Software-Zulieferer werden regelmäßig auf ihre Sicherheitspraktiken geprüft – inklusive ISO-27001-Zertifizierung, Penetrationstests und Incident-Response-Prozesse.

5. Least-Privilege für Build-Systeme: CI/CD-Pipelines erhalten nur die minimal notwendigen Berechtigungen. Secrets werden nicht in Code oder Umgebungsvariablen gespeichert, sondern über Vault-Lösungen bereitgestellt.

Key Facts

Angriffsanstieg: +78 % Supply-Chain-Angriffe 2025 vs. 2024 (Sonatype)

Open-Source-Anteil: 80 % des Codes in Enterprise-Apps stammt aus Open-Source-Bibliotheken

Reaktionszeit: Mit SBOM sinkt die Schwachstellen-Identifikation von Wochen auf Minuten

Regulierung: EU Cyber Resilience Act und NIS2 machen Supply-Chain-Security zur Pflicht

Kosten eines Vorfalls: Durchschnittlich 4,5 Mio. USD pro Supply-Chain-Breach (IBM)

Fakt: 62 Prozent aller Cyberangriffe auf Unternehmen nutzen laut CrowdStrike die Software-Lieferkette als Einfallstor.

Fakt: Die durchschnittliche Dauer bis zur Entdeckung eines Supply-Chain-Angriffs beträgt laut Mandiant 287 Tage – fast zehn Monate.

Häufige Fragen

Was ist Supply Chain Security?

Supply Chain Security bezeichnet den Schutz der gesamten Software-Lieferkette – von Open-Source-Bibliotheken über Build-Systeme bis hin zu Drittanbieter-Diensten. Ziel ist es, sicherzustellen, dass keine kompromittierten Komponenten in die eigene Software gelangen.

Warum sind Open-Source-Abhängigkeiten ein Risiko?

Open-Source-Pakete werden oft von einzelnen Maintainern gepflegt und können durch Account-Übernahme, Social Engineering oder Dependency Confusion kompromittiert werden. Da sie in Tausenden Anwendungen gleichzeitig eingesetzt werden, potenziert sich die Wirkung eines Angriffs enorm.

Was ist eine SBOM und wozu braucht man sie?

Eine Software Bill of Materials ist eine maschinenlesbare Liste aller Komponenten einer Software. Sie ermöglicht es, bei neuen Schwachstellen sofort zu prüfen, ob eigene Systeme betroffen sind, und wird durch den EU Cyber Resilience Act zunehmend verpflichtend.

Welche Tools helfen bei der Supply-Chain-Absicherung?

Für Dependency-Scanning eignen sich Snyk, Dependabot und Renovate. Für SBOM-Generierung Syft und Trivy. Für Signaturprüfung Sigstore und Cosign. Für Lieferanten-Assessment bieten Plattformen wie SecurityScorecard und BitSight automatisierte Bewertungen.

Wie hängen NIS2 und Supply Chain Security zusammen?

NIS2 verpflichtet Unternehmen in kritischen Sektoren, die Cybersicherheit ihrer gesamten Lieferkette zu bewerten und abzusichern. Dazu gehören vertragliche Sicherheitsanforderungen an Zulieferer, regelmäßige Audits und dokumentierte Risikobewertungen der eingesetzten Drittanbieter-Software.