Schwachstellen priorisieren: CVSS, EPSS, CISA KEV und Laufzeitkontext sinnvoll kombinieren statt in CVE-Listen unterzugehen
Warum Scanner endlose CVE-Listen liefern, was CVSS und EPSS wirklich messen, welche Rolle der CISA-KEV-Katalog spielt und wie Laufzeitkontext aus der Observability Tausende Findings auf eine kurze, zugeordnete Arbeitsliste reduziert.
Zusammenfassung
- CVSS beschreibt, wie schwer eine Schwachstelle grundsätzlich wiegt, EPSS schätzt die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen, und der CISA-KEV-Katalog listet Schwachstellen mit belastbaren Belegen für aktive Ausnutzung.
- Keines dieser Signale kennt Ihre Umgebung: Erst Laufzeitkontext – ist die Bibliothek geladen, erreichbar, aus dem Internet exponiert, verarbeitet sie sensible Daten – zeigt, was wirklich dringend ist.
- Ein einfaches Prioritätsmodell mit Verantwortlichen, Beispiel-SLAs und zwei Kennzahlen – mittlere Behebungszeit je Priorität und offene, aktiv ausgenutzte CVEs – macht aus der CVE-Flut einen messbaren Prozess.
Schwachstellen priorisieren heißt entscheiden, welche der vielen bekannten Schwachstellen in Ihrer Software zuerst behoben werden und welche warten können. An Findings mangelt es den wenigsten Teams: Schon ein einzelner Container-Image-Scan kann Hunderte CVEs melden, über eine ganze Service-Landschaft hinweg sind es schnell Tausende. Was fehlt, ist eine nachvollziehbare Begründung für die Aussage „diese zwanzig sind diese Woche dran“ – und ein Weg, im Nachhinein zu belegen, dass die Entscheidung richtig war.
Dieser Leitfaden erklärt, warum Scanner so lange Listen erzeugen, was CVSS und EPSS tatsächlich messen (und was nicht), wie der Known-Exploited-Vulnerabilities-Katalog der CISA hineinpasst und warum Laufzeitkontext aus der Observability die fehlende Zutat im Schwachstellenmanagement ist. Am Ende finden Sie ein anpassbares Prioritätsmodell, Beispiel-SLAs, Kennzahlen zur Fortschrittsmessung und eine Triage-Checkliste zum Kopieren.
Warum Scanner endlose CVE-Listen liefern
Software-Composition-Analysis und Container-Scanner arbeiten inventarbasiert: Sie lesen Paketmanifeste, Lock-Dateien und Image-Layer, gleichen jede Komponente samt Version mit Schwachstellendatenbanken ab und melden jeden Treffer. Das ist bewusst gründlich und erklärt die Menge:
- Transitive Abhängigkeiten: Ein Service mit einigen Dutzend direkten Abhängigkeiten zieht oft Hunderte indirekte nach sich, jede mit eigenen CVEs.
- Basis-Images: Betriebssystempakete im Basis-Image werden gemeldet, auch wenn Ihre Anwendung sie nie aufruft.
- Duplikate über Services hinweg: Dieselbe verwundbare Bibliothek in vierzig Services ergibt vierzig Findings – obwohl es eine einzige Entscheidung ist.
- Kein Laufzeitwissen: Ein Scanner sieht, was installiert ist, nicht was geladen, ausgeführt, aus dem Netz erreichbar ist oder Kundendaten verarbeitet.
Heraus kommt eine nach Schweregrad sortierte Liste, in der ein großer Teil der „kritischen“ Findings in Code steckt, der in Produktion nie läuft. Wer alles beheben will, brennt aus; wer die Liste ignoriert, übersieht die wenigen Schwachstellen, die Angreifer tatsächlich nutzen. Die Lösung: mehrere Signale kombinieren, die jeweils eine andere Frage beantworten.
CVSS: was der Base Score aussagt und was nicht
Das Common Vulnerability Scoring System (CVSS) wird von FIRST, dem Forum of Incident Response and Security Teams, gepflegt. Die aktuelle Version CVSS v4.0 wurde am 1. November 2023 veröffentlicht. Laut Spezifikation liefert CVSS numerische Werte, die den Schweregrad einer Schwachstelle im Verhältnis zu anderen Schwachstellen ausdrücken. Version 4.0 gliedert die Metriken in vier Gruppen:
- Base: inhärente Eigenschaften der Schwachstelle, die über die Zeit und über Umgebungen hinweg konstant sind, etwa Angriffsvektor, Angriffskomplexität, die neue Metrik Attack Requirements, benötigte Rechte und Auswirkungen.
- Threat: Eigenschaften, die sich mit der Zeit ändern, etwa die Reife von Exploit-Code (diese Gruppe ersetzt die früheren Temporal-Metriken).
- Environmental: Eigenschaften Ihrer konkreten Umgebung, etwa Sicherheitsanforderungen und angepasste Base-Metriken.
- Supplemental: zusätzlicher Kontext, der laut Spezifikation den Score nicht verändert.
Neu in CVSS v4.0 ist außerdem eine Nomenklatur, die erkennbar macht, welche Gruppen in einen Score eingeflossen sind: CVSS-B (nur Base), CVSS-BT (Base und Threat), CVSS-BE (Base und Environmental) und CVSS-BTE (alle drei). Die qualitative Skala ordnet Werte zu: None (0,0), Low (0,1–3,9), Medium (4,0–6,9), High (7,0–8,9) und Critical (9,0–10,0).
Wichtig: Fast jeder Scanner zeigt einen CVSS-B-Wert, also den Base Score. Er beschreibt, wie schlimm eine Schwachstelle in einer generischen Umgebung sein könnte. Er sagt nichts darüber, ob sie ausgenutzt wird, ob der verwundbare Code bei Ihnen läuft oder welcher geschäftliche Schaden entstünde. FIRST betont selbst, dass CVSS mehr ist als der Base Score.
Nutzen Sie den Base Score, um mögliche Auswirkungen einzuschätzen – nicht als Reihenfolge für die Abarbeitung. Wer Tausende Findings nur danach sortiert, setzt viele „9,8“ in ungenutztem Code vor eine „7,5“, die auf Ihrem öffentlich erreichbaren Login-Service aktiv ausgenutzt wird.
EPSS: die Wahrscheinlichkeit einer Ausnutzung
Das Exploit Prediction Scoring System (EPSS), ebenfalls von FIRST betreut, beantwortet eine andere Frage: Wie wahrscheinlich ist es, dass eine veröffentlichte CVE in den nächsten 30 Tagen in freier Wildbahn ausgenutzt wird? EPSS ist ein datengetriebenes Machine-Learning-Modell, das täglich für jede CVE eine Wahrscheinlichkeit zwischen 0 und 1 veröffentlicht, dazu ein Perzentil, das die Schwachstelle im Vergleich zu allen aktuell bewerteten einordnet. Das Modell wurde mehrfach überarbeitet: FIRST führt EPSS v4 (Modell v2025.03.14) mit Veröffentlichung ab dem 17. März 2025 und EPSS v5 (Modell v2026.06.15) mit Veröffentlichung ab dem 15. Juni 2026. Jede Version hat die Werte zum Starttermin verschoben – Zeitreihen über diese Daten hinweg spiegeln also auch Methodikwechsel wider.
Drei Punkte sind beim Einsatz von EPSS entscheidend:
- Wahrscheinlichkeit, kein Schweregrad: Ein EPSS-Wert von 0,4 bedeutet eine geschätzte Wahrscheinlichkeit von 40 %, dass innerhalb von 30 Tagen Ausnutzungsaktivität beobachtet wird. Hoher CVSS und niedriger EPSS können beide zutreffen, weil sie Unterschiedliches messen.
- CVSS nicht mit EPSS multiplizieren: Die EPSS-FAQ stellt ausdrücklich klar, dass das Produkt keine Wahrscheinlichkeit mal Schweregrad ergibt und nie eine gute Idee ist. Behandeln Sie beide als getrennte Dimensionen.
- Kein Umgebungswissen: EPSS berücksichtigt weder kompensierende Maßnahmen noch Ihre Architektur. FIRST empfiehlt, den Wert mit Vorhandensein, Erreichbarkeit und Auswirkung zu kombinieren – genau hier setzt Laufzeitkontext an.
CISA KEV: Belege für aktive Ausnutzung
Den Katalog Known Exploited Vulnerabilities (KEV) der US-Behörde Cybersecurity and Infrastructure Security Agency (CISA) bezeichnet die CISA als maßgebliche Quelle für Schwachstellen, die in freier Wildbahn ausgenutzt wurden. Aufgenommen wird eine Schwachstelle nur, wenn drei Kriterien erfüllt sind: Sie hat eine CVE-ID, es gibt belastbare Belege für aktive Ausnutzung, und es existiert eine klare Abhilfemaßnahme wie ein Hersteller-Update. Scans, Sicherheitsforschung oder Proof-of-Concept-Code allein gelten nicht als aktive Ausnutzung.
US-Bundesbehörden der zivilen Exekutive sind per verbindlicher Direktive verpflichtet, KEV-Einträge innerhalb festgelegter Fristen zu beheben (die Kriterien stammen aus BOD 22-01 und werden von BOD 26-04 fortgeführt). Für Unternehmen in Europa gilt das nicht, die CISA empfiehlt aber allen ausdrücklich, die sofortige Behandlung von KEV-Schwachstellen im eigenen Schwachstellenmanagement zu verankern. Für ein Prioritätsmodell ist KEV das stärkste einzelne Dringlichkeitssignal, weil es beobachtete Angriffe statt einer Prognose abbildet. Wer unter NIS2 fällt, kann KEV zudem als nachvollziehbares Kriterium im Risikomanagement nach NIS2 dokumentieren.
Laufzeitkontext: das Signal, das Scanner nicht sehen
CVSS, EPSS und KEV beschreiben die Schwachstelle. Laufzeitkontext beschreibt, wie stark Sie ihr tatsächlich ausgesetzt sind. Diese Information steckt bereits in Ihren Observability-Daten, denn Traces, Metriken, Logs und die Service-Topologie zeigen, was wirklich läuft und mit wem es kommuniziert:
- Ist die verwundbare Bibliothek geladen? Ein Paket im Image, das kein laufender Prozess lädt, ist deutlich weniger dringend als eines im aktiven Klassenpfad.
- Ist der verwundbare Codepfad erreichbar? Zeigen Traces, dass die betroffene Funktion oder der Endpunkt ausgeführt wird, wird eine Ausnutzung realistisch.
- Ist der Service aus dem Internet erreichbar? Topologie- und Ingress-Daten zeigen, ob ein Service externen Traffic erhält oder mehrere Hops hinter internen Diensten liegt.
- Verarbeitet er sensible Daten? Personenbezogene Daten, Zahlungsdaten oder Zugangsdaten erhöhen den Schaden einer Kompromittierung.
- Wem gehört er? Ein Finding ohne Verantwortlichen wird nie behoben. Ein Service-Katalog mit zuständigen Teams und Rufbereitschaft macht aus Findings zugewiesene Arbeit.
Die Signale im Überblick
| Signal | Was es Ihnen sagt | Quelle |
|---|---|---|
| CVSS Base Score (CVSS-B) | Generischer technischer Schweregrad bei Ausnutzung | FIRST-Spezifikation; Werte aus NVD, von Herstellern oder Scannern |
| CVSS Threat/Environmental (CVSS-BT, -BE, -BTE) | Schweregrad angepasst an Exploit-Reife und Ihre Umgebung | Eigene Bewertung mit dem FIRST-Rechner |
| EPSS-Wahrscheinlichkeit und Perzentil | Wahrscheinlichkeit von Ausnutzungsaktivität in den nächsten 30 Tagen | FIRST-EPSS-Datenfeed und API, täglich aktualisiert |
| Eintrag im CISA KEV | Belastbare Belege für aktive Ausnutzung | CISA-KEV-Katalog (CSV/JSON) |
| Bibliothek zur Laufzeit geladen | Ob die verwundbare Komponente tatsächlich läuft | Laufzeit-Agent, Prozess- und Class-Loading-Daten |
| Codepfad erreichbar | Ob die betroffene Funktion oder der Endpunkt ausgeführt wird | Distributed Traces, Profiling-Daten |
| Internet-Exposition | Ob Angreifer den Service direkt erreichen | Service-Topologie, Ingress- und Load-Balancer-Daten |
| Sensible Daten | Geschäftliche und regulatorische Auswirkung | Datenklassifizierung, Metadaten im Service-Katalog |
| Verantwortliche | Wer behebt, wer verantwortet | Service-Katalog, Code-Ownership |
Ein Prioritätsmodell, das die Signale kombiniert
Verzichten Sie auf eine einzige Zauberformel. Eine kleine Entscheidungstabelle lässt sich Auditoren und Entwicklern leichter erklären und besser nachjustieren. Das folgende Modell ist ein Beispiel zum Anpassen; Schwellen wie der EPSS-Grenzwert hängen von Ihrer Kapazität und Risikobereitschaft ab.
| Priorität | Beispielregel |
|---|---|
| P1 – sofort beheben | Im CISA KEV gelistet und zur Laufzeit geladen und aus dem Internet erreichbar oder mit sensiblen Daten |
| P2 – im aktuellen Sprint | KEV-gelistet, aber nur intern, oder hoher EPSS (Beispiel: von Ihnen festgelegte obere Perzentile) und erreichbar, oder CVSS Critical, erreichbar und exponiert |
| P3 – eingeplant | Zur Laufzeit geladen, aber nicht erreichbar oder nicht exponiert, kein KEV-Eintrag, niedriger EPSS |
| P4 – Backlog / Hygiene | Zur Laufzeit nicht geladen; Behebung über reguläre Abhängigkeits- und Image-Updates |
Zwei Regeln machen das Modell belastbar. Erstens: laufend neu bewerten. EPSS ändert sich täglich, der KEV-Katalog wächst, und ein Deployment kann einen bisher unerreichbaren Pfad erreichbar machen. Verknüpfen Sie Findings mit Deployment-Tracking, sehen Sie, welches Release eine verwundbare Version eingeführt oder entfernt hat. Zweitens: Ausnahmen dokumentieren. Lässt sich ein P1 nicht patchen, halten Sie die kompensierende Maßnahme (etwa eine WAF-Regel oder ein Feature-Flag) und ein Ablaufdatum fest.
SLAs je Priorität (Beispiel)
Behebungsfristen machen Prioritäten verbindlich. Die folgenden Werte sind reine Beispiele – weder Empfehlung noch regulatorische Vorgabe. Stimmen Sie sie auf Ihre Risikobereitschaft, Verträge und geltende Pflichten ab. Behandeln Sie sie wie ein internes SLA und ordnen Sie P1 Ihren Incident-Schweregraden zu, falls eine Schwachstelle aktiv gegen Sie ausgenutzt wird.
| Priorität | Beispiel-Behebungsfrist | Beispiel-Eskalation |
|---|---|---|
| P1 | Mitigation innerhalb von 48 Stunden, Behebung innerhalb von 7 Tagen | Sofort an Security-Lead und Service-Verantwortliche; Incident bei beobachteter Ausnutzung |
| P2 | 30 Tage | Teamleitung nach 50 % der Frist |
| P3 | 90 Tage | Monatliches Review |
| P4 | Nächstes geplantes Abhängigkeits- oder Image-Update | Quartalsweiser Hygiene-Report |
Ein Runbook je Priorität – wer benachrichtigt wird, wie temporär mitigiert wird, wie die Behebung verifiziert wird – sorgt für einen einheitlichen Ablauf über alle Teams.
Fortschritt messen
Die Gesamtzahl offener CVEs ist eine schlechte Kennzahl: Sie steigt, sobald Scanner mehr abdecken, und sagt nichts über das Risiko. Messen Sie stattdessen wenige Werte, die die tatsächliche Exposition abbilden:
- Mittlere Behebungszeit (MTTR) je Priorität: von der Erkennung bis zur verifizierten Behebung, getrennt für P1 bis P4. Eine sinkende P1-MTTR ist das klarste Zeichen für Fortschritt.
- SLA-Einhaltung je Priorität: Anteil der fristgerecht behobenen Findings.
- Offene KEV-gelistete CVEs: Anzahl und Anteil offener Findings im CISA-KEV-Katalog, idealerweise getrennt nach geladen und nicht geladen. Das Ziel für geladene, exponierte KEV-Findings ist null.
- Expositionstrend: Anzahl der Findings, die geladen und zugleich aus dem Internet erreichbar sind, je Team.
- Findings ohne Verantwortliche: Findings auf Services ohne Eintrag im Service-Katalog. Diese Zahl sollte als Erstes auf null.
- Ausnahmen: offene Risikoakzeptanzen und wie viele davon abgelaufen sind.
Berichten Sie diese Kennzahlen je Team, nicht nur gesamt – Verantwortung bewegt die Zahlen. Zu viele wertlose Tickets erzeugen dieselbe Ermüdung wie laute Alarme; die Prinzipien aus unserem Beitrag zu Alert Fatigue gelten für Security-Findings genauso.
Triage-Checkliste für Schwachstellen zum Kopieren
Nutzen Sie diese Checkliste für jedes neue Finding oder jeden Stapel von Findings, etwa im wöchentlichen Triage-Termin oder als Ticket-Vorlage:
TRIAGE-CHECKLISTE SCHWACHSTELLEN
CVE / Finding-ID: ______________ Komponente + Version: ______________
Betroffene Services: ______________ Verantwortlich (Team / Rufbereitschaft): ______________
[ ] 1. Deduplizieren: gleiche Komponente in mehreren Services = eine Entscheidung
[ ] 2. CVSS: Base Score + Vektor notiert (CVSS-B); Umgebungsanpassung nötig?
[ ] 3. EPSS: Wahrscheinlichkeit ____ und Perzentil ____ (Stand: ____)
[ ] 4. CISA KEV: gelistet? ja / nein (aufgenommen am: ____)
[ ] 5. Laufzeit: Bibliothek in Produktion geladen? ja / nein / unbekannt
[ ] 6. Erreichbarkeit: verwundbarer Codepfad ausgeführt (Traces/Profile)? ja / nein / unbekannt
[ ] 7. Exposition: aus dem Internet erreichbar? direkt / indirekt / nur intern
[ ] 8. Daten: personenbezogene, Zahlungs- oder Zugangsdaten? ja / nein
[ ] 9. Priorität (P1-P4) und angewandte Regel: ______________
[ ] 10. Behebungsweg: Upgrade / Patch / Konfiguration / Abhängigkeit entfernen
[ ] 11. Zwischenlösung bei Verzögerung: ______________ (gültig bis: ____)
[ ] 12. Fälligkeit laut SLA: ______________
[ ] 13. Behebung in Produktion verifiziert (Version nicht mehr geladen): ______________
[ ] 14. "Unbekannt"-Antworten eskaliert, um Telemetrie-Abdeckung zu verbessern„Unbekannt“ ist eine zulässige Antwort. Behandeln Sie sie aber als den ungünstigeren Fall, bis Laufzeitdaten vorliegen, und zählen Sie, wie oft sie vorkommt – das ist ein direktes Maß für fehlende Sichtbarkeit.
Wie Obseria unterstützt
Obseria verbindet Schwachstellen-Findings mit den Laufzeitdaten, die Ihre Observability ohnehin erfasst. Obseria Application Security läuft im vorhandenen Obseria Agent, bewertet Schwachstellen danach, ob der Code geladen, aus dem Internet erreichbar und mit sensiblen Daten befasst ist, und leitet Findings an die Teams weiter, denen die Services gehören. Der Use Case Sicherheit und Zuverlässigkeit zeigt, wie sich das in Incident- und Release-Prozesse einfügt.
- Runtime Vulnerability Analytics mit Bewertung von Exposition und Erreichbarkeit sowie SBOM-Sicht auf Container und Bibliotheken.
- Zuständigkeiten aus dem Service-Katalog und Release-Kontext aus dem Deployment-Tracking.
- Release Gates für kritische Findings und automatische Weiterleitung an Ticket- und Chat-Systeme.
- Für Teams ohne eigene Kapazität: Managed Observability & Security mit unserem Implementierungspartner.
Sie möchten sehen, welche Ihrer CVEs wirklich zählen? Testen Sie Obseria kostenlos und binden Sie Ihre ersten Services an.