CVSS reicht nicht: Schwachstellen mit EPSS, KEV und Asset-Kontext priorisieren

Edouard Jacques

Managing Director, Cyber Culture

Ihr Scanner sortiert die offenen Schwachstellen nach CVSS, ganz oben stehen ein paar Dutzend Einträge mit 9,8 oder 10,0. Wer diese Liste von oben nach unten abarbeitet, ist beschäftigt, aber nicht unbedingt sicherer. Dieser Artikel zeigt, was CVSS, EPSS und der KEV-Katalog jeweils messen, wo ihre Grenzen liegen und wie Sie daraus eine Entscheidungslogik bauen, die IT-Betrieb und Auditor gleichermaßen nachvollziehen können.

Was der CVSS-Wert tatsächlich misst

Das Common Vulnerability Scoring System wird von FIRST herausgegeben, einem internationalen Verbund von Incident-Response-Teams. Die aktuelle Version 4.0 ist seit November 2023 veröffentlicht. Die Spezifikation ist in einem Punkt deutlich: Der Base Score beschreibt die Schwere einer Schwachstelle anhand ihrer technischen Eigenschaften und unterstellt den ungünstigsten realistischen Fall über alle denkbaren Umgebungen hinweg. Ob es einen Exploit gibt, ob das System aus dem Internet erreichbar ist und ob darauf Ihre Lohnbuchhaltung läuft, fließt nicht ein.

Dafür sieht CVSS weitere Metrikgruppen vor. Mit Version 4.0 hat FIRST sogar eigene Bezeichnungen eingeführt: CVSS-B für den reinen Base Score, CVSS-BT mit Bedrohungsdaten, CVSS-BE mit Umgebungsdaten und CVSS-BTE mit beidem. Die Spezifikation fordert Anwender ausdrücklich auf, den Base Score um diese Werte zu ergänzen, bevor er in eine Risikobewertung einfließt. Scanner zeigen in der Regel trotzdem den Base Score aus der NVD oder vom Hersteller an. Das ist ein Schweregrad, keine Priorität.

Sichtbar wird das Problem, sobald ein großer Teil der Liste als High oder Critical eingestuft ist. Dann trennt der Wert nicht mehr zwischen dringend und später. Ihr Team entscheidet nach Bauchgefühl oder danach, welcher Patch sich am leichtesten verteilen lässt.

EPSS: Wahrscheinlichkeit statt Schwere

Das Exploit Prediction Scoring System, ebenfalls von FIRST, beantwortet eine andere Frage: Wie wahrscheinlich ist es, dass eine veröffentlichte CVE in den nächsten 30 Tagen tatsächlich ausgenutzt wird? Der Wert liegt zwischen 0 und 1, wird täglich für jede CVE neu berechnet und ist kostenlos per API und als CSV-Datei verfügbar. Seit März 2025 läuft die Modellversion 4. Zusätzlich gibt es ein Perzentil, das zeigt, wie eine CVE im Vergleich zu allen anderen bewertet ist.

Drei Einschränkungen sollten Sie kennen, bevor Sie EPSS in Ihre Regeln schreiben. Erstens kennt EPSS Ihre Umgebung nicht: keine Exposition, keine Kompensationsmaßnahmen, keine Auswirkung auf Ihr Geschäft. Zweitens gibt es keinen offiziellen Schwellenwert. Die oft zitierte Grenze von 0,1 hat laut EPSS-FAQ keine besondere Autorität, FIRST empfiehlt, den Schwellenwert an der eigenen Abarbeitungskapazität auszurichten. Drittens bewertet EPSS nur CVEs. Eine fehlerhafte Konfiguration, ein offener Management-Port oder ein Server ohne Herstellersupport tauchen dort gar nicht auf.

