CVE Usage of CVRF

CVE content can be downloaded in CVRF format on the Download CVE page. A single download of all CVE Entries in CVRF format is available, as are downloads for individual calendar years in CVRF format such as 2013, etc.

CVE Entries in CVRF Format

CVE uses Common Vulnerability Reporting Framework (CVRF) Version 1.1, which is maintained by the Industry Consortium for Advancement of Security on the Internet (ICASI).

Please note that because CVE itself does not provide a rich set of data fields, many of the elements that are defined in CVRF are not actually used. Since CVRF was designed to be flexible, it does not require many elements, which allows even CVE Entries limited data model to be represented.

Benefits over Other CVE-Provided Formats

CVE's CVRF implementation has the following features with advantages compared to other CVE-provided formats:

• The user can download the entire CVE List all at once, or download only the CVE Entries for a particular year. (Note that, as with all vulnerability data repositories (often referred to as vulnerability databases), CVE frequently adds or updates older entries from previous years.)

• Each CVE can record when it was initially published by the CVE Team, and when it was most recently modified by the CVE Team. This is the first time that the CVE Team has published this data authoritatively. Other dates as used in other formats do not provide the expected information. More details are below.

Header Information

The following CVRF elements appear near the top of the document and have special meaning within CVE data.

• DocumentTitle - The title includes the date on which the data was last generated.

• Date, InitialReleaseDate, CurrentReleaseDate - As of the initial release of CVE in CVRF, all of these dates reflect when the document was generated, in UTC date/time format. CVRF requires the InitialReleaseDate, which typically supports individual advisories that might be modified periodically. But for vulnerability data repositories (often referred to as vulnerability databases) such as CVE, there isn't really an "initial" release date, and modification of the database occurs on a constant basis.

• Identification - The ID element uses a CVE-style "timestamp" for the date and time on which the data was last generated, of the form "YYYYMMDD-hhmmss", with leading zeroes as necessary. This element can be used with simple string-comparison routines to automatically determine if one download file is more recent than another one.

• Version - This is yet another encoding of the date and time on which the file was generated. As required by CVRF, it is of the form "YYYY.MM.DD.hh" where "YYYY" is the year, "MM" is the month, "DD" is the day, and "hh" is the hour. Since CVRF 1.1 does not allow leading zeros in the Version element, the month and day can sometimes be a single digit. As a result, multiple documents cannot necessarily be sorted using the Version element, since "2013.3.4.5" (March 4, 2013, 5 AM) would sort AFTER "2013.12.1.20" (December 1, 2013, 8 PM) using common string-matching methods.

Individual Vulnerability Information

Each CVE entry has its own Vulnerability element.

• The Title element lists the CVE ID. (The Title is required by CVRF).

• The CVE Description is represented as a Note element whose Type attribute is "Description".

• A "Published" date is provided as follows. For some CVE Entries, data is provided about when the CVE Entry was initially published by the CVE Team (ignoring any preceding time when the CVE Entry may have been reserved.) This is implemented in a Note element whose Title is "Published". The element is of the form YYYY-MM-DD (year, month, date). Note that this data is not necessarily available or precise for older CVE Entries, especially those that were published before 2006. For issues before 2006, dates may be estimated based on Purdue's CVE Change Logs.
  
  Note that CVRF 1.1 does not support a per-Vulnerability publication date, which forces usage of the more-generic Note element. This limitation might be addressed in later CVRF versions.

• The date that the CVE Entry's Description or References were last modified is covered as a "Modified" date. For some CVE Entries, data is provided about when the CVE was last modified. This is implemented in a Note element whose Title is "Modified". The element is of the form YYYY-MM-DD (year, month, date). Note that this data is not necessarily available or precise for older CVE Entries. For entries that were active in November 2013 and earlier, dates may be estimated based on Purdue's CVE Change Logs.
  
  Note that CVRF 1.1 does not support a per-Vulnerability modification date, which forces usage of the more-generic Note element. This limitation might be addressed in later CVRF versions.

• The CVE element contains the CVE ID of the entry.

• The References element contains CVE's cross-references. There can be one or more Reference elements. Within a Reference element, the Description is used for the reference name (CVE-style "SOURCE:name"), and the URL element is used for the URL. Note that not all CVE references have URLs, but since CVRF 1.1 requires the URL element, it can sometimes be empty. Unlike other formats offered by CVE, the source (e.g., BUGTRAQ or CONFIRM) is not separately listed as an attribute. This is because CVRF 1.1 only allows for URL and Description elements when representing a reference. This limitation might be addressed in later versions.

• The Ordinal attribute of the Vulnerability element is intended by CVRF to help with sorting. For each CVE, its associated Ordinal value may change over time as different versions of download files are generated. In addition, the Ordinal value will not always start at 1 within a document.

Information Not Captured in CVRF

The following information is made available for historical purposes in other CVE data, but is not captured in CVRF:

• Status ("Candidate" or "Entry" type) - Since approximately 2005, there has been no functional difference between CVE "candidates" and "entries," since individual CVEs are no longer reviewed and approved by the CVE Board. This distinction was only useful for historical purposes. (See Why did CVE retire the term CVE "candidates"? for additional information.)

• Phase - For recent CVE IDs, the Phase is always "Assigned" with an associated date, but when candidates were actively distinguished from entries in earlier years, this Phase would change more often. Some sources appear to rely on the "Assigned" date, but its usage is almost always incorrect (see What does "Date Entry Created" signify in a CVE Entry? for additional information about assigned dates). This date only reflects when the number was first allocated by MITRE and rarely has any close relationship with when the issue was discovered or first made public, or when the ID was privately linked with an issue before publication. Due to extensive misunderstanding and misuse of this field, it is intentionally being omitted. However, the "Published" and "Modified" Note elements should provide the desired data.

• Votes - This field was only populated in 2005 and earlier, and only for candidates that had not been promoted to official entries or otherwise rejected. Since individual CVE Entries are no longer reviewed and approved by the CVE Board, this data is at best historical.

Potential CVRF Enhancements for Vulnerability Repositories

CVRF 1.1 and earlier was primarily developed to support publication of individual advisories that only contain a small number of vulnerabilities, such as vendor security announcements. After CVRF 1.0 was released, CVE personnel provided feedback to ICASI (the CVRF maintainer) to ensure that CVRF 1.1 would be better able to handle large vulnerability data repositories (often referred to as vulnerability databases). While CVRF 1.1 contains significant improvements based partly on this feedback, CVE's implementation has highlighted additional limitations, some of which are covered earlier in this document.

Suggestions for improvement will be sent to ICASI and to other maintainers of vulnerability data repositories (often referred to as vulnerability databases) upon request, so that future versions of CVRF could improve support for large vulnerability data repositories such as CVE.

Please send all comments and concerns to cve@mitre.org.