Patch Management12. Januar 2026 · 6 Min. Lesezeit

Patch-Priorisierung: CVE-Scores richtig lesen und umsetzen

Einleitung

Du hast hundert offene CVEs aber nur ein Maintenance-Fenster am Wochenende. Wer nach CVSS-Score sortiert und von oben anfängt, macht erstmal nichts falsch. Aber optimal ist es nicht. Wenn du verstehst, wie der Score zu lesen ist, kannst du die Priorisierung besser an DEIN Netz anpassen. Dieser Artikel erklärt, wie CVSS funktioniert, wo es versagt, und welche Zusatzinformationen du brauchst, um wirklich zu priorisieren.

Warum das Thema wichtig ist

Der CVSS-Score ist der de-facto-Standard zur Schwachstellenbewertung, wird aber gleichzeitig massiv missverstanden. Zum Beispiel bedeutet ein CVSS 9.8 in der Theorie: “extrem gefährlich”. Es bedeutet aber nicht, dass dieser auch aktiv ausgenutzt wird. Auch sagt er nichts darüber aus, wie relevant er für deine Umgebung ist. Wer blind nach CVSS priorisiert, verschwendet mit hoher Wahrscheinlichkeit Ressourcen auf Schwachstellen, die nie ausgenutzt werden, und übersieht vielleicht DIE CVSS-6.5-Lücke, die gerade aktiv in Exploit-Kits gepackt wird und die einen Initial Access auf deinem Webserver zulässt.

CVSS verstehen: Was der Score wirklich misst

Die drei Metriken-Gruppen

Der Base Score (statisch, theoretisch):

Temporal Score (zeitabhängig):

Environmental Score (umgebungsspezifisch):

Das Problem: Die meisten Tools zeigen nur den Base Score. Temporal und Environmental werden in der Praxis ignoriert – obwohl sie die eigentlich relevante Information liefern.

Score-Tabelle

Score Kategorie
0.0 None
0.1 – 3.9 Low
4.0 – 6.9 Medium
7.0 – 8.9 High
9.0 – 10.0 Critical

Wo CVSS versagt

Base Score ≠ Ausnutzbarkeit. CVE-2021-44228 (Log4Shell, CVSS 10.0) wurde innerhalb von Stunden ausgenutzt. Natürlich war dies eine hochkritische Lücke auf Systemen, die Zugriff auf das Internet haben. CVE-2026-46333 (ptrace-Race, CVSS 7.8) klingt harmloser, war aber eine triviale Linux-Privilege-Escalation. Der Unterschied: Log4Shell war remote ohne Auth ausnutzbar, die ptrace-Race-Lücke brauchte lokalen Zugriff. Für eine Umgebung ohne extern erreichbare Linux-Systeme ist die ptrace-Race-Lücke deutlich weniger dringend, für das betroffene Gerät war es aber eine 12 von 10. CVSS betrachtet das nicht.

Ein sauberes Asset-Management hilft, kritische Systeme schneller zu identifizieren.

EPSS: Der bessere Priorisierungs-Ansatz

Der EPSS (Exploit Prediction Scoring System) beantwortet die richtige Frage: Wie hoch ist die Wahrscheinlichkeit, dass diese CVE in den nächsten 30 Tagen aktiv ausgenutzt wird?

FIRST berechnet den EPSS täglich neu auf Basis von:

Die API-Abfrage ist kostenlos und ohne Registrierung möglich:

curl "https://api.first.org/data/v1/epss?cve=CVE-2021-44228"

Antwort:

{
  "data": [{
    "cve": "CVE-2021-44228",
    "epss": "0.97564",
    "percentile": "0.99994"
  }]
}

EPSS 0.97 = Eine 97 % Wahrscheinlichkeit aktiver Ausnutzung in den nächsten 30 Tagen. Klare Ansage.

Die Zahlen, die alles ändern:

Strategie Aufwand Abdeckung der ausgenutzten CVEs
Alle CVEs patchen 100 % 100 %
CVSS ≥ 7.0 patchen ~58 % ~82 %
EPSS ≥ 0.088 patchen ~7 % ~82 %

Zahlen aus der EPSS-v3-Studie von Jacobs et al. (WEIS 2023, Cyentia/FIRST.org, Basis: reale Exploitation-Daten zu tausenden CVEs).

Betrachtet man EPSS, so erreicht man mit 7 % Aufwand dieselbe Abdeckung (82 %) wie bei reiner Betrachtung von CVSS, wo der Aufwand bei 58 % liegt. Der Effizienzgewinn: Achtmal weniger Patch-Aufwand für identische Trefferquote bei den tatsächlich ausgenutzten CVEs.

Die Priorisierungs-Matrix

Kombiniere CVSS, EPSS und CISA KEV:

Eingehende CVE
│
├── In CISA KEV?          → JA → Priorität 1 (24 h)
│
├── EPSS > 0.5?
│   ├── + CVSS ≥ 7.0      → Priorität 1 (48 h)
│   └── + CVSS < 7.0      → Priorität 2 (7 Tage)
│
├── EPSS 0.1 – 0.5?
│   ├── + CVSS ≥ 9.0      → Priorität 2 (7 Tage)
│   └── + CVSS < 9.0      → Priorität 3 (30 Tage)
│
└── EPSS < 0.1, CVSS < 7  → Priorität 4 (nächstes Fenster)

CISA KEV als Trumpfkarte

Die Known Exploited Vulnerabilities-Liste (KEV) von CISA ist ein starker Indikator dafür, dass eine Schwachstelle als kritisch einzustufen ist. Sobald eine Schwachstelle in freier Wildbahn ausgenutzt wird, ist sie Priorität Nummer 1 und sollte umgehend gepatcht werden.

# Prüfen, ob eine CVE in der KEV-Liste steht
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq '.vulnerabilities[] | select(.cveID == "CVE-2023-23397")'

Umgebungskontext

Vor der finalen Priorisierung: Kontextcheck. Hier kommt das Wissen um die eigenen Systeme zum Tragen. Du musst wissen, welche Systeme vom Internet aus erreichbar sind.

Grob kann man sagen:

Workflow in der Praxis

Vulnerability-Scan (Greenbone/OpenVas, Nessus, ...)
│
├── CVE-Liste exportieren (CSV)
│
├── EPSS-Scores in Batch abrufen
│   curl "https://api.first.org/data/v1/epss?cve=CVE-X,CVE-Y,CVE-Z"
│
├── CISA KEV abgleichen
│
├── Sortieren nach Matrix
│
└── Tickets erstellen (mit SLA aus Matrix)

Beispiel-Snippet zum Anreichern einer CVE-Liste:

#!/bin/bash
CVES=$(cat scan_cves.txt | tr '\n' ',')
curl -s "https://api.first.org/data/v1/epss?cve=${CVES}" \
  | jq -r '.data[] | [.cve, .epss, .percentile] | @tsv'

Tools, die helfen

Praxis-Checkliste

Fazit

CVSS kann nur ein Startpunkt sein. Wer Patch-Priorisierung professionell betreibt, kombiniert Base Score, EPSS, CISA KEV und Umgebungskontext. Dafür benötigt man keine teure Plattform – sondern etwas Zeit beim Aufbau des Workflows und Konsequenz bei der Ausführung.

Wenn du tiefer einsteigen willst: Im Newsletter schauen wir uns jeden Monat einen konkreten Security-Prozess an. Trag dich ein und bleib dran.

← Zurück zur Übersicht