NIS2, KRITIS & Open Source: Risikomanagement richtig umsetzen
NIS2, KRITIS & Open Source: Risikomanagement richtig umsetzen
Nandini Suresh
Informationssicherheits- und Datenschutzexpertin
December 15, 2025
5 Minuten
Nandini Suresh ist Compliance Expert bei SECJUR und spezialisiert auf Datenschutz, Cybersecurity und geistiges Eigentum. Bevor sie zu SECJUR kam, war sie unter anderem bei Bird & Bird sowie Lorenz Seidler Gossel tätig und betreute dort internationale Mandate im Marken- und Datenschutzrecht. Durch ihre Erfahrung an der Schnittstelle von Recht, Technologie und Compliance verbindet sie juristische Präzision mit einem tiefen Verständnis für die regulatorischen Anforderungen moderner Unternehmen.
Key Takeaways
Unter NIS2 gilt Open Source als Teil der Lieferkette und unterliegt vollständiger Betreiberverantwortung.
Unbekannte transitive Abhängigkeiten sind eines der größten Sicherheitsrisiken für KRITIS-Unternehmen.
Ohne SBOM und kontinuierliches Monitoring ist NIS2-konformes Open-Source-Risikomanagement nicht möglich.
Automatisierte Prozesse machen Open Source von einem Haftungsrisiko zu einem kontrollierbaren Compliance-Baustein.
Erinnern Sie sich an den Dezember 2021? Als die "Log4Shell"-Sicherheitslücke bekannt wurde, hielten IT-Abteilungen weltweit den Atem an. Ein winziges Stück Open-Source-Code, tief vergraben in Millionen von Systemen, wurde plötzlich zum Einfallstor für Angreifer. Für viele Unternehmen war es ein Weckruf.
Heute, mit der Einführung der NIS2-Richtlinie (Network and Information Security Directive 2), ist dieser Weckruf Gesetz geworden.
Wenn Sie in einem KRITIS-Unternehmen (Kritische Infrastrukturen) oder einem "besonders wichtigen" bzw. "wichtigen" Unternehmen nach NIS2-Definition arbeiten, stehen Sie vor einer komplexen Herausforderung: Sie müssen Innovation und Agilität, die Open-Source-Software (OSS) bietet, mit den strengen Sicherheitsanforderungen des Gesetzgebers in Einklang bringen.
Es ist ein offenes Geheimnis: Moderne Softwareentwicklung ohne Open Source ist undenkbar. Doch unter NIS2 wird dieser Innovationsmotor zu einem Risikofaktor, den Sie aktiv managen müssen. In diesem Artikel schauen wir uns an, wie Sie diesen Spagat meistern – nicht als lästige Pflicht, sondern als strategischen Vorteil.
Das neue Spielfeld: Wo NIS2 auf Open Source trifft
Bevor wir in die technischen Details gehen, lassen Sie uns kurz den Kontext klären. NIS2 ist nicht einfach nur ein Update der alten Richtlinie; es ist ein Paradigmenwechsel. Der Fokus verschiebt sich von reiner Reaktion auf Vorfälle hin zu einem präventiven, risikobasierten Ansatz.
Für Sie bedeutet das: Sie sind nicht nur für Ihren eigenen Code verantwortlich, sondern für die Sicherheit Ihrer gesamten digitalen Lieferkette. Und dazu gehört jede einzelne Open-Source-Bibliothek, die Ihre Entwickler nutzen.
Warum Open Source unter NIS2 besonders kritisch ist
Die NIS2-Anforderungen verlangen explizit Maßnahmen zur "Sicherheit der Lieferkette". Bei kommerzieller Software haben Sie einen Vertragspartner, den Sie in Regress nehmen können (oder zumindest SLA-Garantien). Bei Open Source? Da gibt es oft nur eine Community.
Das Paradoxon ist greifbar:
Transparenz: Open Source ist transparent (jeder kann den Code sehen), was theoretisch sicherer ist.
Verbreitung: Weil es jeder nutzt, sind Schwachstellen in populären Bibliotheken für Hacker extrem attraktiv (siehe Log4Shell).
Verantwortung: Unter NIS2 verschiebt sich die Verantwortung. Wenn eine Open-Source-Komponente in Ihrem System versagt und einen KRITIS-Vorfall auslöst, haftet im Zweifel Ihre Geschäftsführung.
Die drei Säulen des Open-Source-Risikomanagements
Um NIS2-konform zu agieren, müssen wir das Chaos ordnen. Ein effektives Risikomanagement für Open-Source-Komponenten in kritischen Sektoren ruht auf drei Säulen: Transparenz, Schwachstellenmanagement und Lizenzkonformität.
1. Transparenz durch SBOM (Software Bill of Materials)
Stellen Sie sich vor, Sie betreiben eine Bäckerei, müssen aber bei jedem einzelnen Keks genau nachweisen, von welchem Feld das Getreide stammt. Genau das erwartet NIS2 digital von Ihnen.
Sie können kein Risiko managen, das Sie nicht kennen. Der erste Schritt ist daher immer die Erstellung einer Software Bill of Materials (SBOM). Eine SBOM ist im Grunde eine Zutatenliste für Ihre Software. Sie listet alle Komponenten, Abhängigkeiten und Sub-Abhängigkeiten auf.
Aha-Moment: Viele Unternehmen sind überrascht, dass 80-90% ihrer Codebasis aus Open Source besteht. Ohne eine automatisierte SBOM wissen Sie im Falle einer neuen Sicherheitslücke gar nicht, ob Sie betroffen sind.
2. Proaktives Schwachstellenmanagement
Unter NIS2 reicht es nicht mehr, einmal im Jahr einen Pentest durchzuführen. Der Gesetzgeber fordert eine kontinuierliche Überwachung. Das NIS2-Risikomanagement muss dynamisch sein.
Open-Source-Komponenten altern wie Milch, nicht wie Wein. Eine Bibliothek, die heute sicher ist, kann morgen eine kritische Schwachstelle (CVE) aufweisen.
Best Practices für KRITIS-Betreiber:
Automatisierte Scans: Nutzen Sie SCA-Tools (Software Composition Analysis), die Ihre Repositories permanent gegen aktuelle CVE-Datenbanken prüfen.
Priorisierung: Nicht jede Lücke ist kritisch. Bewerten Sie das Risiko im Kontext Ihrer Architektur. Ist die verwundbare Funktion überhaupt aktiv?
Patch-Management: Definieren Sie klare SLAs, wie schnell kritische Updates eingespielt werden müssen.
3. Lizenzkonformität und rechtliche Risiken
Oft übersehen, aber brandgefährlich: Die rechtliche Seite. NIS2 pocht auf "Business Continuity". Wenn Sie aufgrund einer Lizenzverletzung (z.B. durch Copyleft-Lizenzen wie GPL in proprietärer Software) gezwungen werden, Ihre Software vom Markt zu nehmen oder den Betrieb einzustellen, ist das ein Verstoß gegen die Verfügbarkeitsanforderungen von NIS2.
Zudem rückt die NIS2-Haftung der Geschäftsführer stärker in den Fokus. Die Geschäftsleitung muss sicherstellen, dass rechtliche Risiken in der Lieferkette minimiert werden.
Lieferkettensicherheit: Der Blick über den Tellerrand
Ein zentraler Aspekt von NIS2 ist die Lieferkettensicherheit. Bei Open Source bedeutet das: Vertrauen ist gut, Kontrolle ist Pflicht.
Wie gesund ist das Open-Source-Projekt, das Sie nutzen?
Wird es regelmäßig gewartet?
Gibt es eine aktive Community?
Wie schnell werden Issues behoben?
Für KRITIS-Unternehmen kann es sinnvoll sein, "tote" Projekte proaktiv auszutauschen oder interne Forks zu pflegen, um die Wartbarkeit zu garantieren. Dies ist Teil einer umfassenden lieferanten risikobewertung, auch wenn der "Lieferant" hier eine Community ist.
Integration in Ihr ISMS
All diese Maßnahmen dürfen keine Insel-Lösungen sein. Sie müssen nahtlos in Ihr Information Security Management System (ISMS) integriert werden. Die NIS2-Compliance ist kein einmaliges Projekt, sondern ein dauerhafter Prozess.
Hier scheitern viele Unternehmen an der manuellen Last. Excel-Listen für tausende Software-Komponenten zu pflegen, ist schlicht unmöglich. Die Lösung liegt in der Automatisierung. Wer sein ISMS automatisiert, kann Richtlinien für den Umgang mit Open Source definieren (z.B. "Keine Komponenten mit kritischen CVEs älter als 7 Tage im Produktivsystem") und deren Einhaltung technisch erzwingen.
Fazit: Vom Risiko zur Resilienz
Die Cybersicherheit von Open-Source-Komponenten unter NIS2 ist komplex, aber machbar. Es erfordert einen Kulturwandel: Weg vom blinden Vertrauen, hin zu verifizierter Sicherheit.
Indem Sie Transparenz schaffen, Schwachstellen automatisiert managen und Lizenzfragen klären, schützen Sie nicht nur Ihre Compliance, sondern stärken die Resilienz Ihrer gesamten Infrastruktur. Betrachten Sie NIS2 nicht als Hürde, sondern als Anstoß, Ihre Software-Supply-Chain endlich so robust zu machen, wie sie für KRITIS-Systeme sein sollte.
Wollen Sie tiefer in die Umsetzung einsteigen? Lesen Sie weiter in unserem Leitfaden zum NIS2-Risikomanagement.
FAQ: Häufige Fragen zu Open Source & NIS2
Gilt NIS2 auch, wenn ich nur kostenlose Open-Source-Software nutze?
Ja. Entscheidend ist nicht, ob die Software Geld kostet, sondern ob Sie als Unternehmen unter den Anwendungsbereich von NIS2 fallen. Wenn Sie die Software in Ihren kritischen Prozessen einsetzen, müssen Sie deren Sicherheit gewährleisten.
Muss ich jetzt auf Open Source verzichten?
Auf keinen Fall. Das wäre wirtschaftlich und technisch kaum machbar. Ziel ist nicht der Verzicht, sondern der kontrollierte Einsatz. Sie müssen wissen, was Sie nutzen, und die Risiken aktiv managen.
Welche Rolle spielt der Cyber Resilience Act (CRA)?
?Der CRA ist eine weitere EU-Verordnung, die Hersteller von Produkten mit digitalen Elementen betrifft. Er wird in Zukunft Hersteller verpflichten, Sicherheitsupdates bereitzustellen. Für NIS2-betroffene Unternehmen wird der CRA helfen, da er die Sicherheit der eingekauften Komponenten (auch Open Source, sofern kommerziell genutzt) erhöht.
Wie dokumentiere ich meine Maßnahmen für ein Audit?
Ein NIS2-Audit erfordert Nachweise. Eine aktuelle SBOM, Protokolle Ihrer Vulnerability-Scans und dokumentierte Prozesse zur Behebung von Schwachstellen sind essenziell. Automatisierte Compliance-Plattformen können diese Nachweise oft auf Knopfdruck generieren.
Nandini Suresh ist Compliance Expert bei SECJUR und spezialisiert auf Datenschutz, Cybersecurity und geistiges Eigentum. Bevor sie zu SECJUR kam, war sie unter anderem bei Bird & Bird sowie Lorenz Seidler Gossel tätig und betreute dort internationale Mandate im Marken- und Datenschutzrecht. Durch ihre Erfahrung an der Schnittstelle von Recht, Technologie und Compliance verbindet sie juristische Präzision mit einem tiefen Verständnis für die regulatorischen Anforderungen moderner Unternehmen.
Über SECJUR
SECJUR steht für eine Welt, in der Unternehmen immer compliant sind, aber nie an Compliance denken müssen. Mit dem Digital Compliance Office automatisieren Unternehmen aufwändige Arbeitsschritte und erlangen Compliance-Standards wie DSGVO, ISO 27001 oder TISAX® bis zu 50% schneller.
Compliance, completed
Automatisieren Sie Ihre Compliance Prozesse mit dem Digital Compliance Office
Der EU AI Act stellt Unternehmen vor neue strategische, rechtliche und technische Anforderungen im Umgang mit Künstlicher Intelligenz. Dieser Leitfaden zeigt praxisnah, wie Sie Betroffenheit prüfen, KI-Systeme korrekt klassifizieren und Hochrisiko-Anwendungen compliant umsetzen. Erfahren Sie, wie Sie Compliance strukturiert aufbauen, Bußgelder vermeiden und den AI Act als Wettbewerbsvorteil nutzen.
Erfahren Sie, warum die Sicherheit von Unternehmensinformationen nicht länger als optionales Extra betrachtet wird, sondern als unerlässliche Säule für den Erfolg und die Nachhaltigkeit von Unternehmen jeder Größe. Wir erläutern die Definition eines ISMS und dessen umfassenden Ansatz, der technische, organisatorische, rechtliche und menschliche Aspekte berücksichtigt.
Viele Unternehmen starten ein ISO 27001-Projekt und scheitern am Risikomanagement. Dieser Leitfaden zeigt, wie Sie Risiken strukturiert bewerten, passende Maßnahmen ableiten und ein auditfestes Statement of Applicability (SoA) erstellen. So wird Risikomanagement vom Pflichtprozess zum strategischen Werkzeug, das Informationswerte schützt, Ressourcen gezielt lenkt und Ihr ISMS wirklich wirksam macht.