🧱 Single point of failure? – 🔍 Is another vulnerability database needed?
- Daniel Eberhorn
- Apr 20
- 8 min read
Image generated by OpenAI's DALL·E
Why are CVEs and vulnerabilities currently being discussed more frequently?
Common Vulnerabilities and Exposures (CVEs) are standardized identifiers for the unique identification of vulnerabilities in IT systems, software applications, and digital infrastructures. They enable the globally consistent and traceable recording, assessment, and communication of security vulnerabilities. Without this system, a structured and coordinated approach to vulnerable components would be virtually impossible – especially with regard to risk assessment, patch management, and incident response.
CVEs are the standard for vulnerability management worldwide – but what happens when the system falters? That's exactly what happened in 2024. The result: a European counter-proposal called the EUVD. This article explains why this is relevant – and what it means for the future of IT security.
This article provides a detailed insight into the structure and functionality of CVEs:
According to the IBM Security Report 2024, it takes an average of 204 days to detect and contain a successful attack. This demonstrates the importance of globally consistent systems like CVE to shorten this timeframe and assess vulnerabilities quickly and clearly.
Current reason: Delays in the US-based NVD
In spring 2024, the NIST (National Institute of Standards and Technology)—one of the central US authorities for technological standards, security, and research—announced that internal resource constraints would cause significant delays in maintaining the National Vulnerability Database (NVD). NIST has operated the NVD for over two decades and plays a key role in assessing and publishing vulnerability information worldwide. Among other things, the NVD is responsible for enriching CVEs with technical details, CVSS scores, and references to exploits or patches.
The official announcement from March 2024 made it clear that NIST would focus its resources more specifically on prioritized vulnerabilities in the future. This realignment was justified by internal reorganization measures and an increased focus on more strategically important cybersecurity topics. In practice, this meant that thousands of newly registered CVEs were not added to the NVD for weeks or were only rudimentarily supplemented. This resulted in the lack of key information such as CVSS scores, references to exploits, or hints on countermeasures – information that numerous companies, CERTs, and manufacturers rely on in their daily workflows.
According to a VulnCheck analysis from September 2024, 72.4% of the newly registered CVEs in the NVD since February 12, 2024, had not yet been fully analyzed. Particularly worrying is that 46.7% of the vulnerabilities classified as "Known Exploited Vulnerabilities" (KEVs) have also not yet been assessed. This affects critical technologies from vendors such as Adobe, Cisco, Microsoft, and VMware, among others. Although a contract was signed with the company Analygence in May 2024 to address the backlog, progress remains slow. As of September 21, 2024, only 85.9% of the new CVEs had received a CVSS score, meaning 14.1% remain without an assessment. As a result of this announcement, numerous CVEs were either late in enriching their details or not at all.
European response: The European Vulnerability Database (EUVD)
Parallel to the discussion about delays in the NVD, the European Cybersecurity Agency (ENISA) launched the European Vulnerability Database (EUVD) as a publicly accessible beta version in March 2024. The EUVD is part of a strategic initiative of the European Union to strengthen digital sovereignty and reduce critical dependencies on US-based infrastructure. The platform is intended to provide a central European point of contact for vulnerability information, particularly for products and systems with high relevance to the European market.
In terms of content, the EUVD is currently largely based on data from the existing CVE system. It is therefore not a completely independent system, but rather a platform that takes existing CVEs, contextualizes them, and enriches them with additional information for European stakeholders. The EUVD references CVE IDs but adds its own metadata—for example, on the affected European infrastructure, its significance for critical sectors (such as energy, transport, or health), or available regulatory measures.
The EUVD is operated by ENISA in close cooperation with CERT-EU and other European partners. There is currently no legally required reporting to the EUVD, but the long-term goal is to create a stable, interoperable, and trustworthy European complement to CVE/NVD.
EUVD: A new opportunity or additional complication?
Currently, the EUVD merely references existing CVE numbers and expands them with Europe-specific information. There are currently no parallel numbering systems. However, in the future, the introduction of a separate identification format (e.g., "EUV-XXXX") could lead to parallel structures, resulting in information redundancy and potential conflicts.
Redundancy and responsibility
Currently, there are already overlaps between NVD and EUVD. While the NVD was historically considered faster—especially in enriching CVEs with CVSS scores and technical references—it has experienced noticeable delays since the beginning of 2024. The EUVD, on the other hand, scores with targeted additions for European users, including information on critical infrastructure or regulatory contexts (e.g., under the NIS2 Directive).
A specific example is the vulnerability CVE-2024-3094, which affected a backdoor in a widely used open source library. While the NVD needed several days to add the CVSS score and relevant references, the EUVD had already published information on European impacts and recommendations for action for operators of critical infrastructure early on. Another example is CVE-2024-4572, which was listed in the NVD but remained there without any indication of an active exploit—information that was communicated by CERT-EU via the EUVD.
In the long term, clear responsibilities are necessary to systematically avoid such information gaps. Currently, MITRE remains the central issuing authority for CVE numbers, while the EUVD – in close cooperation with CERT-EU – assumes exclusively processing and contextualizing functions. There is currently no legal obligation to report to the EUVD, which has so far limited widespread use by manufacturers and CERTs.
Impact on companies and IT security teams
For companies, this potentially results in duplicate communication channels for vulnerability reports and uncertainties regarding regulatory requirements (e.g., due to the NIS2 Directive). Analysts and CERTs face increased workloads as data from multiple sources must be consolidated and potential discrepancies assessed.
Digital sovereignty vs. global standard
The EUVD fits into a broader European cybersecurity strategy whose overarching goal is to build digital sovereignty. At a time when central security infrastructures such as the NVD are dependent on bottlenecks, delays, and the political frameworks of individual states, a fundamental question arises: Should the management of globally relevant vulnerability information remain permanently in the hands of a single country – or do we need distributed, resilient systems with regional responsibility and global cooperation?
The debate is reminiscent of similar developments in the areas of cloud infrastructure, semiconductor production, and AI governance, where Europe is increasingly seeking to reduce technological dependence. The establishment of the EUVD is therefore more than just a technical measure—it is a political signal: Europe no longer wants to be merely a recipient, but also an active shaper of global cybersecurity structures.
At the same time, digital sovereignty should not be confused with technical isolation. The challenge lies in maintaining international interoperability and standardization – e.g., through CVE IDs or CVSS scores – without losing access to essential information in the event of a failure or withdrawal of individual actors such as NIST or MITRE. The EUVD could represent a decentralized backup system here, but also a regulatory corrective space for the specific requirements of European infrastructures – for example, in the energy, transport, or healthcare sectors.
The introduction of proprietary identification formats such as "EUVD-YYYY-NNNNN" exemplifies this tension. This is not just about technical issues of formatting or data maintenance – it's about a key strategic decision: Does global vulnerability management need to continue to be supported almost entirely by a US-dominated system – or is it time to create alternative structures that more closely reflect European interests?
The CVE system, operated by MITRE and supplemented by the NVD under NIST control, is the de facto standard—but not inherently superior. Its dominance has historically resulted from early development and availability, not necessarily from functional superiority. Recent problems in the NVD—such as massive delays in CVSS assessment and missing exploit references—have demonstrated the vulnerability of this monopoly. According to VulnCheck, as of mid-2024, over 70% of newly issued CVEs were not fully processed in the NVD, many of them with confirmed active exploits.
The introduction of separate EUVD IDs can therefore be understood as an attempt not only to build redundancy but also to regain control over relevance and assessment. However, without proper interoperability with the CVE system, inconsistencies threaten: What happens if a vulnerability is rated as critical in EUVD but moderate in NVD? Which source is considered regulatory? Which recommendation does a manufacturer or CERT follow?
For companies and CERTs, this means in concrete terms: They would have to expand their processes in the future, monitor data streams from multiple sources simultaneously, and, if necessary, supplement their tools with additional parsers, matching engines, and assessment comparisons. While this isn't currently mandatory—since the EUVD doesn't currently issue its own IDs and relies heavily on the CVE system—as the platform becomes increasingly independent, the pressure to consider both sources equally is likely to grow. However, the additional effort involved could be worthwhile if it allows critical vulnerabilities to be identified and closed more quickly before they are exploited globally.
Whether CVE is the "better" system is not the central question. The central question is: Is it sustainable if a single, nationally bound actor decides on the complete technical processing and prioritization of global vulnerabilities? The EUVD poses this question – and with its own identifiers, it may provide the first step toward an answer.
In the long term, therefore, the question arises not only about the technical benefits of the EUVD, but also about its conceptual orientation: Should it merely serve as a "fallback" when the NVD weakens? Or should it operate independently, robustly, and with clear responsibilities – with or without CVE dependency? One thing is clear: a coordinated, international approach would be ideal. But this requires binding governance structures, open interfaces, and a common political will on both sides of the Atlantic.
Further perspectives: governance, technology, market and international developments
Currently, the EUVD is primarily a supplementary information source that can fill specific gaps. However, it currently lacks a clear demarcation and defined responsibilities. To provide long-term added value, ENISA would need to cooperate closely with international structures, ensure reliable technical synchronization, and clearly define how to avoid parallel systems.
Ideally, EUVD would become a robust, complementary and sovereign source of information that complements global standards without fragmenting them.
International Governance – Who decides on vulnerabilities?
A key challenge is the question of governance: Who should assume responsibility for the classification and communication of vulnerabilities in the future? Currently, this responsibility primarily rests with MITRE (as operator of the CVE system) and NIST (as publisher of the NVD). However, a globally uniform, politically independent framework—perhaps under the umbrella of an international organization similar to IANA—could ensure trust and stability in the long term.
The idea: a networked model with clearly defined responsibilities, in which regional platforms like the EUVD act autonomously but are interconnected through common protocols, formats, and escalation procedures. This could reduce inconsistencies in assessments or entries while simultaneously taking national interests into account.
Technical challenges of parallel systems
The coexistence of multiple platforms such as CVE/NVD and EUVD presents companies and manufacturers with new technical hurdles:
Differences in CVSS scores and ratings require multi-level analyses.
Tools such as Qualys, Rapid7 and Tenable rely on NVD – a comparable integration for EUVD is currently missing.
Automation is becoming more difficult: APIs, formats, and update frequencies must be harmonized so that security teams do not operate with different data sets.
Role of industry and private actors
One aspect that should not be underestimated is the role of commercial platforms, bug bounty programs, and vendors. Many report vulnerabilities directly to MITRE—without involving European authorities. The EUVD must therefore find ways to be accepted as an equal player, for example through collaborations with security researchers, programming communities, and platforms such as HackerOne or Bugcrowd.
Compliance and regulation
With the implementation of the NIS2 Directive and similar laws, the pressure on companies to not only identify vulnerabilities but also to address them correctly in accordance with regulations is increasing. It is unclear whether EUVD entries will also be considered a mandatory basis for risk assessments in the future. Without legal clarity, there is a risk of uncertainty regarding audits and certifications (e.g., ISO 27001, TISAX, or BSI IT-Grundschutz).
International examples and lessons
Other countries are also building their own systems: In China, a parallel system with state control exists, the CNNVD (China National Vulnerability Database). There, a government agency decides when vulnerabilities are published.
This and other models show that national self-interest often conflicts with transparency and responsiveness. There is an opportunity to take a middle path (as with IANA, for example) – with openness but also control. The EUVD could thus become a model for a multilateral, balanced vulnerability policy.
