In der Cybersecurity Community herrschte letzte Woche helle Aufregung, weil die Einsparungstruppe von Trumps Gnaden die grandiose Idee hatte, das Funding für den Betrieb des CVE-Systems durch Mitre einzustellen. Wahrscheinlich aufgrund des starken Gegenwindes von der Seite der US-Industrie wurde eine Lösung gefunden und der Betrieb ist (angeblich) für die nächsten 11 Monate gesichert.

Ich will das zum Anlass nehmen, das System hinter den bekannten CVE-Nummern zu erklären und mögliche Entwicklungen aufzuzeigen.

Wozu das Ganze?

Schwachstellen Namen/Identifier zu geben, macht es für die IT-Abteilungen von Organisationen deutlich einfacher, ein systematisches Schwachstellenmanagement zu betreiben. Advisories von Herstellern, Ergebnisse von Scans, Patches und neue Softwareversionen nutzen diese Kennzeichen, um klar zu kommunizieren, um welche Schwachstellen es geht. Für Suchen im Web sind sie hilfreich und in internen Datenbanken werden sie zur Korrelation diverser Informationen genutzt. Sie sind vor allem lieferanten- und dienstleisterübergreifend einheitlich, was für die Interoperabilität extrem hilfreich ist.

Was genau einen solchen Identifier verdient, darüber kann man trefflich streiten, genauso wie man die Kritikalität und Ausnutzungswahrscheinlichkeit bewerten sollte.

One CVE to rule them all?

Das System rund um CVE (Common Vulnerabilities and Exposures), das von der Mitre Corporation im Auftrag der US-Regierung betrieben wird, ist bei weitem nicht das einzige derartige System. Zu erwähnen sind hier etwas das chinesische, das russische, das japanische, das von Github und das System für Cloud-Schwachstellen. Solange alle die dort vergebenen Identifier verschiedene Prefixe (etwa „CVE-“) nutzen, können diese problemlos nebeneinander existieren. Zwischen den Datenbanken wird es aber auch Überlappungen geben: dieselbe Schwachstelle kann in mehreren dieser Systeme einen Identifier bekommen haben, und es braucht ein Mapping dazwischen. Das ist ähnlich wie bei Malware oder Tätergruppen: auch hier existieren verschiedene Benennungssysteme nebeneinander. Das ist nicht schön, weil es Übersetzungstabellen braucht, aber es ist kein Weltuntergang.

Analogie DNS

Es bestehen gewisse Ähnlichkeiten zum Domain Name System (DNS): auch dieses muss sicherstellen, dass Identifier an einer Stelle nur einmal vergeben werden können. Und auch hier hat sich ein vergleichbares, komplexes Ökosystem aus verschiedenen Akteuren herausgebildet.

Initial war das CVE-System zentralistisch organisiert: CVE-Nummern wurden von genau einer Organisation vergeben, nachdem eine Schwachstelle an diese Stelle gemeldet wurde. Das skaliert nur begrenzt, daher wurde das Konzept von CVE Numbering Authorities (CNAs) eingeführt. Diese CNAs können dann in ihrem jeweiligen Bereich eigenständig CVE-Nummer vergeben – entweder aus einem vorher zugewiesenem Nummernpool oder eine, on-demand per API von Mitre abgeholte, freie Nummer.

Ähnliches ist im DNS passiert: war die Domainvergabe initial nur direkt bei der Registry möglich, so ist es heute üblich, dass ein Registrar die Kundeninteraktion übernimmt, und dass der Registrar dann über ein API die eigentliche Domainregistrierung bei der Registry vornimmt.

Rollen / Aufgaben

Registry / Vulnerability-DB

Um die Eindeutigkeit der Nummernzuordnung zu garantieren, wird von einer Organisation eine zentrale Datenbank betrieben (ja, das könnte man auch verteilt machen, aber das ist die Komplexität nicht wert). Diese hat eine natürliche Monopolstellung für den von ihr verwalteten Namensraum, daher macht es Sinn, ihre Aufgaben so eng wie möglich zu definieren.

Im Bereich des DNS gilt das für die meisten Registries: Sie betreiben die autoritative Datenbank der registrierten Domains, und interagieren möglichst wenig direkt mit den Domaininhabern.

Das gleiche gilt für Schwachstellenidentifierdatenbanken.

Registrare / CNAs

Im DNS übernehmen die Registrare die Kundebeziehung und nutzen die Registry nur per API um dann dort im Namen ihrer Kunden die Domain zu registrieren. Die CNAs haben die gleiche Aufgabe für Schwachstellen Die Verwaltung der Registrare/CNAs ist eine weitere Aufgabe der Registry bzw. der VDBs. (Das ICANN-System ist da natürlich speziell.)

Konfliktauflösung

Im DNS wird das selten gebraucht, und wenn, dann ist das entweder ein Thema für die Rechtsabteilung der Registry, von Gerichten oder die UDRP.

Es ist im CVE-System nicht so selten, dass das zu Unstimmigkeiten kommt: Es kann Duplikate geben, wenn eine Schwachstelle von mehreren CNAs eingebracht wird, oder es kann verschiedene Meinungen geben, ob die Meldung überhaupt die Kriterien für die Vergabe eines Identifiers erfüllt. Hier kommen die „Roots“ ins Spiel, die als Schiedsrichter fungieren und Ungereimtheiten auflösen sollen.

Direktvergabe

