Leitfaden für ein Vulnerability-Management-Programm: Von der Schwachstellenanalyse zur Behebung (2026)

Vulnerability Management ist eine der operativ anspruchsvollsten Sicherheitsdisziplinen — und eine der am häufigsten von Prüfern im Rahmen von DORA, NIS2 und ISO 27001 untersuchten. Dieser Leitfaden beschreibt, wie man ein vollständiges, vertretbares und verhältnismäßiges Programm aufbaut: von Scan-Architektur und Asset-Abdeckung über risikobasierte Priorisierung bis hin zu SLAs, Metriken und regulatorischen Nachweisen.

Warum Vulnerability Management mehr als nur Scanning ist

Viele Organisationen betreiben einen Scanner und glauben, damit ein Vulnerability-Management-Programm zu haben. Scanning ist der erste Schritt — nicht der gesamte Prozess. Ein reifes Vulnerability-Management-Programm erfordert:

• Asset-Inventar. Man kann nicht scannen, was man nicht kennt. Ohne ein genaues, aktuelles Asset-Inventar ist die Scan-Abdeckung unbekannt — und unbekannte Abdeckung ist selbst ein Risiko.
• Risikobasierte Priorisierung. Scanner produzieren tausende Befunde. Ohne eine Triage-Methodik sind Teams überfordert und die gefährlichsten Schwachstellen erhalten möglicherweise nicht zuerst Aufmerksamkeit.
• Zuständigkeit für Behebung. Identifizierte Schwachstellen brauchen Verantwortliche, die für deren Behebung zuständig sind und durch einen Workflow mit messbaren SLAs verfolgt werden.
• Metriken und Berichterstattung. Führung und Prüfer müssen Nachweise über die Programmeffektivität sehen — nicht nur eine Liste von Befunden.
• Kontinuierliche Verbesserung. Abdeckung, Tools, SLAs und Prozesse müssen regelmäßig überprüft werden, wenn sich die Umgebung ändert.

Das Asset-Inventar als Grundlage

Ein Asset-Inventar ist das Fundament, das jede Prüfung zuerst prüft. Für Vulnerability-Management-Zwecke benötigen Sie:

• Eine Liste aller Hardware-Assets (Server, Endgeräte, Netzwerkgeräte, OT/IoT wo zutreffend)
• Alle Software-Assets und Versionen, die in der Umgebung laufen
• Klare Klassifizierung der Assets nach Kritikalität (kritisch, wichtig, standard) — verknüpft mit Geschäftsfunktionen
• Cloud-Assets einbezogen — Cloud-VMs, Container und serverlose Workloads fehlen häufig in Inventaren
• Von Drittanbietern verwaltete Komponenten klar identifiziert — Zuständigkeit für Scanning und Behebung muss definiert sein
• Das Inventar wird mindestens vierteljährlich oder bei wesentlichen Änderungen überprüft und aktualisiert

Scan-Architektur und Abdeckung

Ziel der Scan-Architektur ist eine vollständige, authentifizierte Abdeckung mit genauen und zeitnahen Befunden. Gängige Varianten:

Authentifiziertes vs. nicht-authentifiziertes Scanning

Nicht-authentifiziertes (netzwerkbasiertes) Scanning zeigt, was ein Angreifer vom Netzwerk aus sehen kann. Authentifiziertes Scanning meldet sich in Systemen an und liefert ein wesentlich vollständigeres Bild von installierter Software, Patch-Levels und lokaler Konfiguration. Für jedes ernsthafte Programm ist authentifiziertes Scanning der Standard — nicht-authentifiziertes Scanning allein wird die Mehrheit der Schwachstellen übersehen.

Scan-Häufigkeit

