Auf der Suche nach Alternativen zum CVE-Programm – Source: www.csoonline.com

Dave Hoeek – shutterstock.com

Der jüngste kurze Panikausbruch wegen der möglichen Einstellung des Common Vulnerabilities and Exposures (CVE)-Programms hat die starke Abhängigkeit der Sicherheitsbranche von diesem Programm deutlich gemacht. Er führte zu Diskussionen über Notfallstrategien , falls das standardisierte System zur Identifizierung und Katalogisierung von Schwachstellen nicht mehr verfügbar sein sollte.

Obwohl das CVE-Programm durch eine Verlängerung des Vertrags um elf Monate – und vermutlich auch langfristig – weiter unterstützen wird, ist die Unsicherheit hinsichtlich der langfristigen Stabilität des CVE-Programms ist nicht der einzige Faktor, der einige Organisationen dazu veranlasst, nach Alternativen zu suchen. Viele erwägen CVE-Daten zumindest durch Schwachstelleninformationen aus anderen Quellen zu ergänzen. Das NIST, das CVEs mit CVSS-Bewertungen, CWE-Klassifizierungen und CPE-Produktkennungen anreichert, hat aufgrund von Ressourcenengpässen seit mehr als einem Jahr Schwierigkeiten, diese wichtige Aufgabe zu erfüllen.

Das Ergebnis ist ein anhaltender Rückstand bei Schwachstellen, für die keine Informationen und Kontextdaten vorliegen. Diese sind erforderlich, um sie für automatisierte Sicherheitsaufgaben besser durchsuchbar, quantifizierbar und nutzbar zu machen.

„Einige zukunftsorientierte Unternehmen bereiten sich bereits jetzt auf eine Zeit nach CVE vor, indem sie ihre Abläufe davon abkoppeln“, erklärt Josh Lefkowitz, Mitbegründer und CEO von Flashpoint, gegenüber CSO. „Sie haben begonnen, CVE-unabhängige Prozesse und Tools einzusetzen, um relevante Bedrohungen zu identifizieren.“

Allerdings hat sich das, was jetzt geschieht, laut Lefkowitz schon seit einiger Zeit abgezeichnet. „Die Herausforderungen für das CVE-Programm sind gewachsen. Das CVE-System hat mit der Geschwindigkeit und Komplexität der heutigen Bedrohungslandschaft nicht Schritt gehalten“, betont der Experte und ergänzt: „Schwachstellen werden schneller entdeckt, früher ausgenutzt und betreffen immer größere Lieferketten, oft noch bevor eine CVE-ID vergeben wird.“

Die wachsende Kluft zwischen Entdeckung und Offenlegung wird durch aktuelle Daten deutlich: Die Threat Intelligence Group von Google (GTIG)  registrierte im vergangenen Jahr 75 Schwachstellen, die Angreifer als Zero-Day-Exploits ausnutzten – oft, bevor ein Fix oder sogar eine CVE-Kennung verfügbar war.

Entkopplung von CVE

„Diese Trends verstärken die Notwendigkeit für Unternehmen, ihre Schwachstellenbekämpfung von der alleinigen Abhängigkeit von CVE zu entkoppeln. Sie sollten sicherstellen, dass ihre Sicherheitstools Schwachstellen mit oder ohne CVE-Identitäten verarbeiten können, mahnt Lefkowitz. „Da Unternehmen weiterhin nach Resilienz und Zuverlässigkeit in ihren Programmen zum Sicherheits- und Schwachstellenmanagementstreben, ist es von entscheidender Bedeutung, dass sie damit beginnen, alternative und ergänzende Quellen für Schwachstelleninformationen zu integrieren.“

Die große Frage ist jedoch, wie dies einfach und effektiv umgesetzt werden kann. „Das CVE-System bildet die Grundlage, um Schwachstellen im gesamten Software-Ökosystem zu erkennen und zu beheben, einschließlich der von Behörden verwendeten Tools und Plattformen“, räumt Joe Nicastro, Field CTO bei Legit Security, ein. „Ohne dieses System würde die gemeinsame Sprache, auf die wir uns bei der Identifizierung, Einstufung und Behebung von Schwachstellen verlassen, verschwinden.“

