NIS-2- und CRA-Haftungsrisiko:Geschäftsführer sollten Software-Lieferkette durchleuchten

Mit dem Inkrafttreten des Gesetzes zur Umsetzung der NIS-2-Richtlinie in deutsches Recht haben sich die Sicherheitsanforderungen an Unternehmen deutlich verschärft. Parallel dazu gewinnt mit dem Cyber Resilience Act (CRA) ein weiterer Regulierungsrahmen an Bedeutung, der erstmals verbindliche Sicherheitsanforderungen an digitale Produkte und Software über deren gesamten Lebenszyklus hinweg festlegt.

Verantwortliche müssen dem Thema Software Supply Chain Security also mehr Aufmerksamkeit schenken. Was wichtig und richtig ist, schließlich scheitern viele Maßnahmen und klassische Tools, die Software Supply Chain eigentlich ganzheitlich auf Risiken überprüfen sollten. Das Ergebnis: Die Geschäftsleitung kann die Sorgfaltspflicht nicht erfüllen und Haftungsrisiken werden zunehmend realistischer.

Was lange währt, wird endlich Pflicht: Im Dezember 2025 ist das NIS-2-Umsetzungs- und Cyber-Sicherheitsstärkungsgesetz (NIS2UmsuCG) in Kraft getreten – und mit ihm schärfere Anforderungen an Unternehmen. Schließlich soll das Ziel „mehr digitale Sicherheit“ nicht nur von einigen wenigen erreicht werden. Daher müssen sich mit NIS-2 auch deutlich mehr Organisationen und mehr Branchen auseinandersetzen als noch zu NIS-1-Zeiten. Zentral ist die Grundversorgung der Bevölkerung. Deshalb sind Bereiche wie Gesundheits- und Energieversorgung, Infrastrukturanbieter oder IT-Dienstleister besonders gefragt.

Alles in allem müssen sie verbindliche Maßnahmen für die Cyber-Sicherheit implementieren und Sicherheitsvorfälle schneller und umfangreicher melden. Außerdem rückt das Risikomanagement in den Mittelpunkt – und wird zur dringlichen Chefsache. Darunter fällt gleichfalls das häufig vernachlässigte Thema „sichere Software-Lieferkette“. Verantwortliche müssen die IT-Sicherheit ihrer Lieferkette überprüfen und, wo nötig, Maßnahmen ergreifen.

Diese Anforderungen werden durch den Cyber Resilience Act (CRA) weiter konkretisiert und verschärft. Während NIS-2 vor allem organisatorische Pflichten adressiert, legt der CRA erstmals verbindliche Sicherheitsanforderungen an digitale Produkte und Software über ihren gesamten Lebenszyklus fest. Damit wird deutlich: Die Verantwortung endet nicht bei der eigenen IT und selbst eingesetzter Software, sondern umfasst auch eigene Produkte mit Softwarekomponenten, die an Kunden geliefert werden.

Schwachstellen heutiger Lösungen

Wer diesen Punkt im eigenen Unternehmen schon als abgehakt sieht, sollte noch einen Moment innehalten. Denn auch wenn Firmen gängige Lösungen zur Analyse der genutzten Software einsetzen, bieten diese nur einen teilweisen Schutz. Beispielsweise können Virenscanner moderne Supply-Chain-Angriffe, die direkt im Bauprozess der Software stattfinden, nicht erkennen. Fehlende Quellcodes sorgen für Sicherheitslücken. Und auch SBOM-Tools (SBOM steht für Software Bill of Materials) weisen Security-technisch Schwachstellen auf.

Häufig wird vermutet, dass diese Lösungen zur Generierung einer SBOM alle Risiken beleuchten können. Schließlich werben sie damit, dass sie automatisch eine detaillierte Inventarliste aller Komponenten und sämtlicher Abhängigkeiten einer Software erstellen und anschließend analysieren. Und doch spiegeln klassische SBOM-Tools die produktive Software meist nicht vollständig wider. Die Gründe liegen in der Realität moderner Softwareentwicklung verborgen.

Abhängigkeiten entstehen nicht nur im Quellcode, sondern auch in Build-Pipelines, Container-Images und zur Laufzeit. Hinzu kommen transitive Dependencies, nachgeladene Komponenten, Unterschiede zwischen Entwicklungs- und Produktionsumgebung sowie Third-Party-Software, deren innere Lieferkette nicht vollständig offengelegt wird.

Ohne durchgängige Prozessintegration – von der Entwicklung über das Deployment bis zum Betrieb – bleibt die SBOM daher häufig eine Momentaufnahme statt einer verlässlichen Abbildung der Realität. Für Geschäftsführer heißt das: Es bleibt ein Risiko, der (Produkt-)Haftungspflicht nicht ausreichend zu entsprechen – im Worst-Case-Szenario mit hohen Bußgeldzahlungen.

Checkliste für ein evolutionäres SBOM-Tool

Doch es gibt Ausnahmen – und Hinweise für Unternehmen, ob das SBOM-Tool die oben beschriebenen Risiken offenlässt oder die Software-Lieferkette ganzheitlich durchleuchtet. Drei Punkte sollten oberste Priorität bei der Entscheidung erhalten.

• SBOM aus Binaries; Tools, die nur Metadaten aus Build-Dateien oder Paketlisten auslesen, erfassen häufig nicht alle Komponenten einer produktiven Anwendung. Moderne Lösungen wie der Application Supply Guard [TT1.1]analysieren dagegen direkt die kompilierten Binaries, Container-Images oder ZIP-Archive und decken so auch dynamisch geladene Libraries und sonstige Komponenten auf, die in konfigurationsbasierten SBOMs fehlen würden.
• Scan aktueller Schwachstellen; ein vollständiger Security-Report sollte nicht nur eine Stückliste der Komponenten liefern, sondern diese automatisch mit aktuellen Schwachstellen aus CVE-Datenbanken abgleichen. Nur so lässt sich erkennen, welche Bestandteile tatsächlich ein Risiko darstellen. Daher sind SBOM-Tools zu empfehlen, die jede Komponente automatisch mit allen aktuellen CVE-Datenbanken zu bekannten Schwachstellen abgleichen.
• Sicherheitsreport; eine SBOM liefert für die Geschäftsführung meist ein unübersichtliches Dokument. Auch wenn bekannte Schwachstellen und Abhängigkeiten aus CVE-Datenbanken in den Bericht einfließen, nimmt es für verantwortliche Entscheider viel Zeit in Anspruch, diese zu erkennen und Maßnahmen einzuleiten. Vorteilhaft ist es daher, wenn zusätzlich zur generierten SBOM auch ein übersichtlicher Sicherheitsreport mit klarer Priorisierung und Empfehlungen ausgegeben wird. Auf eventuelle Sicherheitsgefahren lässt sich so deutlich zielgerichteter reagieren.

Augen auf bei der SBOM-Wahl

SBOM ist heute eine wichtige Grundlage – aber keine Garantie für vollständige Transparenz. Kritisch wird es, wenn sie nicht über den gesamten Software-Lifecycle sauber eingebunden ist. Daher sollten Organisationen SBOM-Lösungen genauer unter die Lupe nehmen.

Auf die Inventarisierung der Software allein kommt es hier nicht an. Entscheidender ist ein vollständiger Sicherheitsreport. Erst dieser dient als Basis für regulatorische Nachweise und Risikoentscheidungen.

Roland Baum ist Co-Founder und CEO der umbrella.associates GmbH.

umbrella.associates GmbH