CVE Vendor Product File Format for a CVE Vulnerabilities File

[okeuday]

Proposed New Idea/Feature (required)

Please provide a "Vendor Product File Format" for use on a vendor's website, to clearly publish past product vulnerabilities in a way that is easy to read and parse for automated use. The goal described here is to provide a simple standard way of providing data similar to the webpage https://www.openssl.org/news/vulnerabilities.html (i.e., an example of the data in HTML format).

A CSV or JSON standard format would be a good alternative to the example in HTML to ensure the HTML doesn't require web scraping for automated use (which is prone to breakage as the HTML changes). The important fields that must be present are:

• CVE ID (in the format listed in http://cve.mitre.org/cve/identifiers/syntaxchange.html#new )
• severity (with CVSS v3.0 Ratings values CRITICAL, HIGH, MEDIUM, LOW defined at https://nvd.nist.gov/vuln-metrics/cvss )
• version_since
• version_fix
• description

The file should be named "vulnerabilities" in any language and can be referred to as a "CVE Vulnerabilities File". The version_since is used instead of version_affected (described at https://github.com/CVEProject/automation-working-group/blob/master/cve_json_schema/DRAFT-JSON-file-format-v4.md ) to ensure versions can be checked easily and affected version data entry errors are avoided. Both version_since and version_fix are version values, as used by the vendor for the product. Each entry in the vulnerabilities file is an indication of a CVE that was fixed (based on the information available at the time the vulnerabilities file was updated).

Additional Notes (Optional)

The reason for proposing this idea is due to a desire to make it simple to consume authoritative CVE data. The intent is to have these vulnerabilities files always hosted by the vendor as part of their commitment to providing accurate CVE version information (which assumes correct DNS lookup and TCP/IP routing). The automated consumption of a vulnerabilities file would be used to identify current security threats based on the current runtime version of the vendor's product.

An example of the process of using a vulnerabilities file would be similar to what is currently done by the PEST (Primitive Erlang Security Tool) which currently web scrapes the HTML example with ./pest.erl -U crypto and outputs the relevant vulnerabilities with ./pest.erl -V crypto. A separate command-line option could be added that only provides an exit status of 0 if no vulnerabilities exist with the current installation version(s) and there hasn't been any error processing vulnerabilities file data (to allow automated checking of the current installation).

[zmanion]

This is a great idea and something that has been worked on in different ways for many years. It is IMO something bigger than CVE and outside of our scope. We do recommend (possibly require) that suppliers publish advisories (or some form of documentation) for CVE IDs they assign, but developing and requiring a format (and discovery/exchange mechanisms) that works for all suppliers turns out to be a hard problem.