• Scan-Credentials werden gemäß der Zugangsverwaltungsrichtlinie der Organisation gepflegt und rotiert
• Scan-Abdeckung wird als Prozentsatz des bekannten Asset-Inventars gemessen — und diese Metrik wird berichtet
• Ausschlüsse vom Scanning sind mit einer geschäftlichen Begründung dokumentiert und werden regelmäßig überprüft
• Cloud-Assets werden abgedeckt — entweder durch agentenbasiertes Scanning oder über cloud-native Integrationen
• Scan-Ergebnisse werden für Prüfzwecke aufbewahrt (mindestens 12 Monate, länger unter DORA)

Risikobasierte Triage und Priorisierung

Ein CVSS-Score allein ist keine ausreichende Grundlage für die Priorisierung. CVSS misst den intrinsischen Schweregrad einer Schwachstelle in Isolation; er berücksichtigt weder Ihre Umgebung, die Ausnutzbarkeit in der Praxis noch die Asset-Kritikalität. Ein reifer Priorisierungsansatz kombiniert:

• CVSS-Basis-Score — ein Ausgangspunkt, nicht das Ziel
• Asset-Kritikalität — ein kritischer Befund auf einem System, das eine Kernbankenfunktion unterstützt, ist dringlicher als derselbe Befund auf einem Testserver
• Ausnutzbarkeit in der Praxis — der KEV-Katalog der CISA und Bedrohungsintelligenz-Feeds identifizieren, welche Schwachstellen aktiv ausgenutzt werden; diese haben typischerweise die höchste Priorität unabhängig vom CVSS
• Exposition — internetexponierte Systeme tragen ein höheres Risiko als interne Systeme mit starker Netzwerksegmentierung
• Kompensierende Kontrollen — eine Schwachstelle kann im Kontext durch eine WAF, Netzwerkkontrolle oder Konfiguration gemildert sein, die die reale Ausnutzbarkeit reduziert

• Eine dokumentierte Risikobewertungsmethodik existiert und wird konsistent angewendet
• Die Organisation abonniert relevante Bedrohungsintelligenz (mindestens CISA KEV, NVD, ENISA-Advisories und Sicherheitsbulletins der Hersteller)
• Kritische und aktiv ausgenutzte Schwachstellen haben einen beschleunigten Triage- und Behebungspfad, getrennt vom Standard-SLA

SLAs und Behebungs-Workflow

SLAs machen das Programm messbar und auditierbar. Ohne definierte Behebungsfristen ist jeder Befund effektiv optional. DORA und NIS2 erfordern beide dokumentierte Patch-Management-Prozesse; Prüfer werden nach SLA-Definitionen und Compliance-Nachweisen fragen.

• SLAs sind pro Schweregrad definiert und formal genehmigt
• Schwachstellen-Befunde werden in einem Ticketing-System (oder einer Vulnerability-Management-Plattform) mit Verantwortlichem, Fälligkeitsdatum und Status verfolgt
• SLA-Compliance wird gemessen und berichtet — der Prozentsatz der innerhalb des SLA behobenen Befunde ist ein zentraler KPI
• Ausnahme- und Risikoakzeptanzprozesse existieren: Befunde, die nicht innerhalb des SLA gepatcht werden können, werden mit Dokumentation als Risiko akzeptiert — nicht stillschweigend versäumt
• Behobene Befunde werden mit einem Follow-up-Scan verifiziert, nicht nur vom Verantwortlichen als geschlossen markiert

DORA- und NIS2-Anforderungen für Vulnerability Management

Sowohl DORA als auch NIS2 adressieren Schwachstellen- und Patch-Management explizit als erforderliche Sicherheitsfähigkeiten:

• DORA (Artikel 9): Das IKT-Risikomanagement muss Patch-Management als Schutzmaßnahme umfassen und alle IKT-Assets abdecken. Schwachstellenidentifikation und -behebung werden explizit erwartet.
• DORA (Säule 3 / Artikel 25): Das Resilienztestprogramm muss Schwachstellenbewertungen und Penetrationstests umfassen. Befunde aus Tests müssen verfolgt und behoben werden — nicht nur dokumentiert.
• NIS2 (Artikel 21(2)(e)): Sicherheit in der Beschaffung, Entwicklung und Wartung von Netz- und Informationssystemen umfasst Richtlinien zur Schwachstellenbehandlung und -offenlegung sowie Patch-Management als Mindestmaßnahme.
• NIS2 (Artikel 21(2)(g)): Grundlegende Cyberhygiene umfasst explizit Patching.