Der Security-Spezialist warnt: „Wir hätten mit Fragmentierung, Verwirrung und längeren Reaktionszeiten zu kämpfen – und das in einer Zeit, in der Softwareangriffe und Bedrohungsakteure mehr denn je zunehmen.“

Derzeit stellt die kürzlich von der Europäischen Agentur für Cybersicherheit (ENISA) eingerichtete Europäische Schwachstellendatenbank (EUVD) eine der formellsten Bemühungen dar, die Abhängigkeit von CVE zu verringern. Die erklärte Aufgabe der EUVD besteht darin, zeitnahe und zuverlässige Informationen über Schwachstellen in Software- und Hardwareprodukten, die innerhalb der EU verwendet werden, bereitzustellen. Die Datenbank sammelt Informationen zu Schwachstellen aus einer Vielzahl von Quellen. Darunter befinden sich Open-Source-Datenbanken, Hinweise und Warnmeldungen von nationalen Cybersicherheits-Notfallteams und Warnmeldungen von Anbietern.

Die Daten werden in drei separaten Kategorien oder Dashboard-Ansichten dargestellt: kritische, ausgenutzte und von der EU koordinierte Schwachstellen.

Die EUVD ist eine strategische Initiative der EU-Mitgliedstaaten, um regionaler Autonomie im Bereich Schwachstellenmanagement zu schaffen. Im Mai 2025 ins Leben gerufen, positionieren die EU-Behörden die EUVD, als Ergänzung zu CVE und nicht als deren Ersatz. Die Datenbank genießt institutionelle Glaubwürdigkeit und Unterstützung, und ihre Aufgabe steht im Einklang mit den wachsenden Forderungen nach einem diversifizierteren und widerstandsfähigeren Ökosystem für die Offenlegung von Schwachstellen.

Dennoch fehlt es dem EUVD bislang an der globalen Akzeptanz und Infrastruktur der CVE-Datenbank, und es bedarf einer stärkeren Beteiligung der Anbieter und einer besseren Integration von Tools, bevor es mit CVE in Bezug auf Umfang und Unterstützung des Ökosystems mithalten kann.

„Da das Ziel jeder Schwachstellendatenbank darin besteht, verwertbare Informationen bereitzustellen, benötigt eine neue Datenbank wie das EUVD Tools, die zur Lösung von Produktionsproblemen dienen“, erläutert Tim Mackey, Leiter des Bereichs Software Supply Chain Risk bei Black Duck. Um umsetzbare Erkenntnisse zu liefern, die mit denen der CVE-Datenbank vergleichbar sind, müsse die EUVD vollständig in Tools und Workflows integriert werden, beispielsweise in Scanner, Patch-Management-Systeme und SIEM-Plattformen.“

Darüber hinaus „erfordern praktikable Alternativen eine Zusammenarbeit zwischen Datenbankanbietern und Tool-Anbietern, wobei die Implementierung und die Workflows dann von Regulierungsbehörden und Unternehmensprüfern akzeptiert werden müssen“, fügt Mackey hinzu.

Aktuelle Alternativen umfassen verschiedene Anbieterquellen

Unabhängige Anbieter von aggregierten Schwachstelleninformationen wie Flashpoint, VulnCheck, Tenable, BitSight und andere sind eine weitere Option. „Viele dieser Anbieter bieten kuratierte Datensätze, die Schwachstellen erfassen, die von CVE oft übersehen oder verzögert gemeldet werden“, so Lefkowitz. „Sie bieten auch wichtige Kontextinformationen wie Ausnutzbarkeit, Ransomware-Risiko und soziales Risiko.“

Um diese Informationen operationalisieren zu können, müssten Unternehmen überdenken, wie sie Schwachstellen verarbeiten und darauf reagieren, merkt der Flashpoint-CEO an. „Das beginnt damit, dass Workflows von starren Abhängigkeiten von CVE/NVD entkoppelt werden. Zudem wird sichergestellt, dass die Sicherheitstools bei Bedarf auch herstellerspezifische Schwachstellenkennungen verarbeiten können.“

Nach Meinung von Lefkowitz sollte die Priorisierung von Risiken auf der Grundlage von Bedrohungsinformationen erfolgen und dabei die Verfügbarkeit von Exploit-Code, die Gefährdung von Assets und sogar die Wahrscheinlichkeit von Ransomware-Angriffen berücksichtigen. „Sicherheitsverantwortliche sollten Schwachstellenplattformen in Betracht ziehen, die sich direkt in ihre SIEMs, SOARs, Patching-Tools und Ticketing-Systeme integrieren lassen“, rät er.

