The recent brief scare over the potential discontinuation of the Common Vulnerabilities and Exposures (CVE) program highlighted the security industry’s heavy reliance on it and sparked discussions on contingency strategies should the standardized vulnerability identification and cataloguing system become unavailable.
The short-lived drama was triggered by a letter from MITRE’s director to CVE board members, notifying them that its contract to operate the program would expire on 16 April. The letter warned of “multiple impacts to CVE, including deterioration of national vulnerability databases and advisories,” should a service disruption occur.
The US Cybersecurity and Infrastructure Security Agency’s (CISA) announcement barely a day later that it would continue to sponsor the CVE program via a 11-month contract extension — and presumably for the long term as well — quelled that broad alarm. But unease remains about the long-term stability of the CVE program’s operations and whether future transitions in sponsorship or management could again place a critical piece of global cybersecurity infrastructure at risk.
The volatility around CVE is not the only factor spurring some organizations to look at ways to at least supplement CVE data with vulnerability information from other sources. NIST, which enriches CVEs with CVSS scores, CWE classifications, and CPE product identifiers, has struggled to fulfill this critical role for over a year because of resource constraints. The result is a continued backlog in vulnerabilities that do not have the associated information and context required to make them more searchable, quantifiable and usable for automated security tasks.
Some forward-leaning organizations are already preparing for a post-CVE world by decoupling their operations from it, says Josh Lefkowitz, co-founder and CEO of Flashpoint. They have begun using processes and tools that don’t always require CVE, to identify the threats that matter, to figure out if they are exploitable, what needs to be fixed first and how threat actors are leveraging them.
In a way, what’s happening now has been some time in the making, Lefkowitz tells CSO. “The challenges faced by the CVE program have been mounting. The CVE system hasn’t kept pace with the speed and complexity of today’s threat landscape. Vulnerabilities are being discovered faster, exploited sooner, and are affecting broader supply chains, often before a CVE ID is even assigned.”
The growing gap between discovery and disclosure is evident in recent data: Google’s Threat Intelligence Group (GTIG) recorded 75 vulnerabilities that attackers exploited as zero-days in 2024—often before a fix, or even a CVE identifier, was available.
Decoupling from CVE
The trends heighten the need for organizations to start decoupling their vulnerability operations from sole reliance on CVE and ensuring their security tools can process vulnerabilities with or without CVE identities, Lefkowitz says. “As organizations continue to seek resiliency and reliability in their security and vulnerability management programs, it’s critical they begin integrating alternate and complementary sources of vulnerability intelligence.”
How to do that though easily or effectively is the big question. The CVE system underpins vulnerability detection and response across the entire software ecosystem, including the tools and platforms used by government agencies, notes Joe Nicastro, field CTO at Legit Security. “Without it, the shared language we rely on to identify, triage, and patch vulnerabilities evaporates, and we’re left with fragmentation, confusion, and slower response times during a time when software attacks and threat actors are more prevalent than ever.”
For the moment, the European Union Agency for Cybersecurity (ENISA)’s recently launched European Vulnerability Database (EUVD) represents one of the most formal efforts by anyone to reduce dependence on CVE. The EUVD’s stated mission is to provide timely, authoritative vulnerability information for software and hardware products used within the EU. The database aggregates vulnerability information from a variety of sources including open-source databases, advisories and alerts from national cybersecurity incident response teams and vendor alerts. It presents the data under three separate categories, or dashboard views: critical vulnerabilities, exploited vulnerabilities and EU coordinated vulnerabilities.
The EUVD represents a strategic effort by EU nations to establish regional autonomy in vulnerability management. Launched in May 2025, EU authorities have framed the EUVD as a complement to CVE rather than as a replacement for it. The database has institutional credibility and backing and its mission aligns with growing calls for a more diversified and resilient vulnerability disclosure ecosystem. Even so EUVD lacks the global adoption and infrastructure of CVE and needs greater vendor participation and tooling integration before it can match CVE in scale and ecosystem support.
“Since the goal of any vulnerability database is to provide actionable information, a new database such as the EUVD really requires tools using it to solve production problems,” says Tim Mackey, head of software supply chain risk at Black Duck. To deliver actionable insights comparable to those provided by the CVE database, the EUVD must be fully integrated into tools and workflows—such as scanners, patch management systems and SIEM platforms. In addition, “viable alternative options will require collaboration between database providers and tool vendors where the implementation and workflows are then accepted by regulators and corporate auditors,” Mackey says.
Current alternatives include diverse vendor sources
Independent providers of aggregated vulnerability information such as Flashpoint, VulnCheck, Tenable, BitSight and others are another option. Many of these vendors offer curated datasets that capture vulnerabilities often missed or delayed by CVE, Lefkowitz points out. They also offer critical context such as exploitability, ransomware risk, and social risk.
“To operationalize this intelligence, organizations must rethink how they process and respond to vulnerabilities,” Lefkowitz says. That starts with decoupling workflows from rigid dependencies on CVE/NVD and ensuring their security tools can handle vendor-specific vulnerability identifiers if needed. “Risk prioritization should be threat-informed — factoring in exploit code availability, asset exposure, and even ransomware targeting likelihood,” Lefkowitz noted. Security decision makers should consider vulnerability platforms that integrate directly into their SIEMs, SOARs, patching tools and ticketing systems, he advises.
There are other options for organizations to diversify their sources of vulnerability information including vendor advisories, GitHub disclosures, and platforms like HackerOne or Bugcrowd which frequently publish vulnerabilities sometimes before the details make it into a formal database like CVE.
Software vendors like Oracle, Microsoft, and Red Hat routinely publish cybersecurity bulletins for their software, Mackey from BlackDuck says. Similarly, GitHub maintains a repository of vulnerability information known as GitHub Advisory Database and there are several regional vulnerability databases in Australia, the EU, Japan, and China that organizations can tap as well, Mackey says. Examples include AusCERT, VulDB, JPCERT CC, and CNNVD. Consider also providers of Software Composition Analysis (SCA) tools who often augment NVD data to create their own security advisories, Mackey says.
“Of course, there are many different application security testing techniques such as static application security testing, interactive application security testing, and fuzzing that can be used to identify vulnerabilities that were never disclosed,” he says. “Each of these options are valuable, but when combined with each other, a complete view of application risks due to cybersecurity can be obtained.”
CISA’s catalog of Known Exploited Vulnerabilities (KEV) is another useful — and in the case of US federal agencies, mandated — resource for vulnerability data. The catalog is a list of exploited cybersecurity vulnerabilities that pose a risk to government and critical infrastructure organizations. Its primary use case is to guide them in identifying and remediating high-risk vulnerabilities that pose an immediate threat. Once CISA enters a vulnerability in KEV, US civilian federal agencies have a strict deadline within which they have to remediate the flaw or to discontinue use of the affected product until they can remediate it. Though its intended audience is relatively narrow, any organization can use KEV to prioritize patching efforts.
The key though is keeping expectations in check. The CVE program’s core functions include providing a common taxonomy and nomenclature for scoring and rating vulnerabilities in terms of risk. If the security community were to lose the program, researchers and bug hunters would no longer be speaking a common language when categorizing and rating security vulnerabilities, warns Ben Radcliff, senior director, cyber operations at Optiv. Any lack of cohesion and transparency in publishing known security vulnerabilities would likely lead to slower, inconsistent responses to threats from security teams, particularly when presented with zero-day vulnerabilities, Radcliff says.
“The primary barrier to standing up a CVE alternative would be regaining consensus from the entire global security community,” he predicts. “CVE is long-established and well respected and so has had a lot of history in building trust in the fidelity of its collected findings. Any post-CVE approach would be likely to remain decentralized and inconsistent for the foreseeable future.”