A Vulnerable Future: MITRE’s Close Call in CVE Management

Last week, one of the biggest concerns in the cybersecurity industry created a crisis that was avoided at the last minute. On April 16th, 2025, the MITRE Corporation announced:  “The current contracting pathway for MITRE to develop, operate, and modernize CVE and several other related programs, such as CWE, will expire.”

Official letter from MITRE Corp announcing the implications and expiration of the CVE Program

The panic surrounding MITRE’s potential cessation of CVE management stems from the critical role the CVE system plays in the application security landscape over the last 25 years. As the authoritative body responsible for managing and developing the CVE program, MITRE’s activity has been a cornerstone for organizations looking to effectively manage their security risks.

The uncertainty regarding the renewal of MITRE’s contract with the U.S. government raised concerns about the continuity of CVE management and the threat of losing a trusted and standardized framework for identifying vulnerabilities. It also highlighted how closure of this program could lead to significant disruptions in how vulnerabilities are tracked and addressed in the industry, causing organizations to struggle in finding valid alternatives, and ultimately leading to confusion surrounding vulnerability management practices.

To calm concerns, just a few hours after the letter was made public by MITRE,  the U.S. Cybersecurity and Infrastructure Security Agency (CISA) announced that it had extended its contract with MITRE for at least the next 11 months.

But before diving into the possible ending of MITRE’s management of the CVE Program, let’s take a look at how it all started and familiarize ourselves with some of the other key players in this field of vulnerability management.

Understanding The CVE Journey

The CVE Program is sponsored by CISA and managed by the non-profit MITRE Corporation, which provides technical expertise in various fields, including cybersecurity. The CVE program was established in 1999,  based on its mission of identifying, defining, and cataloging publicly disclosed software vulnerabilities using a standardized naming convention. MITRE oversees the ongoing management of the CVE database, which contains nearly 290,000 CVEs and involves collaboration with various stakeholders to ensure accuracy.

Typical journey of a CVE from discovery to advising end-users (click to enlarge)

Once a vulnerability is discovered, a CNA, which is a group of authorized organizations by the CVE Program to assign CVE IDs to vulnerabilities, assigns a CVE ID which is then posted on the CVE List by MITRE. There are currently around 450 CNAs, including organizations like JFrog, MITRE, Microsoft and others. The National Vulnerability Database (NVD), maintained by NIST, enriches these CVEs with data, including CVSS, CWE, CPE and more. In addition to their role in funding the CVE program, CISA, also acts as an Authorized Data Publisher, which helps NVD to enrich CVE records with additional missing information such as CVSS, CWE, CPE, and KEV.

Here you can see the unmistakable trend of CVE discovery since the establishment of the MITRE Program:

Growth in the number of CVEs discovered from 1999 to 2024 (click to enlarge)

The data from NVD and the CVE Project is consumed by many sources. Taking an example from the open-source community, the GitHub Advisory Database is a major resource that includes both CVEs and GHSA identifiers specifically for projects hosted on GitHub. Additionally, other sources like OSV and commercial products like the JFrog Catalog, function as a database that aggregates multiple vulnerability data sources based on multiple vulnerability identifiers. Likewise, there are also distribution maintainers that track vulnerabilities through security advisories detailing affected packages and issuing updates in the context of maintaining their products.

How the End of the CVE Program Could Affect Vulnerability Management

As seen in the MITRE announcement,  the CVE program’s future is highly vulnerable to unforeseen disruptions. To fully understand the implications of a potential shutdown, it’s important to analyze how such a scenario could affect vulnerability management.

In such a scenario, the application security  industry will have to deal with three main challenges:

1. Loss of a Central Authority
2. No New CVEs Assignments
3. Lack of CWE Maintenance

While CWEs have been crucial in raising awareness about security issues, their impact may be the least significant, as there are already 943 documented CWEs that can be readily assigned using sources like NVD and GitHub. Although the absence of new CWEs for emerging security types is a concern, in comparison to other burning issues, it is less important to address in the short term.

