Ist ein Code-Scanner nach NIS2 Pflicht?
Kurze Antwort: Nein. NIS2 und das deutsche Umsetzungsgesetz schreiben kein Scanner-Produkt vor. Sie verlangen Sicherheit bei Entwicklung und Wartung samt Schwachstellenmanagement (§ 30 Abs. 2 Nr. 5 BSIG) und die Dokumentation der Einhaltung. Was das für Betreiber eigener Software bedeutet, in fünf Antworten.
Die kurze Antwort
Nein. Es gibt in der NIS2-Richtlinie und im deutschen BSI-Gesetz keine Vorschrift, die einen Code-Scanner, ein Scanner-Produkt oder ein bestimmtes Prüfverfahren verlangt. Wer das Gegenteil hört, sollte nach der Fundstelle fragen. Es gibt sie nicht.
Was stattdessen verlangt wird
Artikel 21 Absatz 2 Buchstabe e der Richtlinie verlangt von betroffenen Einrichtungen Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen. Deutschland hat das in § 30 Absatz 2 Nummer 5 BSIG übernommen, fast wortgleich. Absatz 1 desselben Paragrafen fügt hinzu, dass die Einhaltung zu dokumentieren ist, und Nummer 6 verlangt Verfahren, mit denen die Wirksamkeit der Maßnahmen bewertet wird.
Das ist die ganze Pflicht: Schwachstellen kennen, behandeln, offenlegen, dokumentieren, bewerten. Wie eine Einrichtung das erreicht, überlässt ihr das Gesetz. Für den eigenen Code sind die Schwachstellen im Wesentlichen hartkodierte Zugangsdaten, verwundbare Abhängigkeiten und unsichere Muster; wie ein laufender Scan diese belegt, steht im Beitrag zu Nachweisen nach § 30 BSIG und auf unserer Seite zu Code-Sicherheit und Compliance.
Warum wir den Scan trotzdem empfehlen
Weil die Dokumentationspflicht aus Absatz 1 in der Praxis das Nadelöhr ist. Man kann Schwachstellen auch mit einer jährlichen manuellen Durchsicht managen. Was dabei fehlt, ist der Beleg für die Zeit dazwischen. Ein Scan bei jedem Commit hinterlässt zu jedem Fund eine Einordnung, eine Maßnahme und ein Datum, und diese Akte entsteht beim Arbeiten statt vor dem Prüftermin. Das ist der Grund für die Empfehlung, nicht eine Pflicht, die es nicht gibt.
Was der Scan nicht kann, und was das für die Pflicht heißt
Ein Scanner findet, was ein Muster hat. Geschäftslogik-Fehler, etwa eine fachlich falsche Berechtigungslogik, findet er nicht, und Designentscheidungen bewertet er nicht. Die Pflicht aus Nummer 5 endet aber nicht an der Grenze des Werkzeugs. Wer sie ganz erfüllen will, braucht neben dem Scan periodisch eine Prüfung dessen, was kein Muster hat, in der Regel einen Penetrationstest. Auch der ist nicht vorgeschrieben. Auch er ist ein Weg zum verlangten Ergebnis.
Für wen die Frage überhaupt gilt
§ 30 BSIG richtet sich an besonders wichtige und wichtige Einrichtungen. Ob ein Unternehmen dazu gehört, hängt von Sektor und Größe ab; unser NIS2-Schnellcheck klärt das in wenigen Minuten. Und unabhängig von NIS2 gilt: Wer keine eigene Software schreibt und keine eingekaufte selbst betreibt, hat nichts zu scannen. Wer eines von beidem hat, hat Schwachstellen zu managen, ob die Richtlinie ihn erfasst oder nicht. Ob es sich lohnt, zeigt die kostenlose Code-Analyse, ohne Verpflichtung.
Häufig gestellte Fragen
Steht irgendwo im Gesetz das Wort Scanner?
Nein. Weder in Artikel 21 der Richtlinie noch in § 30 BSIG. Verlangt wird Schwachstellenmanagement bei Entwicklung und Wartung und dessen Dokumentation, kein Produkt.
Reicht dann ein jährlicher Penetrationstest, um die Pflicht zu erfüllen?
Er belegt den Testtag. Die Pflicht zielt auf den laufenden Umgang mit Schwachstellen und dessen Dokumentation. Für die Zeit zwischen zwei Tests braucht es einen Beleg, und den liefert ein laufender Scan am einfachsten.
Wir fallen nicht unter NIS2. Ist die Frage für uns erledigt?
Die Pflicht ja, das Risiko nicht. Ein hartkodierter Schlüssel im Repository ist unabhängig vom Gesetz ein offenes Passwort. Ob es sich lohnt, hinzusehen, zeigt der Befund der kostenlosen Analyse.