Schwachstellen verstehen und melden: CVE, CVSS, KEV, EPSS, security.txt

Begriffe vorab

• CVE: Eindeutige Kennung einer öffentlich bekannten Schwachstelle.
• CVSS: Common Vulnerability Scoring System: Bewertung des Schweregrads von 0 bis 10.
• KEV: Known Exploited Vulnerabilities: CISA-Katalog der nachweislich ausgenutzten Schwachstellen.
• EPSS: Exploit Prediction Scoring System: Schätzung der Wahrscheinlichkeit einer Ausnutzung.
• Coordinated Disclosure: Abgestimmte Veröffentlichung, die Herstellern Zeit zum Beheben gibt.

Vier Begriffe, vier Fragen

• CVE: Welche Schwachstelle ist gemeint? Beispiel: CVE-2021-44228 (Log4Shell).
• CVSS: Wie schlimm kann sie im schlimmsten Fall sein? Die Version 4.0 wurde am 1. November 2023 vom FIRST veröffentlicht. Sie unterscheidet Base-, Threat-, Environmental- und Supplemental-Metriken. CVSS bewertet den Schweregrad, nicht das konkrete Risiko für dich.
• KEV: Wird sie tatsächlich ausgenutzt? Der Katalog der CISA nennt Schwachstellen, für die eine Ausnutzung bekannt ist.
• EPSS: Wie wahrscheinlich ist eine Ausnutzung? Ein Modell des FIRST schätzt das.

Priorisieren

Nicht jede „kritische“ Schwachstelle trifft dich gleich. Eine Lücke mit Wert 9,8 in einem System, das nicht aus dem Internet erreichbar ist und keine wichtigen Daten hält, ist weniger dringend als eine mittlere Lücke auf dem öffentlichen Datenbankserver. Eine sinnvolle Reihenfolge: (1) steht sie im KEV-Katalog? (2) Ist das System erreichbar und wichtig? (3) Wie hoch sind CVSS und EPSS? (4) Gibt es Ausweichmaßnahmen?

Schwachstellen melden und empfangen

Wenn du eine Schwachstelle findest, melde sie dem Hersteller auf dem vorgesehenen Weg und gib ihm Zeit zur Behebung (Coordinated Disclosure). Als Betreiber erleichterst du das, indem du eine security.txt bereitstellst. Der Standard RFC 9116 beschreibt dieses maschinenlesbare Format: Es liegt unter /.well-known/security.txt, wird über HTTPS ausgeliefert und enthält Felder wie Contact: mit der Meldeadresse.

Contact: mailto:security@example.org
Expires: 2027-12-31T23:59:00.000Z
Preferred-Languages: de, en
Canonical: https://example.org/.well-known/security.txt

Beispiel

Ein Team erhält Meldungen zu 40 Schwachstellen in Abhängigkeiten. Statt nach CVSS allein zu sortieren, prüft es zuerst die KEV-Liste, danach, welche Komponenten aus dem Internet erreichbar sind, und plant die übrigen in regulären Update-Zyklen ein.

Ein Meldeweg ist Teil von Sicherheit: Wer Hinweise nicht empfangen kann, erfährt von Lücken zuletzt.

Zum Selbermachen

1. Lege eine security.txt für ein eigenes Projekt an und veröffentliche sie.
2. Sortiere eine Liste bekannter Schwachstellen nach der obigen Priorisierung.

Verwandte Themen

Open Source → „Komponenten bewerten“. Betrieb → „Incident Response“. Normen & Recht → CRA (Meldepflichten für ausgenutzte Schwachstellen).

Prüfstatus: Belegt (Stand 1. Oktober 2026): Veröffentlichung von CVSS v4.0 am 1. November 2023 und seine Metrikgruppen, die Rolle von CVE, KEV und EPSS sowie der Aufbau von security.txt nach RFC 9116 (/.well-known/security.txt, HTTPS, Contact-Feld) wurden gegen FIRST, CISA und RFC-Verzeichnisse bzw. Fachquellen geprüft. Nicht einzeln belegt: die vorgeschlagene Prioritätenreihenfolge (Einordnung in eigenen Worten) und die Beschreibungen von KEV und EPSS (aus Sekundärquellen). Das Codebeispiel ist konstruiert; die Beispieldaten sind fiktiv.

Quellen

• FIRST – „CVSS v4.0 Specification Document“ (first.org/cvss)
• CISA – „Known Exploited Vulnerabilities Catalog“
• IETF – RFC 9116 „A File Format to Aid in Security Vulnerability Disclosure“