CVE-Priorisierung mit EPSS und CERT-Bund: Patchen, was angegriffen wird
Eine Schwachstelle mit CVSS 9,2 klingt nach Alarmstufe Rot. Nur: Kritisch eingestufte CVEs gibt es viele, und die Zeit der IT-Teams reicht nie für alle gleichzeitig. Wer stur nach Schweregrad patcht, arbeitet fleißig eine Liste ab und übersieht im Zweifel genau die Lücke, die gerade angegriffen wird.
Die bessere Frage lautet deshalb: Welche Schwachstelle wird mit hoher Wahrscheinlichkeit ausgenutzt, und betrifft sie unsere Systeme? Drei Datenquellen helfen bei der Antwort: CVSS, EPSS und CERT-Bund.
CVSS misst die Schwere, nicht das Risiko
Der Wert des Common Vulnerability Scoring System (CVSS) beschreibt, wie schwer eine Schwachstelle technisch wiegt. In die Bewertung fließen Angriffsvektor, Komplexität und die Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit ein. Aktuell sind zwei Versionen im Umlauf, CVSS 3.1 und CVSS 4.0.
Das Problem: Ob eine Schwachstelle jemals in einem realen Angriff auftaucht, verrät der CVSS-Wert nicht. Viele Vulnerability-Management-Programme priorisieren trotzdem allein nach diesem Wert. So bleiben Lücken mit mittlerem Score liegen, die längst aktiv ausgenutzt werden, während das Team Zeit in kritisch bewertete Lücken steckt, für die es keinen Exploit gibt.
EPSS zeigt, welche Lücken tatsächlich angegriffen werden
Das Exploit Prediction Scoring System (EPSS) von FIRST.org setzt genau hier an. Es berechnet für jede CVE eine Wahrscheinlichkeit zwischen 0 und 1, mit der sie in den kommenden 30 Tagen ausgenutzt wird. Das Modell wertet dazu unter anderem veröffentlichten Exploit-Code und beobachtete Angriffsaktivität aus. Laut FIRST.org werden die Werte täglich neu berechnet, die Priorisierung bewegt sich also mit der Bedrohungslage.
Kurz gesagt: CVSS beantwortet die Frage „Wie schlimm wäre es?“, EPSS die Frage „Wie wahrscheinlich ist es?“. Erst beide Werte zusammen ergeben ein realistisches Bild.
CERT-Bund und BSI ordnen Schwachstellen für Deutschland ein
Die National Vulnerability Database (NVD) des NIST ist die zentrale Referenz für CVE-Einträge, CVSS-Werte und technische Metadaten. Für Unternehmen in Deutschland kommt eine weitere Quelle hinzu: CERT-Bund, das Computer Emergency Response Team des BSI, mit seinem Warn- und Informationsdienst (WID). CERT-Bund bewertet Schwachstellen für den deutschen Kontext und veröffentlicht Warnungen mit Handlungsempfehlungen. Unternehmen können diese gezielt für ihre eingesetzte Software abonnieren.
Zusammen liefern NVD, EPSS und CERT-Bund drei Perspektiven: technische Schwere, globale Ausnutzungswahrscheinlichkeit und eine Einordnung für Deutschland.
Aktuelles Beispiel: PHP2Shell
Wie diese Quellen zusammenspielen, zeigte sich im Oktober 2026. Zwei Lücken im PHP-Kern, CVE-2026-109618 und CVE-2026-109619, erlauben Codeausführung auf Webservern ohne Anmeldung. Beide sind nach CVSS 4.0 mit 9,2 bewertet. Noch vor dem geplanten Patch-Termin waren Details geleakt, und am Tag der Updates kursierten bereits technische Analysen zur Ausnutzung, wie Huntress dokumentiert. Das BSI hielt laut ingenieur.de eine großflächige Ausnutzung innerhalb weniger Stunden für wahrscheinlich.
Der CVSS-Wert allein hätte PHP2Shell nicht von vielen anderen kritischen Lücken unterschieden. Den Unterschied machten die Signale zur Ausnutzung. In den ersten Stunden kamen sie vom BSI, kurz darauf bildete EPSS sie eindeutig ab: Am 27. Oktober lag der Wert für beide CVEs bei 0,99999 (FIRST.org EPSS-API).
Risikobasiertes Vulnerability Management beginnt beim eigenen Inventar
Die beste Bewertung nützt wenig, wenn unklar ist, wo die betroffene Software läuft. Ein risikobasierter Prozess lässt sich in vier Schritten beschreiben:
Erfassen: Neue CVEs laufen fortlaufend aus NVD und CERT-Bund ein und werden mit dem Asset-Inventar abgeglichen. Relevant ist nur, was tatsächlich im Einsatz ist.
Bewerten: CVSS, EPSS und eine etwaige CERT-Bund-Warnung fließen in eine gemeinsame Risikobewertung ein. Dazu kommt die Frage, ob das System aus dem Internet erreichbar ist.
Priorisieren: Hoher CVSS-Wert, hoher EPSS-Wert, aktive Warnung und ein exponiertes System bedeuten: sofort handeln. Ein hoher CVSS-Wert bei niedrigem EPSS-Wert auf einem internen System kann warten.
Handeln: Patches werden in dieser Reihenfolge eingespielt und dokumentiert. Für Systeme, für die es keinen Patch mehr gibt, braucht es einen Plan B: Härtung, Abschottung oder Ablösung.
Der Effekt: Das IT-Team schließt zuerst die Lücken, die real angegriffen werden.
Im Managed SOC läuft die Priorisierung weitgehend automatisiert
Bei mehreren Tausend neuen CVEs pro Jahr lässt sich dieser Prozess manuell kaum konsistent durchhalten. Im Managed SOC von suresecure übernehmen automatisierte Regeln und Use Cases einen großen Teil von Erfassung, Anreicherung und Priorisierung. Intern gehen wir von einem Automatisierungsgrad von rund 85 Prozent aus, gestützt auf rund 1.000 hinterlegte Use Cases, die CVE-, CVSS- und EPSS-Daten laufend mit den Kundenumgebungen abgleichen. Das IT-Team muss keine Daten mehr zusammentragen und kann sich auf die eigentliche Entscheidung konzentrieren: Welche Lücke wird zuerst geschlossen?
Das Vulnerability Reporting ist fester Bestandteil von Full-Managed SOCaaS und Co-Managed SOCaaS, jeweils auf Basis eines SIEM/SOAR-Setups. Die Auswertung läuft aus Deutschland, Hosting und Verarbeitung erfolgen DSGVO-konform.
Wichtig zur Abgrenzung: Ein CIRT-Einsatz nach einem erfolgreichen Angriff ist im Managed SOC nicht automatisch enthalten. Aktive Eingriffe erfolgen nur in dem Umfang, der vorab im Statement of Work autorisiert ist. Für den Ernstfall sichert ein separater IR-Retainer ab.
Eine dokumentierte Priorisierung stützt auch Compliance-Nachweise
Wer festhält, warum welche Lücke wann geschlossen wurde, hat zugleich Belege für Audits und Prüfungen. Die Anforderungen unterscheiden sich je nach Regelwerk:
IT-Grundschutz des BSI: verlangt ein strukturiertes Schwachstellenmanagement als Teil des ISMS.
NIS2: adressiert wichtige und besonders wichtige Einrichtungen und fordert ein Risikomanagement, zu dem die Behandlung von Schwachstellen gehört.
KRITIS: betrifft Betreiber Kritischer Infrastrukturen mit eigenen, teils branchenspezifischen Pflichten.
DORA: gilt für Finanzunternehmen und stellt eigene Anforderungen an das IKT-Risikomanagement.
Wer nach Risiko patcht, nutzt seine Zeit für die richtigen Lücken
Kein IT-Team kann jede kritische CVE sofort schließen. Das muss es auch nicht. Entscheidend ist, die richtigen Lücken zuerst zu schließen und diese Entscheidung auf Daten zu stützen statt auf einen einzelnen Score. CVSS, EPSS und CERT-Bund liefern diese Daten, erst der Abgleich mit dem eigenen Inventar macht sie handlungsrelevant.
Wie wenig Zeit dabei bleiben kann, hat PHP2Shell gezeigt: Zwischen dem Leak und den ersten technischen Analysen zur Ausnutzung lag kaum mehr als ein Tag. In diesem Takt funktioniert Priorisierung nur, wenn sie automatisiert läuft und klar geregelt ist, wer entscheidet und wer patcht.
FAQ
Wie oft werden EPSS-Werte aktualisiert?
Laut FIRST.org werden die EPSS-Werte täglich neu berechnet. CVSS-Werte bleiben nach der ersten Bewertung dagegen meist über die gesamte Lebensdauer einer CVE gleich.
Muss jede CVE mit hohem EPSS-Wert sofort gepatcht werden?
Ein hoher EPSS-Wert ist ein starkes Signal, aber kein Automatismus. Entscheidend ist der Abgleich mit dem eigenen Inventar: Ist die Software im Einsatz, und ist das System erreichbar? Erst dann lohnt sich die sofortige Priorisierung.
Warum reicht der CVSS-Wert für die Priorisierung nicht aus?
CVSS bewertet die technische Schwere, nicht die Angriffswahrscheinlichkeit. Viele CVEs mit hohem Wert werden nie ausgenutzt, während Lücken mit mittlerem Score aktiv angegriffen werden.
Was tun, wenn für eine kritische Schwachstelle kein Patch verfügbar ist?
Dann geht es darum, das Risiko bis zur Behebung zu senken: Workarounds des Herstellers umsetzen, betroffene Systeme härten oder vom Netz abschotten und verstärkt überwachen. Erhält eine Software dauerhaft keine Updates mehr, führt an einer Ablösung kein Weg vorbei. Jede dieser Entscheidungen sollte dokumentiert werden.
Annika Gamerad
Event & Marketing Specialist
Veröffentlicht am 28.10.2026
