§ 30 BSIG und der eigene Code: Welche datierten Nachweise ein Scan bei jedem Commit erzeugt

§ 30 Abs. 2 Nr. 5 BSIG verlangt Sicherheitsmaßnahmen bei Entwicklung und Wartung einschließlich Schwachstellenmanagement, und Abs. 1 verlangt, die Einhaltung zu dokumentieren. Was davon ein laufender Code-Scan als datierten Beleg erzeugt, was nicht, und was ein Prüfer sehen will.

Eine Reihe Archivordner mit farbigen, unbeschrifteten Rücken auf einem Regal in einem hellen IT-Büro, davor ein geschlossener Laptop.

Was § 30 BSIG tatsächlich verlangt

Der Wortlaut ist kürzer, als viele Anbieter ihn wiedergeben. Absatz 1 verpflichtet besonders wichtige und wichtige Einrichtungen zu geeigneten, verhältnismäßigen und wirksamen technischen und organisatorischen Maßnahmen und schließt mit einem Satz, der im Audit den Ton angibt: Die Einhaltung dieser Verpflichtung ist zu dokumentieren. Absatz 2 zählt dann auf, was die Maßnahmen zumindest umfassen müssen. Nummer 5 lautet: Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, Komponenten und Prozessen, einschließlich Management und Offenlegung von Schwachstellen. Nummer 6 verlangt zusätzlich Konzepte und Verfahren, um die Wirksamkeit dieser Maßnahmen zu bewerten.

Zwei Dinge fehlen in diesem Text, und beide fehlen absichtlich. Es steht kein Produkt darin, und es steht kein Verfahren darin. Der Gesetzgeber beschreibt ein Ergebnis, nämlich Schwachstellen kennen, behandeln und offenlegen können, und überlässt den Weg dorthin der Einrichtung. Wer eine Kaufpflicht für Scanner behauptet, liest etwas hinein, was nicht drinsteht. Das haben wir auf unserer Seite zu Code-Sicherheit und Compliance so festgehalten und halten es hier genauso.

Warum der eigene Code unter Nummer 5 fällt

Nummer 5 spricht von Systemen, Komponenten und Prozessen, nicht von Software im engeren Sinn. In der Praxis liegen die Schwachstellen, die ein Angreifer zuerst findet, aber genau dort: in einem API-Schlüssel, der vor drei Jahren eingecheckt wurde und noch immer im Verlauf des Repositories liegt, in einer Open-Source-Bibliothek, für die seit Monaten eine Lücke bekannt ist, oder in einer Eingabe, die ungeprüft an eine Datenbank weitergereicht wird. Alle drei sind Schwachstellen im Sinne der Norm. Alle drei entstehen bei Entwicklung oder Wartung. Und alle drei lassen sich nur dann managen, wenn jemand sie regelmäßig sucht.

Genau das ist der Punkt, an dem eine jährliche Prüfung scheitert. Ein Fund vom März sagt nichts über den Commit vom Juni. Nummer 5 verlangt kein Datum, aber die Dokumentationspflicht aus Absatz 1 verlangt eines, und ein Prüfer, der die Akte liest, fragt als Erstes, wie aktuell sie ist.

Was ein Scan bei jedem Commit als Beleg hinterlässt

Ein laufender Scan erzeugt pro Fund vier Datenpunkte, und das sind genau die vier, die in eine Akte gehören. Erstens der Fund selbst: hartkodiertes Passwort, verwundbare Abhängigkeit, unsicheres Muster. Zweitens die Einordnung nach echtem Risiko, nachdem ein Mensch geprüft hat, ob der Fund im Zusammenhang der Codebasis überhaupt ausnutzbar ist. Drittens die Maßnahme: Secret rotiert, Bibliothek aktualisiert, Muster entschärft. Viertens das Datum, an dem die Maßnahme umgesetzt wurde.