Ein weiterer Punkt wird in vielen Präsentationen falsch dargestellt. Die beliebte Rechnung „Risiko gleich CVSS mal EPSS mal Kritikalität“ hat keine methodische Grundlage. FIRST schreibt in derselben FAQ, dass die Multiplikation von EPSS und CVSS nicht Wahrscheinlichkeit mal Schwere ergibt und nie eine gute Idee ist. Die beiden Werte messen unterschiedliche Dinge auf unterschiedlichen Skalen.

Der KEV-Katalog: belegte Ausnutzung

Der Katalog der Known Exploited Vulnerabilities der US-Behörde CISA ist das härteste der drei Signale. Eine Schwachstelle wird nur aufgenommen, wenn sie eine CVE-Nummer hat, verlässliche Belege für eine Ausnutzung in freier Wildbahn vorliegen und es eine klare Abhilfe gibt, etwa ein Hersteller-Update. Anfang Oktober 2026 umfasst der Katalog rund 1.700 Einträge. Ein eigenes Feld zeigt, ob eine Lücke bekanntermaßen in Ransomware-Kampagnen genutzt wird. CISA empfiehlt allen Organisationen, KEV-Einträge in ihrem Schwachstellenmanagement als sofort zu behandeln festzulegen.

Für US-Bundesbehörden ist das verbindlich. Im Juni 2026 hat CISA die bisherige Direktive BOD 22-01 durch BOD 26-04 ersetzt. Die Fristen hängen dort von vier Fragen ab. Ist das System öffentlich erreichbar? Steht die Lücke im KEV-Katalog? Lässt sich die Ausnutzung automatisieren? Erlangt ein Angreifer teilweise oder vollständige Kontrolle? Für ein deutsches Unternehmen ist die Direktive nicht bindend. Als Vorlage taugt sie trotzdem, weil sie zeigt, mit wie wenigen Fragen sich eine belastbare Reihenfolge festlegen lässt.

Die Aufnahmekriterien haben eine Kehrseite. Eine gerade angegriffene Lücke, für die der Hersteller noch keine klare Abhilfe veröffentlicht hat, erfüllt das dritte Kriterium nicht. KEV ersetzt also nicht den Blick auf Herstellerwarnungen und Meldungen des BSI.

Asset-Kontext: Diesen Teil kennt nur Ihr Unternehmen

CVSS, EPSS und KEV kommen von außen. Ob eine Lücke Ihr Geschäft trifft, wissen nur Sie. Zwei Angaben reichen für den Anfang.

Die erste ist die Exposition. Ist das System aus dem Internet erreichbar, direkt oder über eine Portweiterleitung? VPN-Gateways, Remote-Desktop-Zugänge, Webserver und Mail-Gateways gehören in diese Gruppe. Die zweite ist die Kritikalität, und dafür genügen in den meisten mittelständischen Umgebungen drei Stufen:

• Systeme, deren Kompromittierung das ganze Unternehmen trifft, etwa Active Directory oder Entra ID, Backup-Server, ERP, zentrale Fileserver und Fernzugänge.
• Produktive Systeme einzelner Fachbereiche sowie die Arbeitsplätze.
• Test-, Schulungs- und Altsysteme ohne Produktivdaten, sofern sie tatsächlich vom Produktivnetz getrennt sind.

Die Liste entsteht selten aus der CMDB, die erfahrungsgemäß lückenhaft ist. Schneller geht es in einem zweistündigen Termin mit IT-Leitung und den Verantwortlichen für ERP und Produktion. Danach markieren Sie die Systeme im Scanner, als Tag oder Asset-Gruppe. Planen Sie eine Überprüfung pro Quartal ein, sonst stimmt die Einstufung nach dem nächsten Serverumzug nicht mehr.

Eine Entscheidungslogik statt einer Formel

