NIS2-konforme Software-Lieferkette: Wie Unternehmen die Umsetzung fördern lassen können
Wissen Sie, welche Open-Source-Bibliotheken in Ihrer eingesetzten Software stecken? Welche davon bekannte Sicherheitslücken haben? Und können Sie das im Zweifel einem Prüfer oder Kunden gegenüber nachweisen?
Mit dem NIS2-Umsetzungsgesetz sind genau das keine akademischen Fragen mehr – sondern Compliance-Anforderungen mit konkreten Konsequenzen. Gleichzeitig gibt es staatliche Förderprogramme, die den Weg zur Umsetzung finanziell erleichtern.
Inhaltsverzeichnis
- Was NIS2 mit Ihrer Software-Lieferkette zu tun hat 🔗
- Wer ist von NIS2 betroffen? 🏢
- Was ist eine SBOM – und warum ist sie das zentrale Instrument? 📋
- Der EU Cyber Resilience Act: Noch ein Grund, jetzt zu handeln ⚖️
- Der typische Umsetzungspfad 🗺️
- Welche Förderprogramme passen? 💶
- Was das in der Praxis bedeutet 🛠️
- Häufige Fragen ❓
- Fazit: Compliance als Chance 🎯
Was NIS2 mit Ihrer Software-Lieferkette zu tun hat 🔗
Die NIS2-Richtlinie (EU 2022/2555) und das deutsche Umsetzungsgesetz verpflichten betroffene Unternehmen zu einem aktiven Risikomanagement – ausdrücklich auch für Risiken, die aus der Lieferkette kommen. Artikel 21 der Richtlinie nennt dabei explizit:
„Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren Anbietern oder Dienstleistern”
In der Praxis bedeutet das: Wenn ein Unternehmen Software einsetzt – ob zugekauft, als Open-Source-Bibliothek oder als Container-Image – muss es nachweisbar überwachen, ob darin bekannte Schwachstellen stecken. Eine regelmäßige Überprüfung und Dokumentation ist keine Option, sondern Pflicht.
Wer ist von NIS2 betroffen? 🏢
NIS2 gilt für mittlere und große Unternehmen in bestimmten Sektoren. Als Faustregel gilt: Ab 50 Mitarbeitenden oder 10 Mio. Euro Jahresumsatz und Tätigkeit in einem der genannten Sektoren besteht grundsätzlich eine Betroffenheit.
Betroffene Sektoren (Auswahl):
| Sektor | Beispiele |
|---|---|
| Energie | Strom, Gas, Fernwärme, Ladeinfrastruktur |
| Transport | Logistik, Spedition, Flughafenbetreiber |
| Finanzwesen | Banken, Zahlungsdienstleister |
| Gesundheit | Krankenhäuser, Pharmahersteller, Labore |
| Digitale Infrastruktur | Rechenzentren, Cloud-Anbieter, DNS |
| IKT-Dienstleistungen | Managed Service Provider, IT-Systemhäuser |
| Öffentliche Verwaltung | Bundes- und Landesbehörden |
| Produktion | Hersteller kritischer Produkte (Medizin, Chemie) |
Wichtig: Auch wenn ein Unternehmen selbst nicht direkt betroffen ist, kann es als Zulieferer oder IT-Dienstleister für eine betroffene Einrichtung mittelbar unter Druck geraten – weil seine Kunden ihre Lieferkette nachweisbar absichern müssen.
Was ist eine SBOM – und warum ist sie das zentrale Instrument? 📋
Eine SBOM (Software Bill of Materials) ist eine vollständige, maschinenlesbare Liste aller Komponenten, die in einem Softwareprodukt enthalten sind: Open-Source-Bibliotheken, Abhängigkeiten, Versionen, Lizenzen und bekannte Schwachstellen.
Sie ist das entscheidende Werkzeug für NIS2-konforme Software-Lieferkettentransparenz, weil sie:
- Sichtbarkeit schafft: Welche Komponenten sind überhaupt im Einsatz?
- Risiken identifiziert: Welche davon haben bekannte CVEs (Common Vulnerabilities and Exposures)?
- Nachweisbarkeit ermöglicht: Im Audit oder bei Behördenanfragen lässt sich belegen, dass aktiv überwacht wird.
- Automatisierung erlaubt: SBOMs können in CI/CD-Pipelines laufend neu generiert werden – ohne manuellen Aufwand.
Technische Standards
Zwei Formate haben sich etabliert:
- CycloneDX (OWASP, aktuell am weitesten verbreitet im Security-Kontext)
- SPDX (ISO/IEC 5962:2021, der ältere Standard, auch im BSI-Kontext relevant)
Beide werden von gängigen Open-Source-Tools unterstützt und sind zueinander konvertierbar.
Der EU Cyber Resilience Act: Noch ein Grund, jetzt zu handeln ⚖️
Wer Software entwickelt und verkauft, muss zusätzlich zu NIS2 den EU Cyber Resilience Act (CRA) im Blick haben. Er tritt voraussichtlich Ende 2027 vollständig in Kraft und verpflichtet Hersteller von Produkten mit digitalen Elementen:
- Eine SBOM für jedes Produkt bereitzustellen
- Bekannte Schwachstellen aktiv zu verfolgen und zu melden
- Software während des gesamten Produktlebenszyklus aktiv zu pflegen
Die Sanktionen sind erheblich: Bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem was höher ist – ähnlich der DSGVO-Systematik.
Was das bedeutet: Wer heute bereits eine SBOM-Infrastruktur aufbaut, erfüllt gleichzeitig die Anforderungen von NIS2 (als Betreiber) und CRA (als Hersteller). Das ist keine doppelte Arbeit – sondern eine Infrastruktur, die beide Anforderungen abdeckt.
Der typische Umsetzungspfad 🗺️
Die Einführung einer SBOM-Pipeline muss kein großes Projekt sein. Ein bewährter Ansatz in vier Schritten:
Schritt 1: Ist-Analyse
- Welche Repositories, Container-Images und Anwendungen sind relevant?
- Welche Prozesse existieren bereits (CI/CD, Deployment)?
- Welche Compliance-Anforderungen gelten konkret?
Schritt 2: SBOM-Generierung automatisieren
- Integration von SBOM-Generierungstools in bestehende CI/CD-Pipelines
- Automatische Erstellung bei jedem Build oder Deployment
- Ausgabe in CycloneDX oder SPDX Format
Open-Source-Tools, die hier zum Einsatz kommen:
| Tool | Aufgabe |
|---|---|
| Syft | SBOM generieren aus Repos, Container-Images, Binaries |
| Trivy | All-in-one: Scan + SBOM + CVE-Matching |
| cdxgen | SBOM-Generierung für viele Sprachen und Build-Systeme |
Schritt 3: Auswertung und Schwachstellen-Matching
- Abgleich der SBOM-Komponenten mit bekannten CVE-Datenbanken
- Bewertung nach Schweregrad (CVSS-Score)
- Lizenz-Compliance-Check
Open-Source-Tools:
| Tool | Aufgabe |
|---|---|
| Grype | CVE-Matching auf SBOM-Basis |
| Dependency-Track | SBOM-Management-Plattform, Dashboards, Policy-Engine |
| OSV-Scanner | Google-basierter Schwachstellen-Scanner |
Schritt 4: Reports und Benachrichtigungen
- Automatische Benachrichtigung von Entwicklern bei neuen kritischen Schwachstellen (E-Mail, Slack, Teams, Jira-Ticket)
- Periodische Compliance-Reports für Geschäftsführung oder Auditoren
- Dashboard für kontinuierliche Übersicht
Typischer Gesamtaufwand für einen ersten produktiven Betrieb: 6–14 Personentage, je nach Komplexität der bestehenden Infrastruktur.
Welche Förderprogramme passen? 💶
Die Umsetzung einer SBOM-Infrastruktur ist förderbar – über verschiedene Programme:
KfW ERP-Förderkredit Digitalisierung (Nr. 511 / 512)
Der KfW-Digitalisierungskredit fördert Investitionen in digitale Sicherheitsinfrastruktur. SBOM-Toolchains, Monitoring-Systeme und Automatisierungslösungen fallen grundsätzlich in den Förderbereich.
- Stufe 2 oder 3 relevant (LevelUp- oder HighEnd-Digitalisierung)
- Zuschüsse bis zu 5 % der Kreditsumme
- KfW übernimmt optional 50 % des Kreditrisikos
🔗 Mehr zum KfW ERP-Förderkredit Digitalisierung (www.kfw.de)
Transferstelle Cybersicherheit im Mittelstand
Die vom BMWK finanzierte Transferstelle bietet kostenlose Erstorientierung, Handlungsempfehlungen und Workshops speziell für KMU. Sie ist die ideale erste Anlaufstelle, um den eigenen Handlungsbedarf einzuschätzen – bevor man in die technische Umsetzung investiert.
🔗 Zur Transferstelle Cybersicherheit im Mittelstand (transferstelle-cybersicherheit.de)
Mittelstand-Digital Zentren
Die 29 regionalen Beratungszentren des BMWK beraten kostenlos zu Digitalisierung und IT-Sicherheit. Sie helfen dabei, den richtigen Einstieg zu finden – setzen aber nicht selbst um.
🔗 Zu den Mittelstand-Digital Zentren (www.mittelstand-digital.de)
BSI-Förderprogramme und Zertifizierungen
Das BSI bietet Programme zur IT-Sicherheitsberatung für KMU sowie den IT-Grundschutz als anerkannten Rahmen. Eine SBOM-Pipeline zahlt direkt auf IT-Grundschutz-Anforderungen ein und kann als Nachweis bei Audits verwendet werden.
🔗 BSI IT-Grundschutz (www.bsi.bund.de)
Was das in der Praxis bedeutet 🛠️
Beispiel: IT-Systemhaus mit 80 Mitarbeitenden (NIS2-betroffen als ICTS-Dienstleister)
Ausgangssituation: Das Unternehmen setzt in seinem Managed Service etwa 40 verschiedene Open-Source-Komponenten ein – Monitoring-Agents, Datenbank-Clients, Sicherheitsbibliotheken. Niemand hat einen vollständigen Überblick, welche Versionen wo laufen.
Umsetzung:
- Ist-Analyse aller relevanten Softwarekomponenten (1 Tag)
- Einrichtung von Trivy in der bestehenden GitLab CI/CD (2 Tage)
- Aufbau Dependency-Track als zentrales Dashboard (2 Tage)
- Konfiguration automatischer Alert-E-Mails bei CVSS ≥ 7.0 an die zuständigen Entwickler sowie wöchentlicher Report an Geschäftsführung (1 Tag)
Ergebnis: Vollständige SBOM-Transparenz und automatisches Alerting in 6 Personentagen. Laufender Betrieb erfordert kaum manuellen Aufwand – das System überwacht eigenständig.
Beispiel: Softwarehersteller mit 25 Mitarbeitenden (CRA-betroffen)
Ausgangssituation: Das Unternehmen vertreibt eine B2B-Softwarelösung für die Produktionsbranche. Ab 2027 muss es eine SBOM für jede ausgelieferte Version bereitstellen und bekannte Schwachstellen aktiv verfolgen.
Umsetzung:
- Syft in GitHub Actions integrieren – bei jedem Release automatisch SBOM generieren (1 Tag)
- Grype für CVE-Matching bei jedem Build (0,5 Tage)
- SBOM-Artefakt im Release-Paket mitliefern (0,5 Tage)
- Dependency-Track für laufendes Monitoring auch nach dem Release (2 Tage)
Ergebnis: CRA-konforme SBOM-Auslieferung und laufende Schwachstellen-Überwachung in ca. 4 Personentagen. Der Aufwand zahlt sich doppelt aus: NIS2-Anforderungen werden gleichzeitig erfüllt.
Häufige Fragen ❓
Muss ich die SBOM an Kunden oder Behörden herausgeben?
Nach dem CRA ja – Hersteller müssen die SBOM bereitstellen. NIS2 schreibt keine Pflicht zur Herausgabe vor, aber die interne Dokumentation muss vorhanden sein und bei Prüfungen vorgelegt werden können.
Reicht es, die SBOM einmal zu erstellen?
Nein. SBOMs müssen bei jeder neuen Version aktualisiert werden, weil sich Abhängigkeiten ändern. Noch wichtiger: Neue CVEs erscheinen täglich. Nur eine kontinuierlich überwachte SBOM schützt tatsächlich.
Welche Sprachen und Technologien werden unterstützt?
Die gängigen Tools unterstützen Java, Python, Node.js, Go, .NET, Rust, Ruby und viele weitere. Auch Container-Images (Docker) und Systemabhängigkeiten (Debian, Alpine) werden abgedeckt.
Was kostet ein erstes Pilotprojekt?
Der Einstieg ist überschaubar: Für einen ersten produktiven SBOM-Scan inklusive Einrichtung des Dashboards und Notification-Konfiguration rechnet man mit wenigen Tagen Aufwand – abhängig von der Anzahl der Systeme und der bestehenden CI/CD-Infrastruktur.
Fazit: Compliance als Chance 🎯
NIS2 und der Cyber Resilience Act sind keine Bürokratie um ihrer selbst willen. Sie reagieren auf eine echte Bedrohungslage: Die größten Sicherheitsvorfälle der letzten Jahre – Log4Shell, XZ Utils, SolarWinds – kamen genau aus den Stellen, die niemand im Blick hatte: tief eingebettete Abhängigkeiten in der Software-Lieferkette.
Unternehmen, die jetzt eine SBOM-Infrastruktur aufbauen, erhalten:
- Sichtbarkeit über das, was wirklich in ihrer Software steckt
- Frühwarnung, bevor eine Schwachstelle ausgenutzt wird
- Compliance-Nachweis für NIS2-Prüfungen und CRA-Anforderungen
- Förderbarkeit über KfW und staatliche Beratungsangebote
Der Aufwand ist kleiner als erwartet – besonders dann, wenn bestehende CI/CD-Prozesse bereits vorhanden sind. Und staatliche Fördermittel erleichtern den Einstieg zusätzlich.
Wenn Sie wissen möchten, welcher Umsetzungspfad für Ihr Unternehmen konkret passt, sprechen wir das gerne in einem kurzen Assessment durch.
Beratung und Dienstleistungen sind in ganz Deutschland verfügbar. Wir unterstützen Unternehmen nach Absprache vor Ort oder remote in Berlin, Hamburg, München, Köln, Frankfurt am Main, Stuttgart, Düsseldorf, Dortmund, Essen, Leipzig, Bremen, Hannover, Nürnberg, Duisburg, Bochum, Wuppertal, Bielefeld, Bonn und Münster.
↩️ zurück