Release 2020-06-03

2020-06-03 updated data

2019-05-14 Updated data

2018-11-06 Updated data

2018-01-30 Updated data

2017-11-08 Updated data. Sorted JSON keys so future updates should diff more cleanly in git commit logs.

2017-03-30 Updated data. Some more CVSS scores backfilled.

2016-11-03 Updated data. Backfilled "Not Defined" values for many vulnerabilities' CVSS scores.

2016-06-24 Changed search URL, sponsorship, added GitHub migration, no change to data

2016-03-30 Updated data

2014-12-08 Updated data, note significant number of nearly identical reports associated with automated Android SSL testing

2014-05-22 Updated data

2013-11-20 Updated data

2013-04-03 Updated data, added field definition for [DateCreated], fixed 8-bit characters in section 8

2012-07-10 Initial release

This data archive contains nearly all of the non-sensitive vulnerability data collected by CERT, from the inception of the vulnerability notes database (approximately May 1998) to the date the archive was prepared, as noted above in the Change Log.

Since roughly 2004, the United States Department of Homeland Security (DHS) United States Computer Emergency Readiness Team (US-CERT) and other government sponsors have funded the vulnerability analysis and coordination work that includes this vulnerability data and the publication of Vulnerability Notes.

This data is incomplete. All records (reports) should have an ID, title, and creation date. Only some (~6%) of the reports have been analyzed, coordinated, written up, and published as Vulnerability Notes.

Most of the reports are in a preliminary state, with blank or default field values. Few fields are consistently entered across the entire data set. It is generally inappropriate from an analysis perspective to draw conclusions from incomplete and inconsistent data. You have been warned.

There are two sets of data, vulnerability reports and vendor records. A published Vulnerability Note is made up of one vulnerability report and one or more vendor records.

In this document, field names are enclosed in square brackets, like this: [FieldName].

Vulnerability reports describe information about a reported vulnerability. A report may contain 0 or more vulnerabilities. CERT typically attempts to have one vulnerability report per vulnerability, but this isn't always a practical level of abstraction. [VulnerabilityCount] is the number of vulnerabilities (per CERT's definition) in a vulnerability report.

Vulnerability reports have 0 or more associated vendor records. Vendor records describe vendor information related to a vulnerability report. A record is typically created when CERT notifies a vendor about a vulnerability, reasonably believes the vendor may be affected, becomes aware of information about the vendor related to the vulnerability, or otherwise feels that there is relevant information about the vendor related to the vulnerability.

See https://github.com/CERTCC-Vulnerability-Analysis/Vulnerability-Data-Archive-Tools for some python tools to get you started with using this data.

Did you find something interesting in the data? Did you come up with some cool way of slicing it or remixing it and you want to share? You can tweet us @certcc.

If you find a problem with the data or the tools, please create an issue report in the appropriate repository. Please be aware though that we offer no formal support, however we may respond to questions and feedback submitted as issues in this project.

The data in this repository has been transformed from the data found at http://www.cert.org/download/vul_data_archive/. That data set contains archives raw exports of the CERT Vulnerability Notes database. The Vulnerability Notes Database is a Lotus Notes application, and the raw JSON and XML exports in the original archive can be difficult to work with. In this repository we've converted the JSON data to more conventional key-value pairs to make it easier to use.

The directory structure is as follows:

• ./data/ contains the entire data set.
• Below that, ./data/0/ through ./data/99/ contain subdirectories for individual vulnerability reports. A vulnerability report can be found by taking the VU#NNNNN ID modulo 100. (I.e., the last two digits of the VU#, so VU#123456 would be in ./data/56/)
• Individual vulnerability report directories ./data/56/vu_123456/ should contain exactly one vu_*.json file and 0 or more vendor_*.json files.
• vu_*.json files contain data as described in Field Definitions for Vulnerability Reports
• vendor_*.json files contain data as described in Field Definitions for Vendor Records

In the Lotus Notes application from which this data was exported, s\Some fields are initially created as text and the field type is updated only once data has been entered. For example, a datetime field that is blank may appear as a text field.

Descriptions for fields included in published Vulnerability Notes are also available here.

Some of the fields in this archive are not included in published Vulnerability Notes.