Der EU Cyber Resilience Act (Verordnung (EU) 2024/2847) verpflichtet Hersteller, Schwachstellen zu triagieren, rechtzeitig zu beheben und aktive Ausnutzung zu melden, sobald sie davon Kenntnis erlangen. Die Meldepflicht nach Artikel 14 gilt ab dem 11. September 2026; die Pflichten zur Schwachstellenbehandlung, Behebung und Offenlegung nach Artikel 13 und Anhang I gelten ab dem 11. Dezember 2027. Er benennt kein CVSS, EPSS, KEV oder anderes Bewertungssystem. Diese Seite behandelt, was jedes Signal misst, wie sie zu einer vertretbaren Priorisierung kombiniert werden und wie Bewertung Schwachstellenmeldungen und koordinierte Offenlegung von Schwachstellen unterstützt.
Zusammenfassung
- Der CRA schreibt kein Bewertungssystem vor. Er verlangt rechtzeitige Behebung, überlässt die operative Messung aber den Herstellern.
- CVSS misst die inhärente Schwere auf einer Skala von 0 bis 10: Schwachstelleneigenschaften unabhängig davon, ob eine Ausnutzung in der Praxis beobachtet wird.
- EPSS misst die Ausnutzungswahrscheinlichkeit auf einer Skala von 0 bis 1: Wahrscheinlichkeit einer beobachteten Ausnutzungsaktivität gegen einen CVE innerhalb der nächsten 30 Tage, berechnet durch die FIRST EPSS Special Interest Group.
- CISA KEV ist ein binäres Signal für aktive Ausnutzung, das Meldeentscheidungen unterstützen kann, obwohl der CRA-Auslöser über eine KEV-Aufnahme hinausgeht.
- CVSS, EPSS und KEV kombiniert ergeben eine vertretbare Priorisierungsmatrix; kein einzelnes Signal ist für sich allein ausreichend.
- Meldeauslöser sind sachverhaltsbezogen, nicht score-gesteuert. Aktive Ausnutzung und schwerwiegende Vorfälle werden nach den gesetzlichen Definitionen bestimmt, wobei die Bewertung als Beleg dient.
Die vier Signale, die CRA-Schweregradentscheidungen einordnen: inhärente Schwere, Ausnutzungswahrscheinlichkeit, Meldefrist und das Datum, ab dem die Meldepflicht gilt.
Was der CRA zur Bewertung sagt
Liest man die Verordnung unmittelbar, findet sich kein Hinweis auf CVSS, EPSS oder ein anderes benanntes Bewertungssystem. Die operativen Pflichten sind einfacher: Hersteller brauchen einen Schwachstellenprozess, der über den gesamten Supportzeitraum funktioniert, Schwachstellen unverzüglich behebt und bei verfügbaren Sicherheitsupdates klare Angaben zur Schwere veröffentlicht.
- Behebung. Schwachstellen unverzüglich behandeln und beheben, auch durch Sicherheitsupdates.
- Öffentliche Information. Sobald ein Sicherheitsupdate verfügbar ist, eine Beschreibung der behobenen Schwachstelle, die betroffenen Produkte, die wahrscheinlichen Auswirkungen, die Schwere und klare Hinweise zur Behebung bereitstellen.
Diese Formulierungen setzen einen Maßstab, keine feste Anzahl von Tagen. Sie werden von Marktüberwachungsbehörden und letztlich von nationalen Gerichten ausgelegt.
Scoring ist die Art, wie Hersteller diese Auslegung in Audits und Untersuchungen nachweisen. Ein Hersteller, der eine dokumentierte Schweregrad-Richtlinie, ein Tracking-System mit CVSS und EPSS bei Eingang, SLAs je Schwereband und Zeitstempel zur fristgerechten Behebung zeigen kann, hat eine vertretbare "unverzüglich"-Position. Wer das nicht kann, hat sie nicht.
Zum umfassenderen Schwachstellenbehandlungsregime siehe Schwachstellenbehandlung. Zu den Meldetakten unter dem Vorfall-Meldungsregime siehe Schwachstellenmeldung.
CVSS: inhärente Schwere
Das Common Vulnerability Scoring System, das von der FIRST CVSS Special Interest Group gepflegt wird, bewertet eine Schwachstelle auf einer Skala von 0,0 bis 10,0. Es ist der dominierende Score für inhärente Schwere in der Branche und der Score, den die meisten CVE-Einträge veröffentlichen.
CVSS v3.1 hat drei Score-Typen:
| Score-Typ | Was er misst | CRA-Nutzung |
|---|---|---|
| Basis-Score | Inhärente Schwachstelleneigenschaften: Angriffsvektor, Komplexität, erforderliche Rechte, Nutzerinteraktion, Umfang und Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit. | Als Erfassungsbasis nutzen, weil dies der Score ist, den die meisten CVE-Einträge veröffentlichen. |
| Temporal-Score | Zeitvariable öffentliche Faktoren: Reife des Exploit-Codes, Behebungsstand und Berichtsvertrauen. | Nutzen, wenn verfügbar, aber nicht davon abhängig machen, weil öffentliche CVE-Einträge ihn selten ausfüllen. |
| Umgebungs-Score | Eigener Produktkontext: Asset-Kritikalität, kompensierende Kontrollen, erreichbare Codepfade und reale Auswirkung im Einsatz. | Nutzen, um zu dokumentieren, warum der Hersteller eine Behebungspriorität erhöht, gesenkt oder zurückgestellt hat. |
CVSS v4.0 wurde von FIRST am 1. November 2023 veröffentlicht. Es behält die Gruppen Basis und Umgebung bei, ersetzt die v3.1-Gruppe Temporal durch eine engere Threat-Gruppe, die sich auf die Reife von Exploits konzentriert, und ergänzt eine Supplemental-Gruppe (einschließlich Sicherheit, Automatisierbarkeit, Wiederherstellung und Wertdichte), die Kontext erfasst, ohne den Gesamtscore zu verändern. Die Übernahme verläuft schrittweise: Viele CVE-Feeds veröffentlichen weiterhin v3.1, und die Werkzeugunterstützung für v4.0 ist uneinheitlich. Beide sollten eingelesen werden, wo verfügbar, und der Übergang sollte nicht als Anlass für eine Neubasierung des Backlogs genutzt werden.
CVSS allein ist unzureichend. Empirische Forschung zeigt konsistent, dass die meisten von CVSS als "hoch" oder "kritisch" eingestuften Schwachstellen in der Praxis nie ausgenutzt werden. Eine rein CVSS-gesteuerte Warteschlange verbraucht Engineering-Kapazität für theoretische Risiken, während reale Ausnutzung unbehandelt bleibt.
EPSS: Ausnutzungswahrscheinlichkeit
Das Exploit Prediction Scoring System, das ebenfalls von FIRST über seine EPSS SIG gepflegt wird, sagt die Wahrscheinlichkeit voraus, dass Ausnutzungsaktivität gegen einen CVE innerhalb der nächsten 30 Tage beobachtet wird. EPSS veröffentlicht eine Wahrscheinlichkeit zwischen 0 und 1 sowie einen Perzentilrang gegenüber allen CVEs.
EPSS wird von einem Machine-Learning-Modell berechnet, das CVE-Attribute (CVSS-Metriken, CWE, betroffener Anbieter und Produkt, Alter) und öffentliche Signale (PoC-Verfügbarkeit, beobachtete Ausnutzungsaktivität von beitragenden Partnern, Bedrohungshinweise) verarbeitet. Scores werden täglich aktualisiert. Ein neuer CVE ohne öffentlichen PoC erzielt typischerweise unter 0,05; einer mit einem funktionsfähigen PoC kann je nach anderen Eingaben des Modells deutlich ansteigen.
EPSS allein ist ebenfalls unzureichend. Ein niedriger EPSS heute ist keine Garantie für morgen: Wenn ein Forscher einen funktionierenden Exploit veröffentlicht, bewegt sich der Score. EPSS muss kontinuierlich neu bewertet werden, nicht nur bei der Ersterfassung.
CISA KEV: bestätigte Ausnutzung
Der Known Exploited Vulnerabilities-Katalog, der von der US Cybersecurity and Infrastructure Security Agency gepflegt wird, ist eine Liste von Schwachstellen mit verlässlichen Belegen für aktive Ausnutzung. Ein CVE ist entweder im Katalog oder nicht. CISA nimmt einen CVE auf, wenn verlässliche Belege vorliegen, dass die Schwachstelle gegen ein reales Ziel ausgenutzt wurde.
KEV ist eine US-Regierungsquelle. EU-Hersteller nutzen ihn weit verbreitet aufgrund der breiten Werkzeugunterstützung. Seit dem 13. Mai 2025 betreibt ENISA auch die European Vulnerability Database (EUVD), die den Ausnutzungsstatus und eine gesonderte Ansicht aktiv ausgenutzter Schwachstellen veröffentlicht; sie sollte als zusätzliches EU-Priorisierungssignal neben KEV verwendet werden. Beide sind von der einheitlichen CRA-Meldeplattform (Artikel 16) getrennt, und keiner ist selbst der Auslöser der Meldepflicht nach Artikel 14.
Für den Frühwarn-Auslöser ist eine KEV-Aufnahme ein starkes Signal, dass eine Schwachstelle im Sinne der Verordnung "aktiv ausgenutzt" sein kann. Sie ist nicht das einzige Signal: Der Auslöser ist breiter und erfasst jede aktiv ausgenutzte Schwachstelle, auch solche aus Kundenmeldungen, interner Telemetrie oder Bedrohungsdaten, die CISA noch nicht erreicht haben. Eine Schwachstelle, die gegen Ihre Kunden ausgenutzt wird, aber noch nicht in KEV steht, kann die Pflicht trotzdem auslösen. Die Feststellung ist sachverhaltsbezogen, nicht listenbasiert, und verlangt verlässliche Belege dafür, dass ein böswilliger Akteur die Schwachstelle ohne Erlaubnis ausgenutzt hat.
CVSS, EPSS und KEV zu einer CRA-Priorisierungsmatrix kombinieren
Kein einzelnes Signal ist ausreichend. Der vertretbare Ansatz besteht darin, alle drei zu kombinieren und Behebungs-SLAs an das kombinierte Band zu knüpfen. Das folgende Diagramm zeigt warum: Ein CVSS-9,8 ohne beobachtete Ausnutzung ist ein geringeres reales Risiko als ein CVSS-7 mit EPSS 0,95 und KEV-Eintrag, auch wenn der erste in einer reinen CVSS-Warteschlange schlechter aussieht.
| Band | Signalkombination | Behebungs-SLA | CRA-Implikation |
|---|---|---|---|
| Notfall | KEV-gelistet ODER bestätigte aktive Ausnutzung ODER (CVSS Kritisch 9,0+ UND EPSS > 0,5) | Tage, nicht Wochen | Dringende Meldeprüfung, wenn die Ausnutzung das eigene Produkt betreffen kann |
| Hoch | CVSS Hoch (7,0-8,9) ODER EPSS > 0,5 | 30 Tage | "Ohne Verzögerung"-Position ist oberhalb von 30 Tagen gefährdet |
| Mittel | CVSS Mittel (4,0-6,9), EPSS < 0,5, nicht KEV-gelistet | 90 Tage | Vertretbar mit Dokumentation und Zeitstempeln |
| Niedrig | CVSS Niedrig (< 4,0) | Nächster regulärer Release-Zyklus | Aufschub im Schwachstellenmanagement-Protokoll dokumentieren |
Die Matrix ist die Richtlinie des Herstellers, keine CRA-Anforderung. Sie schriftlich festzuhalten gibt einer Marktüberwachungsbehörde eine dokumentierte, wiederholbare Grundlage für die Behebungsentscheidungen, die sie nach Bekanntwerden einer schwerwiegenden Schwachstelle prüfen kann. Eine dokumentierte Richtlinie, die jeden CVE bei der Erfassung einem Band zuordnet, festhält, in welches Band dieser CVE eingestuft wurde, und zeigt, dass die Behebung innerhalb des passenden SLA mit Zeitstempeln erfolgte, lässt sich weit leichter verteidigen als "wir haben gepatcht, sobald wir dazu gekommen sind".
Unsere Einschätzung: eine reine CVSS-Warteschlange wird zum Audit-Warnsignal
Die obigen Abschnitte beschreiben operative Mechanismen. Der folgende Kasten gibt unsere Einschätzung als Praktiker wieder, keine Rechtsberatung.
Die aktuelle Verordnung benennt kein Bewertungssystem, und wir erwarten nicht, dass sich das ändert. Die Richtung ist dennoch klar. Seit die EUVD von ENISA eine Ansicht aktiv ausgenutzter Schwachstellen neben CISA KEV veröffentlicht, werden ausnutzungsbezogene Nachweise für Behörden schwerer zu ignorieren: "Wir haben nach CVSS priorisiert und die Schwachstelle übersehen, die gerade ausgenutzt wurde" ist von Quartal zu Quartal eine schwächere Antwort. Wir erwarten, dass Marktüberwachungsbehörden und CSIRTs einen EPSS-und-KEV-bewussten Prozess als Untergrenze eines kompetenten Schwachstellenbehandlungsregimes lesen, nicht als fortgeschrittene Option. Wer für das aufbaut, worauf die Durchsetzung zusteuert, bewertet bereits nach Ausnutzungswahrscheinlichkeit, nicht nur nach Schwere.
Schweregrad auf Meldeauslöser abbilden
Meldungen sind nicht score-gesteuert. Das Vorfall-Meldungsregime teilt sich in zwei Stränge mit denselben 24-Stunden- und 72-Stunden-Fristen, aber unterschiedlichen Abschlussberichtsfristen:
- Aktiv ausgenutzte Schwachstelle. 24-Stunden-Frühwarnung, 72-Stunden-Schwachstellenmeldung, 14-Tage-Abschlussbericht ab Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme.
- Schwerwiegender Sicherheitsvorfall. 24-Stunden-Frühwarnung, 72-Stunden-Vorfallmeldung, 1-Monats-Abschlussbericht ab der 72-Stunden-Meldung.
Keiner der Auslöser ist ein CVSS-Schwellenwert. "Aktiv ausgenutzt" ist eine sachverhaltsbezogene Feststellung: Es liegen verlässliche Belege dafür vor, dass ein böswilliger Akteur die Schwachstelle ohne Erlaubnis ausgenutzt hat. Ein schwerwiegender Sicherheitsvorfall ist ein Vorfall, der sich negativ auf die Fähigkeit des Produkts auswirkt oder auswirken kann, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von sensiblen oder wichtigen Daten oder Funktionen zu schützen, oder der dazu geführt hat oder dazu führen kann, dass böswilliger Code in das Produkt oder in die Netz- und Informationssysteme eines Nutzers eingeschleust oder darin ausgeführt wird.
CVSS und EPSS stützen die Feststellung. Eine CVSS-kritische Schwachstelle mit EPSS > 0,9 und einem KEV-Eintrag sollte eine dringende Meldeprüfung auslösen, sobald Belege vorliegen, dass die Ausnutzung das eigene Produkt betreffen kann. Sie ersetzen die Feststellung nicht. Die 24-Stunden-Frist beginnt in dem Moment, in dem der Hersteller von der aktiven Ausnutzung Kenntnis erlangt, nicht in dem Moment, in dem der CVSS-Score eine bestimmte Zahl überschreitet.
Für die vollständige Meldekadenz siehe Schwachstellenmeldung. Für den vorgelagerten Eingangskanal, der oft das erste Ausnutzungssignal liefert, siehe koordinierte Offenlegung von Schwachstellen.
Bewertung im Schwachstellenprozess operationalisieren
Ein funktionierender, CRA-konformer Bewertungsprozess hat sechs konkrete Bestandteile:
- CVSS bei der Überprüfung einlesen. Die SBOM-zu-CVE-Pipeline sollte bei jeder ersten Erkennung CVSS-Basis-Scores an jeden Befund anhängen. Zur zugrundeliegenden Zuordnungsmechanik siehe SBOM.
- EPSS täglich aktualisieren. Ein nächtlicher Job, der offene Schwachstellen neu bewertet, ist das Minimum.
- CISA KEV beobachten. Den KEV-Feed abonnieren und jede offene Schwachstelle, die in den Katalog aufgenommen wird, automatisch hochstufen.
- Bandgebundene SLAs im Tracking-System festlegen. Bänder und Fristen müssen maschinenlesbar sein, damit überfällige Einträge ohne manuelles Triage sichtbar werden.
- Bei Schwellenwertüberschreitungen hochstufen. Wenn EPSS für einen offenen Befund 0,5 überschreitet, das Band neu einordnen (Hoch, oder Notfall wenn CVSS ebenfalls 9,0+ ist). Wenn KEV einen der eigenen CVEs aufnimmt oder ein Kunde aktive Ausnutzung meldet, wechselt der Eintrag automatisch in das Notfall-Band.
- Die SBOM-Komponenten-zu-CVE-Zuordnung automatisieren. Manuelle Zuordnung bricht bei Skalierung und ist die häufigste Quelle übersehener Schwachstellen in Prüfungsbefunden.
Das Onboarding auf die ENISA Single Reporting Platform ist ein separater, aber verwandter Workstream. Siehe ENISA-SRP-Onboarding.
Häufige Fehler
- CVSS-9 verfolgen und EPSS-0,95 ignorieren. Eine CVSS-7-Schwachstelle mit EPSS 0,95 und einem öffentlichen PoC ist ein höheres reales Risiko als ein CVSS-9,8 mit EPSS 0,01.
- KEV als vollständig betrachten. KEV ist der beste öffentliche Katalog, hinkt aber hinterher. Aktive Ausnutzung gegen die eigenen Kunden kann der KEV-Aufnahme um Tage oder Wochen vorausgehen.
- CVSS als Frist behandeln. Ein CVSS-Kritisch bedeutet nicht "in 24 Stunden patchen". Es bedeutet "das zuerst ansehen". Die Frist ergibt sich aus dem eigenen Richtlinien-SLA, dem EPSS, dem KEV-Status und letztlich aus dem erwarteten unverzüglichen Behebungsmaßstab.
- EPSS-Scores nicht aktualisieren. Eine Schwachstelle, die bei der Erfassung mit EPSS 0,02 bewertet und nie neu bewertet wurde, verbleibt im Niedrig-Prioritäts-Backlog, während sich die reale Ausnutzung außerhalb der eigenen Sicht aufbaut.
- CVSS-Umgebungsanpassungen ignorieren. Ein CVSS-Basis-Score von 9,8 gegen eine Komponente, die das eigene Produkt nie instanziiert, ist in der eigenen Umgebung kein 9,8. Den Umgebungs-Score und die Begründung dokumentieren.
- CVSS oder EPSS als Meldeauslöser verwenden. Die Meldepflicht hängt von sachverhaltsbezogener aktiver Ausnutzung ab. Ein Score ist ein Beleg, nicht die Feststellung.
Häufig gestellte Fragen
Schreibt der CRA die Verwendung von CVSS vor?
Nein. Der CRA benennt CVSS oder ein anderes Bewertungssystem nicht. Die Offenlegungspflicht verlangt, den "Schweregrad" bei der Veröffentlichung einer behobenen Schwachstelle zu kommunizieren, legt die Skala aber nicht fest. CVSS ist der Branchenstandard und die am einfachsten zu verteidigende Skala in einer Prüfung. Eine eigene oder alternative Skala kann funktionieren, wenn sie dokumentiert und konsistent angewendet wird.
Ist EPSS nach dem CRA verpflichtend?
Nein. EPSS wird in der Verordnung nicht erwähnt. Es hilft, den "ohne Verzögerung"-Maßstab nachzuweisen, weil es zeigt, dass die Priorisierung die reale Ausnutzungswahrscheinlichkeit berücksichtigt hat und nicht nur die inhärente Schwere. Ein Hersteller, der die Ausnutzungswahrscheinlichkeit ignoriert und ausschließlich nach CVSS-Rang patcht, wird Schwierigkeiten haben, eine langsame Behebung eines hochgradig-EPSS-Befunds im Nachhinein zu rechtfertigen.
Wie beeinflusst die Bewertung die 24-Stunden-Frist?
Sie ändert nicht, wann die Frist beginnt. Die Frist beginnt, wenn der Hersteller von einer aktiv ausgenutzten Schwachstelle erfährt, unabhängig vom CVSS. Die Bewertung hilft, eingehende Signale zu triagieren und zu bestimmen, welche den Kenntnisschwellenwert erreichen. Sobald die Ausnutzung jedoch glaubwürdig festgestellt ist, läuft die Frist, auch wenn der CVSS-Score noch nicht abgeschlossen ist.
Können wir ein eigenes Bewertungssystem verwenden?
Ja, sofern es in einer Prüfung verteidigt werden kann. Ein Schema, das internen Bedrohungsmodellkontext mit externen Signalen kombiniert, ist akzeptabel, wenn es dokumentiert, konsistent angewendet wird und Behebungsergebnisse erzeugt, die dem "ohne Verzögerung"-Maßstab entsprechen. Der Branchenstandard aus CVSS plus EPSS plus KEV ist der Weg des geringsten Widerstands, weil er weit anerkannt ist.
Bestraft der CRA einen falschen Schweregrad-Score?
Nicht direkt. Das Bußgeldrisiko liegt im Versäumnis, die Schwachstellenbehandlung wirksam umzusetzen, oder im Versäumnis, aktive Ausnutzung zu melden. Ein einzelner falscher Score ist nicht automatisch ein Verstoß, aber ein fehlender oder inkonsistenter Bewertungsprozess kann zum Beleg dafür werden, dass die Schwachstellenbehandlung nicht wirksam war.
Sollten wir CVSS v3.1 oder v4.0 verwenden?
Beide, wo verfügbar. CVSS v4.0 wurde von FIRST am 1. November 2023 veröffentlicht. Es behält die Gruppen Basis und Umgebung bei, ersetzt die Temporal-Gruppe durch eine engere Threat-Gruppe, die sich auf die Reife von Exploits konzentriert, und ergänzt eine Supplemental-Gruppe (einschließlich Sicherheit, Automatisierbarkeit, Wiederherstellung und Wertdichte), die Kontext erfasst, ohne den Score zu verändern. Die Übernahme verläuft schrittweise: Viele öffentliche CVE-Feeds veröffentlichen weiterhin v3.1. Beide Signale sollten eingelesen werden, wo die Quelle sie bereitstellt, und der Übergang von v3.1 auf v4.0 sollte nicht als Anlass für eine Neubasierung des Backlogs genutzt werden.
Ab wann gelten diese Meldepflichten?
Artikel 14 mit den auf dieser Seite beschriebenen Meldepflichten gilt ab dem 11. September 2026. Die Pflichten zur Schwachstellenbehandlung, Behebung und Offenlegung nach Artikel 13 und Anhang I gelten ab dem 11. Dezember 2027; der Großteil der Verordnung gilt ab diesem späteren Datum. Bauen Sie den Bewertungs- und Meldungsbereitschaftsprozess jetzt auf, damit er vor September 2026 betriebsbereit ist.
Was gilt als "Kenntnis erlangen" für die 24-Stunden-Frist?
Die 24-Stunden-Frühwarnfrist beginnt, wenn der Hersteller von einer aktiv ausgenutzten Schwachstelle Kenntnis erlangt. Das bedeutet glaubwürdige Kenntnis, dass ein böswilliger Akteur die Schwachstelle gegen ein reales Ziel ausgenutzt hat, nicht allein eine private Schwachstellenmeldung oder ein funktionierender Proof-of-Concept. Ein CVSS- oder EPSS-Score setzt die Frist nicht in Gang; die sachverhaltsbezogene Feststellung aktiver Ausnutzung tut es.
Wie sollten wir die ENISA EUVD neben CISA KEV nutzen?
Seit dem 13. Mai 2025 betreibt ENISA die European Vulnerability Database (EUVD), die den Ausnutzungsstatus und eine gesonderte Ansicht aktiv ausgenutzter Schwachstellen veröffentlicht. Verwenden Sie sie als Priorisierungssignal neben CISA KEV. Keiner der beiden Kataloge ist der Auslöser der Meldepflicht nach Artikel 14, und beide sind von der einheitlichen CRA-Meldeplattform nach Artikel 16 getrennt.
Ändert VEX den CRA-Schweregrad oder die Meldepflicht?
Nein. Ein VEX-Dokument (Vulnerability Exploitability eXchange) ändert weder den Meldeauslöser noch die inhärente Schwere einer Schwachstelle. Es ist eine maschinenlesbare Methode, um festzuhalten, ob Ihr Produkt tatsächlich von einer bekannten Schwachstelle betroffen ist (betroffen, nicht betroffen, in Prüfung oder behoben), ergänzend zum SBOM. Das macht es zu einem starken Beleg für eine Herabstufung des Umgebungs-Scores oder einen dokumentierten Aufschub.
Sollten wir SSVC anstelle einer CVSS-Matrix verwenden?
Das ist möglich. SSVC (Stakeholder-Specific Vulnerability Categorization), von CISA gemeinsam mit dem SEI der Carnegie Mellon University veröffentlicht, ist eine entscheidungsbaum-basierte Alternative, die auf der Grundlage von Ausnutzungsstatus, Exponierung und Missionsauswirkung zu einer Behebungsentscheidung gelangt (Track, Track*, Attend, Act). Der CRA schreibt es nicht vor. Es ist ein anerkanntes und vertretbares Framework, wenn Sie einen Entscheidungsbaum der CVSS-plus-EPSS-plus-KEV-Matrix auf dieser Seite vorziehen.