Manche Registries erlauben die Domainregistrierung auch direkt – oft aber zu prohibitiv hohen Preisen, weil sie sich nur als Fallback sehen, wenn das normale Registrar-System umgangen werden muss. Auch Mitre hat eine Direktvergabe von CVEs angeboten, aber davon abgeraten, diese zu nutzen; der Weg über die CNAs ist klar der präferierte.

Was drohte, wegzubrechen?

Mit der Meldung, dass die Finanzierung des CVE-Systems gestoppt wird, war die natürliche Reaktion: Welche dieser Funktionen ist dadurch betroffen? Falls es nur die Direktvergabe ist, tut das deutlich weniger weh, als wenn die zentrale Datenbank, ihre APIs für CNAs und die Webseite offline gehen würde.

Das Teure sind die manuellen Prozesse: dort, wo eine qualifizierte Fachkraft einlangende Berichte bewertet, wo zwischen verschiedenen Aussagen entschieden werden muss und bei der administrativen Interaktion mit den CNAs. Der technische Weiterbetrieb der IT-System ist im Vergleich dazu finanziell harmlos.

Zu dem, was wirklich gefährdet war, haben wir nur Gerüchte gehört, aber keine belastbaren Informationen bekommen.

Alternativen

In der Szene wurde schnell nach Möglichkeiten gesucht, das drohende Ende des CVE-Systems zu kompensieren. Das ist nicht trivial, denn ein über Jahre gewachsenes System mit einem ganzen Ökosystem an Playern kann man nicht innerhalb von 24h ersetzen. Nichtsdestotrotz gibt es Ansätze, das Thema Vulnerability Databases neu zu denken.

Die EU Vulnerability Database

In der NIS2-Richtlinie wird der ENISA die Aufgabe zugewiesen, eine Europäische Schwachstellendatenbank zu betreiben. Dazu gab es viele Konsultationen mit dem CSIRTs Network (insb. den Mitgliedern, die auch als CNA fungieren), und man war sich einig, dass man eigentlich nicht das CVE-System duplizieren will, sondern als Ergänzung dienen will. So etwa hat sich ENISA als CNA registrieren lassen und einen Prozess definiert, wie nationale CSIRTs über die ENISA CVE-Registrierungen vornehmen können.

Die EUVD selbst fungiert primär als Aggregation bestehender VDBs, umfasst daher neben den Daten aus dem CVE-System auch die von GHSA, GSD, PYSEC und anderen. Die EUVD vergibt beim Importieren aus anderen VDBs eigene Identifier, die mit EUVD- beginnen. Es war initial nicht daran gedacht, selbst neue Schwachstellen im System zu registrieren, sondern diese immer über das CVE-System zu spielen.

Die EUVD war im April 2025 im „Soft Launch“, also im eingeschränktem Testbetrieb. Durch die Vorgänge rund um die CVE-Finanzierung wurde sie mit dem Hinweis auf eine „beta phase“ live geschalten.

In der jetzigen Form kann die EUVD das von Mitre betriebene System nicht ersetzen. Es gibt nicht die APIs zu CNAs, diese sind nicht bei ENISA registriert, und bei der ENISA fehlt auch die Manpower, die manuellen Prozesse umzusetzen.

Das kann sich alles in den nächsten 11 Monaten ändern.

Mit der Umsetzung des Cyber Resilience Acts wird die EUVD weitere Use-Cases implementieren müssen.

Das Global CVE Allocation System

Die Kollegen von CIRCL, die für Open Source für die Cybersecurity-Community bekannt sind – und mit Vulnerability-Lookup auch ein spannendes Werkzeug zum Betrieb einer Schwachstellendatenbank geschrieben haben, haben mit GCVE eine Initiative gestartet, wie mit einem sehr dünnen Layer über mehrere Schwachstellendatenbanken ein einheitliches System gebaut werden kann.

Wieder in der DNS-Analogie gedacht: sie wollen eine schlanke root-Zone bauen, und einzelne TLDs (oder hier Identifier von VDBs) an Registries zu delegieren. Dort spielt dann die Musik, aber solange es einheitliche APIs gibt, ist das alles kein Problem für die Nutzer.

Während die normalen VDBs „thick registries“ implementieren (die Registrare übertragen alle Daten an die Registry), so ist GCVD mehr eine „thin registry“, in der Verweise auf die Datenbanken der Registrare gespeichert werden, bzw. in der Namensräume delegiert werden.

Die CVE Foundation

Mitre hat schon länger einen Beirat, der sie beim Betrieb des CVE-Systems beraten und beaufsichtigen soll. Aus dieser Gruppe von Personen heraus will sich jetzt eine gemeinnützige Stiftung („CVE Foundation“) gründen, die versuchen wird, das ganze System auf eine komplett neue rechtliche und finanzielle Basis zu stellen.

Zusammenfassung

Das Ökosystem der Schwachstellendatenbanken, von denen CVE die wichtigste ist, ist ein wichtiger Baustein in der globalen Sicherheitsarchitektur auf technischer und operativer Ebene. Es wird zwar nicht von einer Person in Nebraska betrieben, wie das im xkcd-Cartoon zu Software-Abhängigkeiten so schön beschrieben wird, aber manchmal ist die koordinierende Arbeit eines kleinen Teams sehr wohl eine tragende Säule, auf die man nicht spontan verzichten kann.

Ich hoffe wir schaffen es, aus dieser Episode zu lernen und das System auf eine tragfähigere Basis zu stellen.