KEV - Known Exploited Vulnerabilities

KEV vs. CVSS: Das wichtigste Verständnis

CVSS sagt: Diese Lücke HAT Schadenpotenzial (0 bis 10 Skala).

KEV sagt: Diese Lücke WIRD JETZT exploitiert.

Beispiel 1: CVE mit CVSS 6 (Medium) steht im KEV = sofort patchen.

Beispiel 2: CVE mit CVSS 9 (Critical), aber nicht im KEV = wichtig, aber nicht absolut dringend.

Die Logik: Eine Lücke, die GERADE ausgenutzt wird, ist konkrete Bedrohung. Eine theoretisch gefährliche Lücke ohne Exploit ist zukünftiges Risiko.

Im Patch-Prozess der KMU: KEV-Schwachstellen bekommen kürzeste Patch-Fenster (oft 24 bis 72 Stunden je nach BO des Bundes).

Aufnahmekriterien: Wann kommt eine Lücke ins KEV?

CISA fügt eine Lücke nur unter drei Bedingungen hinzu:

1. Es existiert bereits eine CVE-ID für die Lücke.
2. Es gibt zuverlässige, dokumentierte Nachweise, dass Angreifer die Lücke aktiv ausnutzen: nicht „könnte theoretisch”, sondern konkrete Malware-Samples, Angriffslogs, Sicherheitsbericht von Fachleuten.
3. Es existiert eine praktische Gegenmaßnahme: Patch, Workaround oder Mitigationsmöglichkeit. Wenn eine Lücke CVSS 10 hat, aber es gibt noch keinen Patch und CISA findet keine aktiven Exploits, wird sie nicht aufgenommen.

KEV-Daten: Was steht drin, wie aktuell ist es?

Jeder KEV-Eintrag enthält: CVE-ID, Produkt, betroffene Versionen, Datum der Aufnahme, Datum der ersten Ausnutzung (soweit bekannt), Link zum Patch/Advisory. CISA aktualisiert den Katalog täglich. Im Juni 2024 standen ca. 900 bis 1000 Lücken drin, die Trend steigt (mehr Angreifer, bessere Tracking). Sie können den Katalog als CSV, JSON oder Atom-Feed beziehen, für Integration in Ihr Patch-Management perfekt.

KEV in der Praxis: Binding Operational Directive 22-01

Für US-Bundesbehörden ist der KEV-Katalog durch BOD 22-01 (2022) verbindlich: Sie MÜSSEN alle KEV-Lücken patchen, in strikten Fristen je nach Kritikalität (oft 30 Tage für Level 1, 7 Tage für Level 2). Viele Europäische Organisationen nutzen KEV praktisch genauso streng, weil es bei Compliance-Audits erwartet wird („Was habt ihr gegen KEV-Lücken getan?”).

Für KMUs: Formal nicht verbindlich, aber best practice. Sie sollten KEV-Lücken mit höchster Priorität behandeln, da der Nachweis der Ausnutzung real ist.

Praktische KEV-Beispiele aus der Sicherheit

Log4Shell (CVE-2021-44228, Apache Log4j): Im KEV-Katalog seit Tagen nach Disclosure, Angreifer exploitierten es massiv, global. CVSS war 10,0, Ausnutzung real = höchste Priorität.

Folge: Microsoft forderte alle Federal Agencies auf zu patchen, viele europäische Unternehmen auch. Microsoft Exchange-Lücken (CVE-2021-26855, ProxyLogon): Im KEV seit Veröffentlichung, da Ransomware-Banden sofort zuschlugen.

Folge: Weltweit Tausende Fälle in 48h. QEMU-Lücke (CVE-2023-2861): Im KEV gelistet, aber CVSS „nur” 7,5, trotzdem höchste Priorität wegen aktiver Ausnutzung in Cloud-Umgebungen.

KEV und EPSS: Das Triple-Signal für Priorisierung

Drei Systeme geben zusammen das vollste Bild:

1. CVSS: Technische Schwere (0 bis 10).
2. EPSS: Wahrscheinlichkeit, dass Ausnutzung in 30 Tagen kommt (0 bis 100 %).
3. KEV: Wird JETZT exploitiert (Ja/Nein).

Beispiel Priorisierung: CVSS 5 + EPSS 80% + KEV=JA = sofort patchen (konkrete Bedrohung). CVSS 9 + EPSS 10% + KEV=NEIN = wichtig, aber zeitnah (theoretische, noch nicht realisierte Bedrohung). KMU-Praxis: Schauen Sie täglich auf den KEV-Katalog (unter 5 Min Aufwand), gleichen mit Ihrem Inventory ab, kennzeichnen als P1 (kritisch).

KEV nutzen: Automatisierung und Integration

Der KEV-Katalog ist maschinenlesbar. Sie können:

1. Das CSV-Export nutzen, um in Ihre Ticketing/Projekt-Tools zu importieren (z.B. JIRA, ServiceNow).
2. Den Atom-Feed abonnieren und automatisch Alerts erhalten, wenn neue Lücken hinzugefügt werden.
3. Security-Scanner (Nessus, Qualys) nutzen, die KEV-Daten integriert haben und Sie alerten, wenn Sie betroffen sind.
4. Python-Skripte schreiben, die täglich den KEV-Katalog abfragen und mit Ihrem Asset-Inventory abgleichen.

Kleine KMU: Reicht schon, den KEV-Katalog ein- bis zweimal pro Woche zu checken und CVEs gegen Ihre Systeme durchzusuchen.

Grenzen des KEV-Katalogs

KEV ist einseitig US-zentrisch und folgt CISA-Kriterien. Lücken, die hauptsächlich in Europa oder Asien aktiv ausgenutzt werden, könnten später aufgenommen werden oder gar nicht. KEV schließt Zero-Days grundsätzlich aus, eine Lücke muss öffentlich sein und mehrere Nachweise haben.

Kritik: CISA kann nicht alles sehen. Wenn Angreifer privat ausnutzen (nicht öffentlich geleakt), fehlt KEV.

Lösung: Ergänzen Sie KEV mit:

1. nationale Warnungen (BSI),
2. Threat-Intelligence-Feeds (von Security-Providern),
3. vendor-spezifische Advisories (Microsoft, Adobe, etc.). KEV ist notwendig aber nicht hinreichend für vollständige Priorisierung.

Auch bekannt als

CISA KEV · KEV-Katalog · Known Exploited Vulnerabilities Catalog

Teil des Themenbereichs: Schwachstellen bewerten

• CVSS - Common Vulnerability Scoring System

Verwandte Begriffe

• CVE - Common Vulnerabilities and Exposures
• CVSS - Common Vulnerability Scoring System
• CSAF - Common Security Advisory Framework
• TARA - Threat Analysis and Risk Assessment
• Exploit - Exploit / Exploit Code

Quellen

• CISA Known Exploited Vulnerabilities Catalog (Offiziell)
• CISA Binding Operational Directive 22-01 (BOD 22-01)
• FIRST.org - Exploit Prediction Scoring System (EPSS)
• CISA - Why KEV Matters (Threat Analysis)

Zuletzt aktualisiert: 2026-08-15

Häufige Fragen zu KEV