Skip to content

CVE Record Format version 5.1.0

Latest
Compare
Choose a tag to compare
@ccoffin ccoffin released this 09 May 21:05
30f59c7

Changes in CVE Record Format 5.1.0:

  1. Enable versionType field to be used for single instances of a product version.

    • This allows identifying products associated with the vulnerability for hardware identifiers eg., UPC, GTIN, GMN, Package URLs, SKUs.
  2. Prevent typos in optional field names.

    • This ensures typos in field names or misplaced fields in CVE record are identified prior to a record's acceptance by the services.
    • Prevents unexpected fields in the CVE Record.
  3. Add support CVSS v4.0 object.

    • Add support for optional CVSS 4.0 object under metrics. In addition to a numerical score and a qualitative severity rating, a CVSS 4.0 provides several new attributes related to the vulnerability that include urgency, safety impact, and effort required to respond to the vulnerability.
  4. Other changes include: Added clarity to multiple field definitions in the schema, improved examples and bugs in schema syntax.

  5. Name Change: The CVE JSON schema is now the CVE Record Format.

  6. Repo structural changes: The schema files were moved up to the schema root directory and all older schema versions were placed into an archive directory at the same level.

Compatibility considerations:

⚠️ A refresh of some local installations of JSON validation software could result in many CVE Records having validation errors because of a code change within some JSON validation Open Source supply chains. You may need to revert to the earlier version of the JSON validation software if this occurs.

⚠️ A CVE 5.0 record may fail validation with the 5.1.0 schema if it contains unexpected extra fields or if field names have typos.
Suggested solution: Please remove the extra fields or fix the field names to resolve this error.

⚠️ A CVE 5.1 record may fail validation with the 5.0.0 schema if it contains additional data such a CVSS v4 object, or a versionType associated with a single version.
Suggested solution: Please use the 5.1.0 schema to perform the validation.

As of Nov 6th about 287 (about 0.12%) of existing CVE Records are not compliant to CVE-JSON 5.1.0 specification due to presence of typos, or extra fields. Full list is at https://cveproject.github.io/quality-workgroup/report-5.1.0 for potential CNA tooling problems.

CVE JSON producing tools or CVE client implementation considerations:

✅ If a tool is producing a CVE 5.0.0 record that also validate with the CVE 5.1.0 schema, then no changes to client side tooling are required.

⚠️ If a tool is producing a CVE 5.0.0 record that fails validation with the CVE 5.1.0 schema, then appropriate fixes are required to ensure uninterrupted use of CVE services. Please check https://cveproject.github.io/quality-workgroup/report-5.1.0

⚠️ If a CVE services client if performing schema validation prior to submission, please use the 5.1.0 schema to validate the record.

CVE data consumer considerations:

✅ If a CVE data consumer is not validating the JSON data against the schema, then no changes may be required to consumer side code.

⚠️ If a CVE data consumer is validating the JSON data against the 5.0.0 schema, then please use the 5.1.0 schema to validate records.

Fixes since RC1:

Relax dataVersion to be a semver starting with 5
Refactor bundling to remove version from the file name.
Add flattened CNA container published, rejected schemas to help services adoption or clients submitting container objects to services.
Added example of rejected CNA container object.