Ein Scanner wie Trivy oder Grype spuckt schnell ein paar hundert CVEs aus. Der Report ist erstellt, aber danach kommt der schwierige Teil: Welche dieser Findings sind wirklich relevant, und welche kannst du erstmal liegen lassen? Wer jede kritische CVE sofort abarbeiten will, verbrennt Zeit an Dingen, die im eigenen Kontext gar nicht ausnutzbar sind. Dieser Beitrag zeigt, wie ich vom rohen Report zu einer belastbaren Priorisierung komme.

Der CVSS-Score allein reicht nicht

Fast jeder Scanner sortiert nach CVSS. Das ist ein Anfang, aber der Base Score sagt nur, wie schlimm eine Lücke theoretisch ist, nicht wie relevant sie fuer dein System ist. Eine CVE mit Score 9.8 in einer Library, die du zwar installiert hast aber nie aufrufst, ist praktisch harmlos. Eine 6.5 in einem Parser, der ungefilterten Input aus dem Internet verarbeitet, ist dein echtes Problem. Der Base Score kennt deinen Kontext nicht.

Deshalb ergaenzt CVSS die Temporal- und Environmental-Metriken. In der Praxis nutzt sie kaum jemand, weil das manuelle Pflege bedeutet. Stattdessen lohnt sich ein Blick auf zwei Datenquellen, die deutlich mehr aussagen als der Score.

EPSS und KEV: Ausnutzbarkeit statt Theorie

Der EPSS (Exploit Prediction Scoring System) schaetzt die Wahrscheinlichkeit, dass eine CVE in den naechsten 30 Tagen tatsaechlich ausgenutzt wird. Ein Wert zwischen 0 und 1. Eine CVE mit CVSS 9.8 aber EPSS 0.02 wird mit hoher Wahrscheinlichkeit nicht angegriffen. Eine mit CVSS 7.5 und EPSS 0.7 solltest du ernst nehmen.

Die zweite Quelle ist der KEV-Katalog (Known Exploited Vulnerabilities) der CISA. Alles was dort steht, wird nachweislich aktiv ausgenutzt. Das ist keine Prognose mehr, sondern Realitaet. Jede CVE aus deinem Report, die im KEV-Katalog auftaucht, gehoert nach ganz oben, unabhaengig vom CVSS-Score.

Beide Quellen lassen sich frei abfragen. So holst du dir den EPSS-Wert fuer eine CVE:

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-44228" \
  | jq '.data[] | {cve, epss, percentile}'
# Ausgabe:
# {
#   "cve": "CVE-2021-44228",
#   "epss": "0.943680000",
#   "percentile": "0.999750000"
# }

Eine einfache Priorisierungsmatrix

Statt stur nach Severity zu sortieren, kombiniere ich drei Fragen: Ist die CVE im KEV-Katalog? Wie hoch ist der EPSS? Ist die betroffene Komponente in meinem System ueberhaupt erreichbar? Daraus ergibt sich eine grobe Reihenfolge.

• Sofort: CVE im KEV-Katalog und Komponente erreichbar. Kein Warten auf das naechste Wartungsfenster.
• Diese Woche: EPSS ueber 0.5 oder hoher CVSS bei erreichbarer Komponente.
• Geplant: Hoher CVSS, aber niedriger EPSS und keine direkte Erreichbarkeit. Beim naechsten regulaeren Update mitnehmen.
• Beobachten: Alles andere. Dokumentieren, aber nicht hetzen.

Der Punkt Erreichbarkeit ist der, den Scanner nicht kennen. Eine verwundbare Funktion, die in deinem Code nie aufgerufen wird, ist ein anderes Risiko als eine im direkten Request-Pfad. Reachability-Analyse ist noch jung, aber selbst eine grobe manuelle Einschaetzung schlaegt den blinden CVSS-Blick.

Das Ganze in die Pipeline holen

Trivy kann seit einer Weile direkt gegen den KEV- und EPSS-Kontext filtern, aber auch ohne das laesst sich der Report nachbearbeiten. Ein kurzes Skript, das die CVE-Liste aus dem Scanner-JSON gegen die EPSS-API haelt und alles ueber einem Schwellwert markiert, reicht fuer den Anfang:

trivy image --format json myapp:latest \
  | jq -r '.Results[].Vulnerabilities[]?.VulnerabilityID' \
  | sort -u > cves.txt
while read cve; do
  epss=$(curl -s "https://api.first.org/data/v1/epss?cve=$cve" \
    | jq -r '.data[0].epss // "0"')
  awk -v c="$cve" -v e="$epss" 'BEGIN{ if(e+0 > 0.5) print c" EPSS="e" -> pruefen" }'
done < cves.txt

Das ersetzt kein ausgewachsenes Vulnerability-Management-Tool, macht aber den entscheidenden Unterschied: Aus einer Liste von 300 CVEs werden vielleicht 12, die wirklich Aufmerksamkeit brauchen. Der Rest wandert in die geplante Kategorie.

Fazit

Priorisierung heisst nicht, alles zu fixen, sondern das Richtige zuerst. CVSS zeigt den theoretischen Schweregrad, EPSS die Ausnutzungswahrscheinlichkeit, KEV die belegte Realitaet, und Erreichbarkeit den eigenen Kontext. Zusammen ergeben sie eine Reihenfolge, die dein Team nicht in Panik versetzt, sondern arbeitsfaehig haelt. Wer den Prozess ganzheitlich in die Delivery-Kette einbauen will, findet auf digital-business.blog weitere Beitraege dazu.