Losing a central authority like MITRE, however, which has managed the CVE program for the last 25 years, is clearly a significant concern for the application security community. Closure of the MITRE CVE Program would inevitably lead to a lack of standardization in vulnerability identification and management, resulting in inconsistencies regarding how vulnerabilities are reported and prioritized.

The absence of a trusted, centralized organization would certainly create confusion, as stakeholders might start adopting various independent methods for tracking and referencing vulnerabilities, which in turn could lead to miscommunication and chaos across the industry. This shift could ultimately undermine the integrity and reliability of vulnerability management practices, globally exposing the software industry to an ever growing number of cyber risks.

Current Alternatives

For open-source projects, we can find alternate vulnerability identifiers that have been established by various vendors and open-source projects.

Examples of alternate open-source identifiers include:

• GO-2021-0223 – Go vulnerability identifier
• PYSEC-2023-46 – Python vulnerability identifier
• GHSA-chh6-ppwq-jh92 – GitHub vulnerability identifier
• CGA-gx9q-58qg-jvj2 – Wolfi vulnerability identifier

In the commercial sector, we can also find alternative vulnerability identifiers that have been established by various vendors for their specific environments.

Examples of alternate commercial identifiers include:

• ALAS-2025-1966 – Amazon vulnerability identifier
• MS12-020 – Microsoft vulnerability identifier
• XRAY-201848 – JFrog Xray vulnerability identifier

Limitations of Alternative Identifiers

Considering these identifiers as viable replacements for CVE is misguided. Most alternatives are tailored to their specific ecosystems and do not serve as global identifiers. Since GHSA is the only one that is not based on a specific project or product, it could not be considered as a future alternative, but currently only allows GHSA assignments for open source projects hosted on GitHub.

To evaluate whether alternative identifiers can effectively replace CVEs, let’s use the Python ecosystem as a case study. According to the JFrog Catalog, a centralized database for open-source packages and their associated vulnerabilities, there are 4,094 vulnerabilities related to PyPI packages. However, when we compare this figure to the number of alternative PYSEC entries provided by the Python Packaging Authority, we found that only 2,403 of these vulnerabilities have an equivalent PYSEC identifier. This means that 41% of the known vulnerabilities lack an equivalent PYSEC identifier. This indicates that the coverage of alternative identifiers is still far from comprehensive, even within a specific ecosystem like Python open source packages.

A breakdown of Python packages’ CVEs, with and without PYSEC identifiers

New Alternative Initiatives

Given the key challenges outlined and the fact that none of the alternatives support global vulnerability management, in times of uncertainty regarding the future of the CVE Program, it is encouraging to see a number of rapid responses from the application security community, such as GCVE, and the CVE Foundation initiative taken by current  CVE board members.

The CVE Foundation

Active members of the CVE Board have formally established the CVE Foundation to secure the future of the CVE Program. This initiative aims to ensure the long-term viability, stability, and independence of the CVE Program. It also helps to ensure that the CVE program remains independent by avoiding reliance on the interests and funding of governmental organizations and private companies. As the contract is renewed for just the next 11 months, we assume that this initiative is probably going to be the main alternative going forwards.

Vulnerability Management Suffers Ongoing Challenges

Unfortunately, the current situation is not entirely new, as vulnerability management tools have long faced challenges and must continually adapt to evolving circumstances. The possibility of MITRE’s CVE activity shutting down came after other ongoing challenges in the supply of up-to-date vulnerability information. A good example of this is the recent NVD announcement regarding delays in their CVE analysis. These delays have resulted in a significant backlog, with most CVEs from early 2024 still waiting for CVSS and CPE enrichment.

These delays pose significant issues for vulnerability management tools that rely on the NVD as a primary source for assessing  and prioritizing CVE relevence. The backlog in CVE enrichment information, and more specifically the lack of CVSS scores, which many tools use to evaluate risk, challenge the ability to prioritize and effectively remediate many of these vulnerabilities. Even though CISA was added as an ADP to enrich CVEs data, it doesn’t seem to be resolving the problem as the backlog continues to be a major issue.

