NIS2 & CRA
NIS2 und Ihre Software-Lieferkette.
Das NIS2-Umsetzungsgesetz gilt seit dem 6. Dezember 2025. Für betroffene Einrichtungen gehört die Sicherheit der Lieferkette zu den Risikomanagementmaßnahmen nach § 30 BSIG. Diese Seite ordnet ein, was das für Software und Releases bedeutet.
Was im Gesetz steht.
Artikel 21 der NIS2-Richtlinie (EU) 2022/2555 verlangt von betroffenen Einrichtungen geeignete Risikomanagementmaßnahmen. Dazu gehören die Sicherheit der Lieferkette sowie Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen. In Deutschland ist das in § 30 BSIG umgesetzt.
Das Gesetz nennt Ziele, keine Werkzeuge. Es schreibt weder eine bestimmte Plattform noch ein bestimmtes Dateiformat vor. Welche Maßnahmen angemessen sind, richtet sich nach Ihrem Risiko, Ihrer Größe und Ihrer Tätigkeit. Diese Übersetzung von der Anforderung zur konkreten Prüfung ist die Arbeit, die ich mit Ihrem Team mache.
Regulatorischer Kontext
NIS2, CRA und BSI TR-03183
Drei Regelwerke mit unterschiedlichen Adressaten. Welche für Sie gelten, klären Sie vor der Umsetzung.
NIS2 / BSIG
Adressiert betroffene Einrichtungen als Betreiber. Verlangt Risikomanagement einschließlich Lieferkettensicherheit, den Umgang mit Schwachstellen und Meldepflichten. Die Geschäftsleitung ist für die Maßnahmen verantwortlich.
Cyber Resilience Act
Adressiert Hersteller von Produkten mit digitalen Elementen. Verlangt Produktsicherheit über den Lebenszyklus, den Umgang mit Schwachstellen und eine maschinenlesbare SBOM. Die Meldepflichten gelten seit dem 11. September 2026.
BSI TR-03183
Eine technische Richtlinie, keine allgemein geltende gesetzliche Pflicht. Sie konkretisiert SBOM-Formate, Mindestinhalte und Bereitstellungswege und eignet sich als Maßstab für die eigene Gestaltung.
Zeitplan
Die Fristen im Überblick
6. Dezember 2025: NIS2 in Kraft
Das deutsche NIS2-Umsetzungsgesetz ist seit diesem Tag geltendes Recht. Ob Ihre Einrichtung betroffen ist, entscheidet sich nach § 28 BSIG.
6. März 2026: Registrierungsfrist beim BSI abgelaufen
Die reguläre Frist ist vorbei. Eine Registrierung ist weiterhin möglich und sollte nachgeholt werden: Die unterlassene Registrierung ist ein eigenständiger Verstoß.
11. September 2026: CRA-Meldepflichten in Kraft
Seit diesem Tag gelten für Hersteller von Produkten mit digitalen Elementen die Meldepflichten nach Artikel 14 des Cyber Resilience Act: Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden. Sie betreffen aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, nicht jedes Scanner-Finding.
11. Dezember 2027: CRA vollständig anwendbar
Ab diesem Tag gelten die übrigen Produktanforderungen des CRA. Dazu gehört eine maschinenlesbare SBOM für Produkte mit digitalen Elementen.
Bin ich betroffen?
Das hängt von der Einrichtungsart, der Tätigkeit und der Größe ab. Für viele Einrichtungsarten der Anlagen 1 und 2 des BSIG gilt: mindestens 50 Beschäftigte oder Jahresumsatz und Jahresbilanzsumme von jeweils über 10 Millionen Euro. Für bestimmte Einrichtungsarten gelten andere oder größenunabhängige Regeln, und bei verbundenen Unternehmen ist die Berechnung gesondert zu prüfen.
Ob Sie als besonders wichtige oder als wichtige Einrichtung gelten, folgt ebenfalls aus § 28 BSIG. Prüfen Sie Ihre konkrete Einordnung, statt sie aus einer Faustregel abzuleiten.
§ 28 BSIG: Betroffene Einrichtungen
Auch ohne eigene Betroffenheit
Wenn Ihre Kunden betroffen sind, werden sie Anforderungen an Sie als Lieferant stellen. Das ist ein vertragliches Thema und von einer eigenen gesetzlichen Betroffenheit zu unterscheiden. Beides führt zur selben praktischen Frage: Können Sie belegen, was in einer ausgelieferten Version steckt und was vor der Freigabe geprüft wurde?
In der Praxis
Was das für Ihren Release-Prozess bedeutet
Aus Anforderungen werden erst dann Kontrollen, wenn sie an einer konkreten Stelle im Ablauf greifen. Diese vier Fragen kläre ich mit Ihrem Team.
Was steckt in der ausgelieferten Version?
Eine Komponenteninventur je Build, dem ausgelieferten Artefakt zugeordnet. Eine SBOM unterstützt das. Ihre Aussagekraft hängt davon ab, wie sie erzeugt wurde.
Wie erfahren Sie von einer Schwachstelle?
Wer wertet Befunde aus, nach welchen Kriterien und in welcher Frist? Ohne festgelegte Zuständigkeit bleibt ein Bericht ein Bericht.
Was blockiert eine Freigabe?
Welche Befunde stoppen den regulären Release-Weg, und wer darf eine Ausnahme genehmigen? Eine Ausnahme braucht Geltungsbereich, Verantwortung und Ablaufdatum.
Woran erkennen Sie später, was galt?
Prüfergebnisse, Freigaben und Ausnahmen gehören zum Artefakt, nicht nur zu einer Versionsnummer. Sonst lässt sich im Nachhinein nicht rekonstruieren, worauf eine Freigabe beruhte.
Ich arbeite dabei in Ihren bestehenden Build- und Release-Systemen. Vertraut sind mir die etablierten Werkzeuge dieses Felds: CycloneDX und Syft für die Inventarisierung, DependencyTrack für die Verwaltung, Grype für den Abgleich gegen Schwachstellendatenbanken, dazu rio von rebaze. Welche davon passen, entscheidet Ihr Kontext; betreiben Sie bereits eine Plattform, beziehe ich sie ein.
Für jede vereinbarte Kontrolle kläre ich mit Ihnen auch die Verantwortung: Wer legt die Prüfkriterien fest, wer bestätigt die fachliche Richtigkeit, wer darf freigeben und wer bearbeitet Abweichungen? Ich automatisiere wiederkehrende Prüfungen und lege mit Ihnen fest, wann der Release nach klaren Regeln weiterläuft und wann eine menschliche Entscheidung nötig ist.
Wie Kontrollverantwortung, Freigabe und Nachweise zusammenwirken
Was daraus folgt
Eine Richtlinie beschreibt die Absicht. Eine Freigaberegel erzeugt den Nachweis.
§ 30 BSIG verlangt angemessene Maßnahmen, kein bestimmtes Dokument. Geprüft wird später aber nicht Ihre Absicht, sondern ein konkreter Release: Was war enthalten, was wurde geprüft, wer hat freigegeben, und was hätte den Weg gestoppt.
Für Hersteller im CRA-Anwendungsbereich gelten seit dem 11. September 2026 Meldepflichten. Bei Kenntnis einer aktiv ausgenutzten Schwachstelle im Produkt ist eine Frühwarnung binnen 24 Stunden erforderlich. Die Zuordnung von Komponenten zu ausgelieferten Versionen unterstützt die Untersuchung; ein CVE-Treffer allein löst keine Meldepflicht aus. Meldepflichten laut EU-Kommission
Diese Zuordnung entsteht nicht in einem Dokument. Sie entsteht dort, wo der Release stattfindet: wenn Prüfergebnisse an das ausgelieferte Artefakt gebunden sind und eine Regel den regulären Weg stoppt, solange ein vereinbarter Nachweis fehlt. Genau das setze ich als Release Controls in Ihren bestehenden Systemen um – ein Produkt, ein Release-Weg, eine konkrete Verbesserung. Danach führt Ihr Team den nächsten Release ohne mich durch.
Grenze: Ich mache die vereinbarten Prüfungen verbindlich und im Nachhinein belegbar. Welche Maßnahmen für Ihre Einrichtung angemessen sind, entscheiden Sie; rebaze ersetzt weder Rechtsberatung noch ein Audit.
Bringen Sie eine Anforderung mit, bei der unklar ist, wie Sie sie im Release belegen.
Erstgespräch vereinbaren30 Minuten mit Toni Menzel. Kostenlos, konkrete Empfehlungen, keine Verkaufspräsentation.
Clear to Ship: CRA-Anforderungen in Ihrem Release-Prozess umsetzen