CVE - CVE Content Decisions Overview (Archived)

CVE Content Decisions Overview (Archived)

IMPORTANT: This page has been archived. Please see the CVE Numbering Authority (CNA) Rules for the most current information.

CVE content decisions (CDs) are the guidelines used to ensure that CVE Identifiers are created in a consistent fashion, independent of who is doing the creation. There are two major types of CDs: Inclusion and Abstraction.

Inclusion Content Decisions - specify whether a vulnerability or exposure should go into CVE.
Abstraction Content Decisions - specify what level of abstraction (level of detail) a vulnerability should be described at, e.g., whether a particular security issue should be given one CVE Identifier or five CVE Identifiers (see CVE Abstraction Content Decisions: Rationale and Application for detailed information).

There are differences between many vulnerability databases or products in the type of content they include, as well as the level of abstraction. These differences occur within the same database or product. Because of this variety and the flat structure of the CVE Identifier, CVE cannot be flexible enough to account for these differences. It is important for vulnerability analysts to be aware of these differences. As such, CVE CDs not only document the guidelines for creating content, they often indicate areas in which there is inconsistency across vulnerability information sources. Quantitative analyses of vulnerabilities that use CVE-normalized data can be more easily replicated, and the CVE CDs help to ensure that the data is normalized in a predictable fashion.

The Two Most Commonly Used Content Decisions

Two of the most commonly used abstraction facets of CVE CDs are shown in the example below. They also highlight some of the most common discrepancies across vulnerability information sources. These CDs were revised many times over a period of a year and a half, but they were stabilized in early 2001 when they were modified to make them less sensitive to the amount of information that is available for a vulnerability. From an academic perspective this approach is not optimal, but it is proving to be repeatable and less likely to cause CVE Identifiers to become split or merged when new information becomes available after the initial analysis has been performed.

Examples of SF-LOC and SF-EXEC Abstraction Facets

CD:SF-LOC: multiple security flaws in the same executable, but possibly in different lines of code	CD:SF-EXEC: multiple executables exhibiting the same problem
CD:SF-LOC only applies when there may be multiple bugs that appear in the same executable (modulo the codebase, i.e., all "ps" executables in UNIX are treated as the same). SPLIT (create separate CANs) between problems of different types (e.g., buffer overflow versus symlink problem). SPLIT between problems of the same type if problem X appears in some version that problem Y does not. MERGE problems of the same type within the same version. Explicitly list the different problems in the description.	CD:SF-EXEC only applies when there are multiple executables in the same package that demonstrate the same problem. "The same package" basically means "bundled executables that perform related functions that are not distributed separately." Microsoft Word and PowerPoint are not the same package (they can be installed separately). The set of executable programs that support the lpd capability in UNIX are the same package. SPLIT when the problems are of different types. SPLIT when the problems are in different versions (for some definition of "version" that effectively describes the package). MERGE when the problems are of the same type. Explicitly identify the separate affected "components" or executables in the package.

CD:SF-LOC: multiple security flaws in the same executable, but possibly in different lines of code

CD:SF-EXEC: multiple executables exhibiting the same problem

CD:SF-LOC only applies when there may be multiple bugs that appear in the same executable (modulo the codebase, i.e., all "ps" executables in UNIX are treated as the same).
SPLIT (create separate CANs) between problems of different types (e.g., buffer overflow versus symlink problem).
SPLIT between problems of the same type if problem X appears in some version that problem Y does not.
MERGE problems of the same type within the same version. Explicitly list the different problems in the description.

CD:SF-EXEC only applies when there are multiple executables in the same package that demonstrate the same problem.
"The same package" basically means "bundled executables that perform related functions that are not distributed separately." Microsoft Word and PowerPoint are not the same package (they can be installed separately). The set of executable programs that support the lpd capability in UNIX are the same package.
SPLIT when the problems are of different types.
SPLIT when the problems are in different versions (for some definition of "version" that effectively describes the package).
MERGE when the problems are of the same type. Explicitly identify the separate affected "components" or executables in the package.

CD:SF-LOC is less sensitive to the lack of detailed information such as source code, exploits, or attack traces. However, it is still sensitive to changes in version information. Problems that occur in libraries pose special challenges for this CD, because they could be exhibited at several points within the same executable, or in many different executables. Ultimately, while this CD is intended to minimize the amount of information that is required to produce results, it is still dependent on critical information sources such as the vendor of the vulnerable product.

CD:SF-EXEC is also susceptible to error if the problem occurs in a library or other common codebase.