A breakdown of CVEs with and without enriched CVSS scores by NVD and CISA

NVD coverage in 2024 was only 47.9%, highlighting a significant gap that requires a better solution. Additionally, out of 37,621 CVEs in 2024, only 8,947 were enriched with CVSS by CISA, accounting for just 24% of all CVEs. This means that approximately 28.3% of CVEs are still waiting for assessment and CVSS enrichment. The current lack of supplemental information underscores the need for improved support and coverage by CISA.

In addition to these issues, delays in the availability of CPE data weaken the ability to match CVEs to their corresponding vulnerable packages, components, distributions, and versions. This scenario can lead to both overreacting to vulnerabilities that do not represent a significant threat or, even more concerning, the neglect of serious CVEs that require immediate attention.

To compound the situation, the NVD also announced that all CVEs prior to January 1, 2018, will now be classified as deferred, meaning that they won’t be updated with new CVSS scores, CPE, CWE, or exploitability analysis unless it is explicitly requested or the CVE is known to be exploitable.

What You Should Expect From Vulnerability Management Tools

As the future of the CVE program remains unclear, and vulnerability management tools continue to face additional challenges, it is really up to each organization to gain a better understanding of what to expect from specific security solutions when entrusting them with managing the risks of their software development lifecycles.

Leverage Vendor Security Advisories and CNAs

Companies like Microsoft, Amazon and JFrog, as well as projects such as Go, Python, and Apache frequently release their own vulnerability assessments, with some even assigning their own unique vulnerability identifiers. Vulnerability management tools need to keep track of these advisories that provide critical context and updated information. This is especially important in a world that may have to grapple with not having a centralized, managed vulnerability database, like the MITRE CVE Program, to rely on.

Even without closure of the CVE Program, it is still imperative that organizations address these issues today for the following reasons:

1. Even today, not all vulnerabilities are assigned CVE IDs.
2. Security advisories related to specific projects, such as those from Linux distributions, offer crucial insights into how a vulnerability impacts a particular software application within its context. For this reason, it is generally recommended to rely on vulnerability data directly from the vendor, as they are more familiar with the context and provide more accurate and detailed information on severity and mitigation. Typically, it is also more reliable than what is found in a general CVE database.
3. CNAs and vendor security advisories often deliver quicker analysis, which is crucial given the delays caused by the NVD’s backlog.

Example of a CVE assigned with a CVSS score by JFrog CNA which is missing from the NVD CVSS.

Utilize Alternative Vulnerability Databases

In addition to vendor security advisories, it is essential to receive input from multiple vulnerability databases to avoid relying on a single source. Some of these include:

• GitHub Advisory Database – This database includes both CVEs and GHSA identifiers for projects hosted on GitHub. GitHub aggregates advisories from multiple security sources, including NPM, PHP, Python, Ruby, Rust, and more. Additionally, it reviews CVEs and assigns each vulnerability a non-quantitative, human-readable severity value, along with a CWE, vulnerable version ranges, and more.

• Open Source Vulnerability (OSV) – OSV provides a comprehensive, open-source-focused catalog of vulnerabilities across various ecosystems and supports most unique identifiers. By consolidating these identifiers in one place, OSV simplifies the process of tracking and managing vulnerabilities.

• The Exploit Prediction Scoring System (EPSS) – As an alternative to the CVSS score, EPSS helps prioritize vulnerabilities by predicting their likelihood of being exploited in the wild. This allows organizations to focus on the most critical, exploitable vulnerabilities, improving the efficiency of their vulnerability management and reducing potential risks.

While these databases are not a replacement for the CVE Program, it is highly recommended to use them in conjunction with the CVE information. This approach allows for cross-referencing information about vulnerabilities and staying informed about security risks that may not appear in the NVD.

Support Alternative Vulnerability Identifiers