Statt die Werte zu verrechnen, sortieren Sie Findings über wenige Ja-Nein-Fragen in Klassen. Die CISA hat dafür mit SSVC ein ausgearbeitetes Entscheidungsbaum-Modell veröffentlicht, dessen Ergebnisse von „Track“ (beobachten) bis „Act“ (sofort handeln) reichen. Für den Mittelstand genügt oft eine vereinfachte Variante. Ein Beispiel, das Sie als Startpunkt mit Ihrem IT-Betrieb abstimmen können:

1. Sofort, mit Notfall-Change und Workaround noch am selben Tag: KEV-Eintrag oder belegte Ausnutzung auf einem System, das aus dem Internet erreichbar ist.
2. Innerhalb dieser Woche: KEV-Eintrag auf einem internen System der höchsten Kritikalitätsstufe oder hoher EPSS-Wert auf einem exponierten System.
3. Im nächsten regulären Patchzyklus: hohe Schwere ohne Hinweise auf Ausnutzung.
4. Beobachten: niedrige Schwere, keine Ausnutzung, Test- und Altsysteme. Neu geprüft wird, wenn sich EPSS-Wert oder KEV-Status ändern.

Den Unterschied macht ein Detail. Die Klasse wird beim Eingang des Findings festgelegt und im Ticket gespeichert. EPSS-Werte ändern sich täglich, und würde die Priorität jeden Morgen neu berechnet, sprängen Tickets zwischen den Klassen hin und her. Dann vertraut niemand mehr der Liste. Eine wöchentliche Neubewertung offener Tickets reicht. Die Ausnahme ist die Aufnahme in den KEV-Katalog: Sie stuft ein Ticket sofort hoch.

Halten Sie die Logik in Ihrer Richtlinie fest, mit Fristen und Eskalationsweg. Auditoren nach ISO 27001 (Control A.8.8) und NIS2 fragen weniger nach dem Scanner als danach, nach welcher Regel Sie entschieden haben und ob Sie sich daran halten. Wie diese Nachweise aussehen, beschreiben wir unter Vulnerability Management auditfest für ISO 27001 und NIS2.

Typische Stolpersteine beim Umstieg

Am häufigsten scheitert ein Modell, das nur das Security-Team versteht. Wenn der Server-Administrator nicht nachvollziehen kann, warum sein Ticket „sofort“ heißt, behandelt er es wie jedes andere. Erklären Sie die vier Klassen in einer halben Stunde im Teammeeting des Betriebs, nicht per Rundmail.

Ebenso oft fehlt der Umgang mit Ausnahmen. Ein System, das sich nicht patchen lässt, braucht eine dokumentierte Ausnahme mit Begründung, Kompensationsmaßnahme, Verantwortlichem und Ablaufdatum. Ohne Ablaufdatum wird aus der Ausnahme eine Dauerlösung.

Und messen Sie nicht nur, wie viele Findings geschlossen wurden. Aussagekräftiger ist, wie viele Findings der ersten beiden Klassen ihre Frist überschritten haben. Diese eine Zahl gehört in den monatlichen Bericht an die Geschäftsführung.

Der erste Schritt in Ihrem Unternehmen

Nehmen Sie den aktuellen Export Ihres Scanners und gleichen Sie ihn mit dem KEV-Katalog ab, den CISA als CSV- und JSON-Datei bereitstellt. Filtern Sie dann auf die Systeme, die aus dem Internet erreichbar sind. Legen Sie das Ergebnis neben die obersten Einträge Ihrer bisherigen CVSS-Sortierung. Wo sich die beiden Listen unterscheiden, haben Sie den Gesprächsstoff für die erste Abstimmung mit Ihrem IT-Betrieb.

Wenn Sie Microsoft Defender einsetzen, zeigt der Artikel Microsoft Defender meldet 500 Schwachstellen, wo Sie diese Filter im Portal finden. Die Sicht der Geschäftsführung auf dieselbe Frage beschreibt Schwachstellen: was ist wirklich dringend?. Und wie wir die Priorisierung gemeinsam mit Ihrem Team einführen, steht unter Schwachstellen risikobasiert priorisieren.