CVE Candidates Explained

Introduction

CVE Identifiers with candidate status—also called “Candidates”—are those vulnerabilities or exposures under consideration for acceptance into CVE. Each CVE Identifier has the following items associated with it: (1) CVE Identifier number (i.e., "CVE-1999-0067"); (2) indication of "entry" or "candidate" status; (3) a brief description of the security vulnerability or exposure; and (4) any pertinent references (i.e., vulnerability reports and advisories or OVAL-ID).

If the candidate is accepted, it is entered into CVE and is published via the site. However, the assignment of a candidate number is not a guarantee that it will become an official CVE entry.

From New Security Issue to CVE Candidate

Candidates get assigned to specific issues in two different ways:

(1) Data Sources — In most cases, MITRE assigns candidate numbers to issues that have already been publicized (e.g., on Bugtraq or in a security advisory) but have not been assigned a candidate number by a Candidate Numbering Authority. In these instances, we rely on other data sources to "feed" us with vulnerability information that they regularly collect and summarize.

We collect and integrate the information from these multiple sources, and create candidates from them. As a result of this process, it takes a minimum of two weeks after the initial public announcement of the problem before the candidates become available to the public. (Our data sources publish their summaries once a week, then it takes us at least a week to process their summaries.)

(2) Candidate Numbering Authorities (CNAs) — Organizations or individuals "reserve" candidate numbers from MITRE, the Primary CNA, for issues that have not yet been publicized. These entities, called CNAs, then include the candidate number in their initial public announcement. As such, the candidate number is immediately available. The CVE Initiative is working to do this more regularly across the industry. One effort involves providing "blocks" of candidates to key parties (like CERT/CC or major operating system vendors like Microsoft). These CNAs can then assign the candidates to incoming issues, independently of MITRE. This addresses some other concerns besides timing, but it requires that the CNAs know how to assign the proper number of candidates, and it also requires close coordination across all parties. (See also Organizations Participating as CNAs and how to Obtain a CVE Identifier.)

Once a candidate has been created and assigned to a specific issue, it is proposed to the CVE Editorial Board. Board members review and vote on the candidates. In general, at least three Board members must "accept" the candidate before it can be promoted to an official CVE entry.

From Candidate to CVE Entry

In general it takes one day to one month to assign a candidate number, and six months to a year for the typical candidate to become an official CVE entry. The review process by the Editorial Board allows a minimum of two weeks from proposal to final acceptance and conversion to an official CVE entry. However, this only happens in certain relatively rare circumstances when the candidate identifies a well-known issue that has been publicly acknowledged by the vendor.

If the candidate is for an obscure issue, or Board members do not have a minimum level of confidence that the reported issue is real, then it can take months or even years before enough Board members cast the required number of "accept" votes. Some candidates may never obtain enough accept votes, but they may not be inaccurate either; these situations are currently handled by the CVE Editor. In addition to its role as Primary CNA, MITRE also functions as the CVE Editor.

During the review process for candidates, an Editorial Board member may find a possible inconsistency or ask a question that requires more detailed research. This can delay a candidate further while the questions are dealt with since some questions are, technically speaking, very difficult to answer. Some candidates may also be further delayed by certain CVE "editorial policies" (see below).

We currently release new CVE versions about once per year. This simplifies maintenance for people who maintain CVE-compatible databases, products, and services. These new versions are announced on the News and Events page and in our free e-newsletter, "CVE-Announce."

Impact of CVE Editorial Policies

CVE Editorial Policies, also called Content Decisions (CDs), are the criteria and consistency rules that determine (a) what security issues become CVE candidates for eventual inclusion in the CVE List, and (b) how we distinguish between similar or related security issues.

Generally, the CVE approach is to create separate candidates for:

(1) vulnerabilities of different types

(2) vulnerabilities of the same type that appear in different versions

(3) vulnerabilities that appear in different codebases (i.e., "by vendor;" however, this also includes vendors who share the same code such as Linux/Unix vendors)

CDs are difficult to document and formalize, partially because of the variety and complexity of vulnerabilities, and partially because of the variety and quality of available information. In effect, CDs also represent areas in which security experts may differ on the proper way of distinguishing between security issues. As a result of these factors, CDs can also change over time. Since CDs directly affect which issues go into CVE and how they are "counted," it is important that CDs be stable before an issue can be promoted to an official CVE entry. As such, if a candidate is affected by an incomplete or unverified CD, it will not be accepted as an official entry until the CD is stable—even if it has enough "accept" votes.

While we have stabilized some CDs, others have not received sufficient discussion and verification. This is especially the case with respect to configuration problems, which are not well-studied in the community in general, and are often areas of sharp disagreement between CVE Editorial Board members (for example, some reported configuration errors fall in the area of "best practices," which some members do not think belong in CVE; also, there is wide variety in how people "count" configuration errors). The instability of content decisions is one of the biggest factors in the delays of certain candidates. But as we further stabilize CDs that will allow a number of candidates to be promoted to official entries. See CVE Editorial Policies for additional information and examples of this process.

For detailed information about CDs, and theoretical and real-world examples, refer to the CVE Editorial Policies section of the CVE Web site.

Monitoring the Newest Candidates

A tool from CERIAS/Purdue University monitors changes to the CVE List, including candidates. "CVE Change Logs" allows you to obtain daily or monthly additions and changes to CVE List. The tool is a feature of CERIAS' Cassandra incident response database service, which is listed on the CVE-Compatible Products and Services page. CERIAS/Purdue University is also a member of the CVE Editorial Board.