Vulnerability management tools should support and provide the user with various known identifier formats provided by different advisories, such as those from GitHub, Go, PyPI, and others.

This capability is crucial for recognizing vulnerabilities that may not be listed in CVEs, thereby creating a holistic view of the security landscape. Relying solely on one source, such as  NVD or CVE.org, can be problematic, as we have seen.

Example of a vulnerability assigned with a PYSEC identifier

Analyze and Enrich Critical Vulnerabilities

As security solutions are critical assets in an organization’s risk management strategy, they must invest effort in vulnerability research and provide the most accurate security information possible. Analyzing vulnerabilities and regularly reviewing them is a vital task, as in many cases relying only on the public information is limited and often partially documented in a format designed for consumption by automated security solutions and not readily understood by developers, operations and security professionals. Diving into the vulnerable code, exploring patches and running proof-of-concept tests are critical for providing the most realistic exploitability information. The process of researching and analyzing vulnerabilities involves evaluating their potential impact, determining appropriate remediation strategies and understanding their applicability based on the unique aspects of specific environments.

How JFrog Addresses Ongoing CVE Challenges

At JFrog, we are committed to proactively ensuring safety in an ever-changing landscape. All the efforts mentioned above are part of our ongoing commitment to the community and our customers.

JFrog consistently aggregates data from multiple sources, including the NVD, OSV, the GitHub Advisory Database, vendor advisories – such as those from Linux distributions –  and relevant ecosystem information. While a potential disruption in the CVE program could be significant, vulnerability data will still be incorporated from multiple advisories, including our own CVE enrichment efforts by the JFrog Security Research team.

For our customers using JFrog Xray, we also provide the context of the application. For example, when scanning a Red Hat Linux based application with Xray, it provides the relevant Red Hat Security Advisory information for vulnerabilities found in Red Hat packages. This information is crucial since Red Hat security advisories provide important contextual information on how the vulnerability affects Red Hat products and a more accurate severity score than general CVE databases.

JFrog consistently monitors the release of new vulnerabilities and supports multiple vulnerability identifier formats, preparing for any situation as well as any unexpected challenges that may arise in managing the latest vulnerabilities.

In addition, the JFrog Security Research team keeps monitoring and researching high-profile vulnerabilities, whether they are assigned with a CVE ID or not, providing valuable vulnerability analysis enrichment. The research team is composed of security experts that perform manual research on vulnerabilities and assign a JFrog Severity Score based on a deep technical analysis that allows deeper understanding of the actual risk posed by specific vulnerabilities. As part of the analysis, the team also provides detailed technical mitigation solutions and adds information on any prerequisites for exploitation of the analyzed vulnerabilities. These prerequisites are then integrated with our industry leading  Contextual Analysis engine for the best possible applicability detection when a CVE is reported by Xray.

Conclusion

Although we were able to avoid significant challenges this time around due to the last-minute extension of MITRE’s contract, the current situation serves as a crucial warning that organizations must be prepared for potential disruptions in the flow of critical CVE information going forwards. The rapid responses suggested by the application security community, including the establishment of The CVE Foundation, underscore the importance of having alternative solutions ready to go.

The short duration of the renewed contract leaves the future uncertain. The CVE Foundation points in a promising direction for ensuring the continued operation of the CVE program and addressing these concerns. However, it remains to be seen how this will evolve and what impact it will have on CISA funding and MITRE’s role in managing the program in the future.

Moving forward, organizations must adopt a diversified approach to vulnerability management and avoid relying on a single source for their CVE information. Proactive exploration and integration of various resources are essential for maintaining a robust and resilient security posture, regardless of whether the current CVE Program is shut down or not. Automation is also an important key in a world of complex, distributed information. Adopting security scanning tools that support multiple vulnerability sources, support non-CVE vulnerabilities, and conduct vulnerability research for better accuracy are the preferred choices for dealing with the ever-evolving threats of vulnerability management.

To stay on top of the latest developments in CVEs and other critical application security issues, make sure to bookmark and visit JFrog’s Security Research Center.