Blog

Schwachstellenmanagement nach NIS2 und ISO 27001: Was Dev-Teams tun müssen

Weder NIS2 noch ISO 27001 schreiben dir ein Werkzeug vor. Beide verlangen aber, dass du von Lücken in deinen Systemen erfährst, sie bewertest, handelst und das belegen kannst. Was das für ein Team mit GitHub-Repos konkret heißt.

Aktualisiert am 25. Oktober 2026 · Stackwatch-Team

Was die Regeln verlangen

NIS2. Die EU-Richtlinie 2022/2555 verlangt in Art. 21 Abs. 2 Buchst. e Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Systemen, einschließlich des Umgangs mit Schwachstellen. In Deutschland setzt das NIS2-Umsetzungsgesetz das um. Die Pflicht steht jetzt in § 30 Abs. 2 Nr. 5 BSI-Gesetz (BSIG): „Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, Komponenten und Prozessen, einschließlich Management und Offenlegung von Schwachstellen“. Nach § 30 Abs. 1 BSIG muss die Einhaltung dokumentiert werden.

ISO 27001. Annex A der ISO/IEC 27001:2022 enthält das Control A.8.8 „Management technischer Schwachstellen“. Sinngemäß: Informationen über technische Schwachstellen der eingesetzten Systeme beschaffen, die eigene Gefährdung bewerten und angemessene Maßnahmen ergreifen. Feste Patch-Fristen nennt die Norm nicht, sie sind risikobasiert und stehen in deiner eigenen Richtlinie.

Ob dein Unternehmen unter NIS2 fällt, prüfst du über die Betroffenheitskriterien des BSI. Für ISO 27001 gilt A.8.8 für alle, die zertifiziert sind oder es werden wollen.

Übersetzt in die Arbeit eines Dev-Teams

Beide Regelwerke laufen auf denselben Kreislauf hinaus:

Inventar: Welche Systeme, Runtimes, Frameworks und Pakete setzen wir ein, mit welchen Versionen?
Informieren: Wie erfahren wir von neuen Lücken, die diese Komponenten betreffen?
Bewerten: Sind wir betroffen, und wie dringend ist es?
Handeln: Patchen, Workaround oder bewusst akzeptieren, mit Begründung.
Nachprüfen: Ist der Fix wirklich ausgerollt?
Belegen: Wer hat wann was gewusst und getan?

Was Auditoren typischerweise sehen wollen

Eine Richtlinie mit Zuständigkeiten und Fristen je Schweregrad, zum Beispiel: Critical mit aktiver Ausnutzung sofort, Critical innerhalb von 72 Stunden, High innerhalb von 14 Tagen. Die Werte legst du selbst fest.
Ein Inventar der eingesetzten Software, das aktuell gehalten wird, zum Beispiel aus Repos, Lockfiles und Dockerfiles abgeleitet.
Belege für einzelne Fälle: Wann kam die Meldung, wer hat sie bestätigt, wann wurde gepatcht, wie wurde nachgeprüft?
Ausnahmen mit Begründung und Ablaufdatum, wenn ihr eine Lücke bewusst nicht sofort schließt.

Der häufigste Schwachpunkt in kleinen Teams ist nicht der Patch selbst, sondern Schritt 2 und 6: Man erfährt zufällig von einer Lücke, und hinterher lässt sich nicht mehr belegen, wann.

Typische Lücken im Prozess

Runtimes fehlen im Inventar. Paket-Scanner erfassen Lockfiles, aber nicht die PHP- oder Node.js-Version im Dockerfile. Bei PHP2Shell war genau das der blinde Fleck. Welches Werkzeug was erfasst, zeigt die Übersicht Dependabot-Alternativen 2026.
Alerts ohne Zuständigkeit. Meldungen landen in einem Postfach oder Tab, den niemand verantwortet.
Kein Nachweis der Prüfung. „Wir haben uns das angesehen, betrifft uns nicht“ ist eine gültige Entscheidung, aber nur mit Datum und Begründung.
Keine Priorisierung. Wer alles gleich behandelt, schafft nichts rechtzeitig. Wie du sortierst, steht im Artikel zu CVSS, EPSS und KEV.

Wie Stackwatch dabei hilft

Stackwatch deckt die Schritte Inventar bis Belegen für deine GitHub-Repos ab: Es erkennt den Stack bis zur Runtime mit Beleg aus Datei und Zeile, gleicht neue Lücken ab, meldet Treffer mit Fix und Workaround, prüft nach dem Patch per Re-Scan nach und schreibt jede Meldung, Bestätigung und Statusänderung in ein manipulationserkennendes Audit-Log (verkettete Prüfsummen) mit CSV-Export. Die Richtlinie und die Entscheidung, was ihr tut, bleiben bei euch. Hosting, AVV und Berechtigungen beschreibt die Seite Sicherheit und Datenschutz.

Quellen

Häufige Fragen

Was verlangt NIS2 beim Umgang mit Schwachstellen?

Art. 21 Abs. 2 Buchst. e der Richtlinie 2022/2555 verlangt Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Systemen, einschließlich des Umgangs mit Schwachstellen. In Deutschland steht die Pflicht in § 30 Abs. 2 Nr. 5 BSIG, nach § 30 Abs. 1 BSIG muss die Einhaltung dokumentiert werden.

Was fordert ISO 27001 zu Schwachstellen?

Das Control A.8.8 (Management technischer Schwachstellen) in Annex A der ISO/IEC 27001:2022: Informationen über technische Schwachstellen beschaffen, die eigene Gefährdung bewerten und angemessene Maßnahmen ergreifen. Feste Patch-Fristen nennt die Norm nicht, sie sind risikobasiert und stehen in deiner eigenen Richtlinie.

Fällt mein Unternehmen unter NIS2?

Das prüfst du über die Betroffenheitskriterien des BSI. Für ISO 27001 gilt A.8.8 für alle, die zertifiziert sind oder es werden wollen.

Was wollen Auditoren typischerweise sehen?

Eine Richtlinie mit Zuständigkeiten und Fristen je Schweregrad, ein aktuell gehaltenes Inventar der eingesetzten Software, Belege für einzelne Fälle (Meldung, Bestätigung, Patch, Nachprüfung) und Ausnahmen mit Begründung und Ablaufdatum.

Wo hakt es in kleinen Teams am häufigsten?

Meist nicht beim Patch selbst, sondern beim Informieren und beim Belegen: Man erfährt zufällig von einer Lücke, und hinterher lässt sich nicht mehr belegen, wann. Typisch sind außerdem Runtimes, die im Inventar fehlen, und Alerts ohne Zuständigkeit.

Wie belege ich, wann wir von einer Lücke wussten und was wir getan haben?

Mit Datum und Begründung zu jeder Entscheidung, auch zu der, dass dich eine Lücke nicht betrifft. Stackwatch schreibt jede Meldung, Bestätigung und Statusänderung in ein manipulationserkennendes Audit-Log (verkettete Prüfsummen) mit CSV-Export. Die Richtlinie und die Entscheidung, was ihr tut, bleiben bei euch.