Unternehmen haben weitere Möglichkeiten, ihre Quellen für Schwachstelleninformationen zu diversifizieren. Darunter Herstellerhinweise, GitHub-Veröffentlichungen und Plattformen wie HackerOne oder Bugcrowd, die Schwachstellen häufig veröffentlichen, bevor die Details in eine formelle Datenbank wie CVE gelangen.

Mackey von BlackDuck verweist darauf: „Softwareanbieter wie Oracle, Microsoft und Red Hat veröffentlichen regelmäßig Cybersicherheitsbulletins für ihre Software. In ähnlicher Weise unterhält GitHub ein Repository mit Informationen zu Schwachstellen, das als „GitHub Advisory Database“ bekannt ist. Zusätzlich gibt es mehrere regionale Datenbanken für Schwachstellen in Australien, der EU, Japan und China.

Beispiele hierfür sind AusCERT, VulDB, JPCERT CC und CNNVD. „Zu berücksichtigen sind auch Anbieter von Software Composition Analysis (SCA)-Tools, die häufig NVD-Daten ergänzen, um eigene Sicherheitshinweise zu erstellen“, fügt Mackey hinzu. „Natürlich gibt es viele verschiedene Techniken zum Testen der Anwendungssicherheit, wie statische Tests, interaktive Tests und Fuzzing, mit denen Schwachstellen identifiziert werden können, die nie offengelegt wurden.“

„Jede dieser Optionen ist wertvoll, aber in Kombination miteinander lässt sich ein vollständiges Bild der Anwendungsrisiken aufgrund von Cybersicherheit erstellen“, so der BlackDuck-Experte.

Der Katalog „Known Exploited Vulnerabilities“ (KEV) der CISA ist eine weitere nützliche – und im Falle von US-Bundesbehörden sogar vorgeschriebene – Quelle für Schwachstellendaten. Der Katalog besteht aus einer Liste von ausgenutzten Cybersicherheitsschwachstellen, die ein Risiko für Regierungsbehörden und kritische Infrastrukturen darstellen. Er dient in erster Linie dazu, sie bei der Identifizierung und Behebung von hochriskanten Schwachstellen zu unterstützen, die eine unmittelbare Bedrohung darstellen.

Sobald die CISA eine Schwachstelle in KEV einträgt, haben US-Bundesbehörden eine strenge Frist, innerhalb derer sie die Schwachstelle beheben oder die Verwendung des betroffenen Produkts einstellen müssen, bis sie behoben ist. Obwohl der Zielkreis relativ eng ist, kann jede Organisation KEV nutzen, um Prioritäten für Patch-Maßnahmen zu setzen.

Entscheidend ist jedoch, die Erwartungen im Zaum zu halten. Zu den Kernfunktionen des CVE-Programms gehört die Bereitstellung einer gemeinsamen Taxonomie und Nomenklatur, um Schwachstellen hinsichtlich ihres Risikos zu bewerten und einzustufen. „Wenn die Sicherheitsgemeinschaft dieses Programm verlieren würde, würden Forscher und Bug-Jäger bei der Kategorisierung und Bewertung von Sicherheitslücken keine gemeinsame Sprache mehr sprechen“, warnt Ben Radcliff, Senior Director, Cyber Operations bei Optiv.

„Jede mangelnde Kohäsion und Transparenz bei der Veröffentlichung bekannter Sicherheitslücken würde wahrscheinlich zu langsameren und inkonsistenten Reaktionen der Sicherheitsteams auf Bedrohungen führen, insbesondere bei Zero-Day-Schwachstellen“, ergänzt Radcliff.

„Die größte Hürde für die Einführung einer CVE-Alternative wäre die Wiederherstellung des Konsenses innerhalb der gesamten globalen Sicherheitsgemeinschaft“, prognostiziert er. „CVE ist seit langem etabliert und hoch angesehen und hat daher eine lange Tradition darin, Vertrauen in die Zuverlässigkeit seiner gesammelten Erkenntnisse aufzubauen. Jeder Ansatz nach CVE würde wahrscheinlich auf absehbare Zeit dezentralisiert und inkonsistent bleiben.“ (jm)