• Vulnerability Management ist als formales Programm mit Richtlinie, Scope, Prozess und verantwortlichem Eigentümer dokumentiert
• Das Programm deckt alle Systeme ab, die kritische oder wichtige Funktionen unterstützen (wie unter DORA oder NIS2 definiert)
• Nachweise für Prüfer sind vorhanden: Scan-Berichte, Behebungsaufzeichnungen, SLA-Compliance-Metriken und Ausnahmeprotokolle
• Penetrationstest-Befunde werden durch den Vulnerability-Management-Workflow verfolgt, nicht in einem separaten Silo

Metriken, die wirklich zählen

Ein Vulnerability-Management-Programm sollte Metriken produzieren, die sowohl für technische Teams als auch für die Führungsebene bedeutsam sind. Die nützlichsten:

• Abdeckungsrate: Prozentsatz des Asset-Inventars, der im letzten Scan-Zyklus erfolgreich gescannt wurde
• Mittlere Zeit bis zur Behebung (MTTR): durchschnittliche Zeit von der Befundidentifikation bis zur verifizierten Schließung, pro Schweregrad
• SLA-Compliance-Rate: Prozentsatz der innerhalb des definierten SLA behobenen Befunde, nach Schweregrad
• Kritischer Rückstand: Anzahl offener kritischer und hoher Befunde — der Trend ist genauso wichtig wie die absolute Zahl
• Wiederauftreten: wie oft Befunde nach Schließung wieder auftreten — eine hohe Rate signalisiert Qualitätsprobleme bei der Behebung
• Ausnahme-Alter: wie lange risikoakzeptierte Ausnahmen ohne Überprüfung offen waren

Die fünf Reifegradlücken, die wir am häufigsten sehen

1. Teilweise Abdeckung, die für vollständig gehalten wird. Organisationen schließen große Teile ihrer Umgebung vom Scanning aus (Cloud, OT, Remote-Standorte) und messen die Lücke nicht. Abdeckungsmetriken machen blinde Flecken sichtbar.
2. CVSS als einziges Triage-Signal. Ohne Ausnutzbarkeits-Daten und Asset-Kritikalität investieren Teams Aufwand in risikoarme High-Befunde, während KEV-gelistete kritische Befunde in der Warteschlange warten.
3. Befunde ohne Verantwortlichen. Vulnerability Management erfordert einen namentlich genannten Verantwortlichen pro Befund — nicht nur eine Team-Queue. Anonyme Backlogs wachsen unkontrolliert.
4. SLAs, die existieren, aber nicht gemessen werden. SLAs in einem Richtliniendokument zu definieren und die Compliance tatsächlich zu messen, sind verschiedene Dinge. Prüfer fragen nach Compliance-Nachweisen, nicht nur nach der Definition.
5. Penetrationstest-Befunde in einem separaten Spreadsheet. Ergebnisse aus Penetrationstests und TLPT-Übungen gehören in den Vulnerability-Management-Workflow. Isoliertes Tracking bedeutet, dass sie ohne systematische Nachverfolgung veralten.

Wie SephiraSec helfen kann

SephiraSec entwirft und reift Vulnerability-Management-Programme in Unternehmensumgebungen — einschließlich Tenable SC Scan-Architektur, risikobasierter Triage-Frameworks, SLA-Definition, CMDB-Integration, DORA/NIS2-Nachweispaketen und Management-Reporting. Mit Sitz in Wien, verfügbar in der gesamten EU, auf Englisch, Deutsch und Rumänisch.