Der CVE-Flood: Warum „Alles patchen” keine Strategie mehr ist
Die Zahlen sprechen eine klare Sprache: Das National Vulnerability Database (NVD) verzeichnete 2023 über 28.000 neu gemeldete CVEs – ein Anstieg von mehr als 15 Prozent gegenüber dem Vorjahr. Seit 2017 hat sich das jährliche CVE-Volumen nahezu verdoppelt. Für Security-Teams bedeutet das eine schlichte operative Wahrheit: Vollständige Remediation ist keine realistische Zielsetzung mehr.
Die Folgen sind systemischer Natur. Teams verbringen den Großteil ihrer Kapazitäten damit, Scan-Reports abzuarbeiten, priorisieren dabei nach Schweregrad-Scores und geraten trotzdem nie aus dem Rückstand. Patches werden deployed, ohne dass sich die tatsächliche Risikolage messbar verbessert. Das klassische Mantra – scan, report, patch – funktioniert in Umgebungen mit Tausenden von Assets und Hunderttausenden von Findings schlicht nicht mehr. Das Ergebnis ist kein schlechtes Sicherheitsniveau durch mangelnden Einsatz, sondern durch falsche Prioritäten.
Die Checklisten-Falle: Was klassisches Vulnerability Management falsch macht
Das dominante Modell im Vulnerability Management folgt einem compliance-getriebenen Ablauf: Ein Scanner identifiziert Schwachstellen, ein Report wird generiert, Tickets werden nach CVSS-Score verteilt. Alles mit CVSS ≥ 9.0 ist „Critical”, alles ≥ 7.0 ist „High” – und entsprechend werden Ressourcen verteilt.
Das Problem liegt nicht im CVSS-System selbst, sondern in seiner Verwendung als alleiniges Priorisierungskriterium. CVSS bewertet technische Eigenschaften einer Schwachstelle in der Theorie – Angriffskomplexität, benötigte Privilegien, Scope. Was CVSS nicht beantwortet: Wird diese Schwachstelle gerade aktiv ausgenutzt? Ist das betroffene Asset geschäftskritisch? Ist es überhaupt aus dem Internet erreichbar?
Ein CVE mit einem CVSS-Score von 9.8 auf einem isolierten Entwicklungssystem, das kein Produktionsnetz erreicht, ist operativ weit weniger dringend als eine 6.5er-Schwachstelle in einer öffentlich exponierten Applikation, für die bereits ein Exploit im Umlauf ist. Wer ausschließlich nach CVSS priorisiert, verschwendet Kapazitäten für Low-Impact-Findings und lässt tatsächlich gefährliche Lücken offen.
Risk-Based Prioritization: Die Metriken, die wirklich zählen
Ein risikobasierter Ansatz kombiniert mehrere Datenpunkte zu einem kontextsensitiven Risikobild:
EPSS (Exploit Prediction Scoring System): Das von FIRST entwickelte Modell schätzt auf Basis von Threat Intelligence, Codeanalyse und historischen Exploit-Daten die Wahrscheinlichkeit, dass eine Schwachstelle innerhalb von 30 Tagen in freier Wildbahn ausgenutzt wird. Eine CVE mit EPSS-Score 0.95 verdient unabhängig ihres CVSS-Wertes sofortige Aufmerksamkeit.
CISA KEV (Known Exploited Vulnerabilities): Die CISA-Liste dokumentiert Schwachstellen, die nachweislich aktiv ausgenutzt werden. KEV-Einträge sind keine Prognose, sondern Evidenz – und sollten in jedem Priorisierungsmodell automatisch in die höchste Risikoklasse eingeordnet werden.
Bild: Beispiel einer Matrix aus CVSS und EPSS zur Dringlichkeitsbetrachtung (aus TrustSource)
Asset Exposure: Eine Schwachstelle auf einem internet-exponierten, nicht WAF-geschützten System mit privilegiertem Datenzugriff ist fundamental anders zu bewerten als dieselbe Schwachstelle in einer air-gapped Umgebung. Asset-Inventar und Netzwerktopologie müssen in das Scoring einfließen.
Business Context: Welche Systeme sind geschäftskritisch? Welche verarbeiten personenbezogene Daten oder unterliegen regulatorischen Anforderungen? Diese Information transformiert ein technisches Risk-Scoring in eine unternehmensspezifische Priorisierung.
Die Kombination dieser Signale erlaubt eine Priorisierungslogik, die nicht mehr fragt „Wie schwerwiegend ist diese Schwachstelle technisch?” – sondern „Wie wahrscheinlich ist eine Ausnutzung, und welchen Schaden würde sie in unserem spezifischen Kontext anrichten?”
Eine risikobasierte Vulnerability Pipeline aufbauen: Von der Detection zur Entscheidung
Die operative Umsetzung erfordert Integration auf mehreren Ebenen. Ein funktionierender Risk-Based-Pipeline-Ansatz besteht aus folgenden Elementen:
Detection Layer: Vulnerability-Scanner (Qualys, Tenable, Rapid7 o. ä.) liefern die Rohfundings. Diese müssen mit einem aktuellen Asset-Inventar angereichert werden – idealerweise automatisiert über CMDB-Integration oder Agenten-basierte Discovery.
Enrichment Layer: Jedes Finding wird mit Threat Intelligence angereichert: EPSS-Score, KEV-Status, öffentliche Exploit-Verfügbarkeit (via ExploitDB, Metasploit-Module, GitHub-PoCs). Dieser Schritt transformiert das technische Finding in ein kontextualisiertes Risikoobjekt.
Prioritization Layer: Auf Basis definierter Regeln – etwa „KEV-Eintrag + internet-exponiertes Asset = P1 mit 48h-SLA” – werden Findings automatisch klassifiziert. Die Priorisierungslogik muss dokumentiert, nachvollziehbar und regelmäßig überprüft werden.
Ownership und SLA: Security identifiziert und priorisiert, Engineering remediated. Klare Ownership-Modelle mit definierten Eskalationspfaden sind entscheidend. SLAs sollten risikobasiert definiert sein – nicht „alle Criticals in 30 Tagen”, sondern „P1-Findings (KEV + Exposition) in 48 Stunden, P2 in 7 Tagen, P3 in 30 Tagen”.
Messen, was zählt: KPIs für Risikoreduktion statt Patch-Velocity
Der häufigste Messfehler im Vulnerability Management: Patch-Rate als primäre KPI. Eine hohe Patch-Rate kann bei falscher Priorisierung sogar kontraproduktiv sein – wenn Low-Risk-Findings gepatcht werden, während kritische Lücken offen bleiben.
Sinnvollere Metriken für ein risikobasiertes Programm:
- MTTR nach Risikoklasse: Mean Time to Remediate getrennt nach P1/P2/P3. Verbessert sich die MTTR für die höchsten Risikoklassen? Das ist die relevante Frage.
- KEV Coverage Rate: Welcher Prozentsatz der CISA KEV-Einträge ist in der eigenen Umgebung gepatcht oder mitigiert? Diese Kennzahl ist direkt mit realem Bedrohungsgeschehen verknüpft.
- Reduction of Exploitable Attack Surface: Wie viele aktiv exploitable Findings (EPSS > 0.5 + Exposition) existieren im Zeitverlauf? Ein sinkender Trend zeigt echte Risikoreduzierung.
- Risk Acceptance Rate: Wie viele Findings werden formal akzeptiert, und auf welcher Risikobasis? Transparenz hier schützt vor implizitem Risiko.
Diese Metriken ermöglichen eine Stakeholder-Kommunikation, die über „wir haben X Prozent der CVEs gepatcht” hinausgeht – hin zu „unsere Exposition gegenüber aktiv ausgenutzten Schwachstellen ist um Y Prozent gesunken”.
Typische Fehler und wie man sie vermeidet
Die Einführung risikobasierter Vulnerability-Management-Prozesse scheitert häufig an vorhersehbaren Stellen:
Tool-Overload ohne Prozessreife: Wer vier verschiedene Scanner, zwei Threat-Intel-Feeds und ein SOAR-System integriert, bevor grundlegende Prozesse definiert sind, erzeugt mehr Rauschen als Klarheit. Tool-Entscheidungen sollten Prozessentscheidungen folgen, nicht umgekehrt.
Fehlende Developer-Integration: Vulnerability Management, das ausschließlich in der Security-Abteilung stattfindet, scheitert an der Remediation. Engineering-Teams müssen früh eingebunden werden – Findings müssen in deren Toolchain (Jira, GitHub Issues) sichtbar sein, und Security muss Kontext liefern, nicht nur Tickets.
Ungekalibrierte Risikomodelle: Ein Risikomodell, das 2022 kalibriert wurde und seitdem unverändert läuft, bildet die aktuelle Bedrohungslandschaft nicht mehr zuverlässig ab. Regelmäßige Reviews – mindestens quartalsweise – sind keine Option, sondern Pflicht.
Risk-Based als Rechtfertigung für Nicht-Patchen: Der gefährlichste Missbrauch des Ansatzes: Findings werden als „low risk” klassifiziert, um Remediation aufzuschieben, ohne dass das Risikomodell diese Einschätzung tatsächlich stützt. Risikobasierte Priorisierung bedeutet intelligentes Patchen – nicht weniger Patchen.
Von reaktiv zu strategisch: Der Reifegrad-Pfad
Vulnerability Management entwickelt sich entlang eines Reifegradmodells:
- Ad hoc: Scanner-Output wird manuell verarbeitet, keine konsistente Priorisierung, hohe MTTR, reaktive Reaktion auf Incidents.
- Defined: Dokumentierte Prozesse, CVSS-basierte Priorisierung, SLA-Definitionen – aber noch kein Kontext-Enrichment.
- Risk-Driven: Integration von EPSS, KEV, Asset-Kontext; automatisierte Priorisierungslogik; risikobasierte SLAs und KPIs.
- Continuous: Geschlossene Feedback-Loops zwischen Security, Engineering und Business; kontinuierliche Kalibrierung des Risikomodells; Vulnerability Management als Input für strategische Architekturentscheidungen.
Teams auf Level 1-2 sollten zunächst Asset-Inventar und KEV-Integration priorisieren – das sind die zwei Maßnahmen mit dem größten unmittelbaren Impact. Teams auf Level 2-3 sollten EPSS-Integration und risikobasierte SLA-Definitionen angehen. Level 3-Teams arbeiten an der kontinuierlichen Kalibrierung und der strategischen Verankerung des Programms.
Drei Kernergebnisse:
- CVSS allein ist kein Priorisierungskriterium – ohne Exploitability-Daten (EPSS, KEV) und Asset-Kontext führt es zu systematisch falschen Prioritäten.
- Patch-Rate ist die falsche KPI – relevanter ist die Reduktion der Exposition gegenüber aktiv ausgenutzten Schwachstellen, messbar über KEV Coverage und exploitable Attack Surface.
- Risk-Based Vulnerability Management ist keine Tool-Frage, sondern eine Prozess- und Kulturfrage: Ohne Developer-Integration, klare Ownership-Modelle und regelmäßige Kalibrierung bleibt das Modell wirkungslos.