Aus diesen vier Punkten wird über Wochen eine Dokumentation, die nicht vor dem Audit zusammengesucht werden muss, weil sie beim Arbeiten entsteht. Wie das für die übrigen NIS2-Pflichten funktioniert, steht in unserem Beitrag zur NIS2-Nachweispflicht im Alltag. Für den Code gilt dasselbe Prinzip, nur mit einem anderen Werkzeug.

Was ebenfalls in die Akte gehört, ist das, was nicht drinsteht: Falschmeldungen werden aussortiert, bevor sie den Bericht erreichen. Ein Prüfer, der 400 Treffer sieht, von denen 380 nicht ausnutzbar waren, lernt daraus nichts über die Sicherheit, nur etwas über den Scanner.

Was ein Nachweis nicht sein sollte

Drei Formen tauchen im Mittelstand immer wieder auf, und keine hält einer Nachfrage stand. Die Rohliste eines Scanners ohne Einordnung: Sie belegt, dass ein Werkzeug gelaufen ist, nicht, dass jemand gehandelt hat. Der Screenshot vom Jahresende: Er belegt einen Tag, nicht einen Prozess. Und die Eigenerklärung im Fragebogen, dass sicher entwickelt wird: Sie belegt, dass jemand ein Kreuz gesetzt hat.

Nummer 6 des Absatzes 2 macht es noch deutlicher. Wer die Wirksamkeit seiner Maßnahmen bewerten soll, braucht Daten darüber, ob die Maßnahme im Zeitverlauf gewirkt hat. Welche drei Fragen das BSI dazu stellt und welche davon ein Scanner beantworten kann, haben wir in einem eigenen Beitrag zur Wirksamkeitsbewertung nach § 30 BSIG auseinandergenommen.

Woher der Beleg kommt, Schritt für Schritt

Am Tag 0 werden die Repositories angebunden und der Bestand erstmalig auf Secrets, verwundbare Abhängigkeiten und unsichere Muster durchsucht. Nach 48 Stunden liegt der erste Befund vor: was echt und kritisch ist, was warten kann, was zuerst passieren muss. In der ersten Woche werden kritische Secrets rotiert, Bibliotheken aktualisiert, gefährliche Muster entschärft, und jede dieser Maßnahmen bekommt ein Datum. Ab dann läuft die Prüfung bei jedem Commit weiter, und die Akte wächst mit dem Code statt vor dem Prüftermin.

Der Einstieg ist die kostenlose Code-Analyse: Anbindung, Bestandsscan und priorisierter Befund, ohne Verpflichtung, auf Wunsch in der eigenen Umgebung.

Häufig gestellte Fragen

Muss ich für § 30 Abs. 2 Nr. 5 BSIG einen Scanner kaufen?

Nein. Die Norm verlangt Sicherheitsmaßnahmen bei Entwicklung und Wartung samt Schwachstellenmanagement und die Dokumentation der Einhaltung. Womit eine Einrichtung das erreicht, ist ihre Entscheidung. Ein laufender Scan ist eine Maßnahme, die den Beleg gleich mitliefert, keine gesetzliche Vorgabe.

Reicht ein jährlicher Penetrationstest als Nachweis für Nummer 5?

Er belegt, was am Testtag von außen erreichbar war. Nummer 5 zielt auf den Prozess bei Entwicklung und Wartung, und der findet zwischen den Tests statt. Beides gehört zusammen: der Test als periodische Tiefenprüfung, der Scan als laufende Hygiene mit Datum.

Wir schreiben keinen eigenen Code. Betrifft uns Nummer 5 trotzdem?

Es kommt darauf an, was Ihr betreibt. Eine gekaufte Anwendung auf eigenen Servern besteht aus Paketen, die altern, und Einstellungen, die niemand mehr anfasst, und beides ist Wartung im Sinne von Nummer 5. Läuft dagegen alles bei Dritten, gibt es nichts anzubinden; dann ist der bessere Startpunkt unser Darknet-Monitoring.