A Brief Overview of Common Vulnerabilities and Exposures (CVE)
Learn about the importance of CVEs in Vulnerability Management, CVE Program organization, and the CVE generation process
Anyone working in cybersecurity would have come across the term ‘CVE’ more often than they would like to think. For many of us, a CVE ID is a straightforward tag we associate with a specific vulnerability, a routine part of our daily work. Yet, beneath this simplicity lies a complex process, a journey from the identification of a new vulnerability to its public disclosure that benefits the entire cybersecurity community, product vendors, and consumers alike.
In this article, I discuss about why a need for such a system was felt, humble beginnings of the CVE Program, and the evolution of the CVE Program initiative over a period to its current stature. I also explore the roles of various stakeholders involved, and an understanding of the process of assigning CVE IDs to discovered vulnerabilities.
Before delving deeper, let’s start by understanding what is CVE and why is it so important?
What is CVE?
CVE stands for Common Vulnerabilities and Exposures. Each CVE entry in the catalogue, also known as a CVE ID, includes an identification number, a description, and at least one public reference for the vulnerability.
The CVE ID is a unique identifier assigned to each vulnerability, following the format ‘CVE-YYYY-NNNNN’. “YYYY” represents the year the CVE ID was assigned, or the vulnerability was made public, and “NNNNN” is a unique sequence number that can vary in length but is typically four or five digits.
For example, the CVE ID for Log4j vulnerability identified in 2021 is CVE–2021–44228, and the CVE ID for HTTP/2 Rapid Reset vulnerability identified in 2023 is CVE–2023–44487.
Why is CVE Important?
Imagine a case where two or more people are talking about a security vulnerability in a product, or two or more tools are articulating scan results. Before the existence of CVEs, there was no way of knowing if they were talking about the same vulnerability, or at least it will require a lot of manual work to find out if, in fact, they were talking about the same or a different vulnerability.
In the absence of a CVE, how would vendors communicate the patch information to customers to resolve a specific vulnerability in their product. Similarly, how would customers identify an appropriate patch for a vendor product that addresses a specific vulnerability in their system or know which vulnerabilities in their systems have been mitigated. This would result in a disjointed and inefficient approach to vulnerability management, increasing the risk of unresolved security vulnerabilities over time.
All this was prior to 1999 before the CVE Program had originated. The origin of a CVE Program had changed it all.
What is the CVE Program?
The CVE Program initiative had originated out of a need for a standardized system for sharing data about vulnerabilities. In its current form, the program is sponsored by the U.S. Department of Homeland Security (DHS) and the Cybersecurity and Infrastructure Security Agency (CISA) and maintained by the MITRE corporation.
The CVE Program’s mission is to identify, define, and catalogue publicly disclosed cybersecurity vulnerabilities. The program aims to standardize the way the information about security vulnerabilities is shared and addressed, making it easier for everyone involved in cybersecurity to communicate about and manage security threats.
The original concept of the CVE Program was presented by two visionaries from the MITRE Corporation in a seminal white paper titled Towards a Common Enumeration of Vulnerabilities back in January 1999. This seminal work marked the beginning of what would become the CVE List (a catalogue of all published CVE Records) that was officially launched to the public in September 1999. There is one CVE Record for each vulnerability listed in this catalogue, and the initial CVE List contained 321 CVE Records.
Growth in CVE Numbers
From its modest beginnings cataloguing a few hundred vulnerabilities, the cybersecurity community has endorsed the importance of CVE via “CVE-compatible” products and services. Following initial success of the program, CVE has witnessed exponential growth over the years, with the year 2023 alone recording over 28,000 vulnerabilities in the catalogue, as shown in the table below.
Source: cve.org — CVE Records published per year since 1999
A graphical representation of vulnerabilities published over years:
As we can see from above, there has been a big surge in the identified vulnerabilities in recent years. This surge in vulnerabilities may be attributed to several factors:
With a major focus on speed of innovation, we inadvertently introduce more vulnerabilities into the software we produce, resulting in an explosion of vulnerabilities.
The growing vigilance and participation of the cybersecurity community, whose collective efforts have brought to light an increasing number of vulnerabilities.
The digital transformation of society, where software has become ubiquitous, touching every aspect of our lives and, consequently, exposing us to an ever-expanding array of vulnerabilities.
CVE Program Management and Structure
Historically, MITRE populated CVE Records, however, this model was not scalable. Since 2016, the CVE Program has adopted a new federated growth strategy, incorporating new CVE Numbering Authority (CNA) to scale the program. This had led to a significant rise in the reported vulnerabilities in 2017, and the growth in reported vulnerabilities has continued consistently ever since, as is evident from the table and the graph above.
The decentralized approach significantly enhances CVE Program’s coverage, ensures timely and efficient CVE ID assignments by those most familiar with the affected products, bolstering CVE Program’s effectiveness in managing cybersecurity vulnerabilities.
At the time of this writing, the program has grown to have 365 CNAs from 40 countries around the world who have all participated to report over 220,000 CVE Records in the CVE catalogue. The CNAs include vendors, open-source, hosted services, bug-bounty providers, CERTs, researchers, and consortiums, who are authorized to assign CVE IDs and publish CVE Records for vulnerabilities within their distinct and agreed upon scope. The top technology companies, such as, Microsoft, Apple, Google, and others participate in this program. The full list of participating CNAs is available here.
Becoming a CNA is voluntary, however, the participants are required to meet certain minimum criteria to join the program, such as, having a public vulnerability disclosure policy, and agreeing to the CVE Program’s Terms of Use amongst others.
Source: cve.org — CVE program structure
The CVE Program has a hierarchical structure with the CVE Board on top overseeing the CVE Program operations and determining its strategic direction. The program structure also includes CVE Working Groups that are created and administered by the CVE board. There are seven working groups with distinct focus areas that help improve processes, workflows, and other aspects of the program as it continues to grow and expand.
Then we have Top-level Root (both CISA and MITRE) reporting to the CVE board, and managing their own Root, CNAs, and CNA-LR. The CNA-LR is a CNA of Last Resort who is authorized by a Root to assign CVE ID and publish the CVE Record within the Root’s scope for vulnerabilities that are not covered within the scope of another CNA.
This structured, yet flexible organization enables the CVE Program to adapt to the evolving cybersecurity landscape, promoting a collaborative approach to vulnerability management.
CVE Reporting Process
The CVE reporting process involves multiple steps to ensure that vulnerabilities are identified, documented, and communicated effectively.
The assignment of a unique CVE ID marks the first step in acknowledging a vulnerability. Once a new vulnerability is discovered, either by an individual or an organization, it is reported to the CVE Program participants (CNA) and a new CVE ID is requested. This CVE ID is then reserved against the reported vulnerability indicating that a formal record has been established. This helps with coordination and management of vulnerability between stakeholders; however, the details of the vulnerability are not yet made public.
Upon confirmation of the reported vulnerability through the identification of the minimum required data elements, the CVE Record is then published to the CVE List.
According to CVE.org, a CVE entry can be in one of the following three stages at any one time —
Reserved— As an initial step, a CNA reserves a CVE ID when a new vulnerability is discovered and reported.
Published— When a CNA populates the information associated with a CVE ID, the CVE Record gets published.
Rejected— If the CVE ID associated with a CVE Record should no longer be used, the CVE Record is put in a ‘Rejected’ state. The ‘Rejected’ CVE Record remains available on the CVE List so that the users can verify its status and know when it is invalid.
CVE.org has published the information requirements for a CVE Record that must include as a minimum, the affected products, affected or fixed version information, CVE ID, vulnerability type or root cause, and at least one public reference.
Source: CVE Record Lifecycle
CVE Records may be designated as ‘Disputed’ when there is a lack of consensus among involved parties on whether a specific issue or bug constitutes a security vulnerability. This label serves to inform readers, enabling them to determine whether the contested report poses a security risk to their organizational assets.
As a de facto international standard for vulnerability identification, CVE feeds crucial data into the US National Vulnerability Database (NVD), reinforcing its pivotal role in cybersecurity. Once a CVE Record becomes available to NVD, as a first step, the NVD assigns a CVSS score to the published CVE Record.
I will cover more on the role of NVD, highlighting its importance in the whole vulnerability management process in my upcoming article.
Update — Link to the article on NVD:
Is NVD Dead? RIP NVD!
*The Inception and Evolution of NVD, Current Challenges, Future of NVD, and the Way Forward for the Cybersecurity…*medium.com