CVE Record Format version 5.1.1 Release Candidate 1

Changes in CVE Record Format 5.1.1:

1. Add new and expanded support for Common Platform Enumeration (CPE) Identifiers using the CPE Applicability Language.

   • Both CNA and ADP containers support a new cpeApplicability block that allows one or more CPE Identifier Names, CPE Match Strings, or CPE Match String Ranges to be defined.
   • The cpeApplicability block is optional. If provided, it is recommended that the CVE Record author ensure that the data provided matches as closely as possible to the product data provided within the affected block.
   • The syntax and format of the cpeApplicability block matches that used by the NIST NVD CVE API JSON v2.0 schema (configurations). NOTE: The “matchCriteriaId” property is optional in the CVE Record Format.
   • The new cpeApplicability block supports CPE 2.3 names only.

2. Example CVE Records (in docs) have been updated to use CVE-1900-xxxx example IDs.

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.

CVE JSON producing tools or CVE client implementation considerations:

✅ If a tool is producing a CVE 5.1.0 record that also validates with the CVE 5.1.1 CVE Record Format, then no changes to client-side tooling are required. However, it is recommended to upgrade to the 5.1.1 CVE Record Format to support the new features listed above.

⚠️ If a tool is producing a CVE 5.0.0 or 5.1.0 record that fails validation with the CVE 5.1.1 CVE Record Format, 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 is 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 are required to the consumer side code.

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

CVE Record Format version 5.1.0

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.

CVE JSON Record Format version 5.1.0 Release Candidate 2

Changes in CVE JSON 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.

Compatibility considerations:

⚠️ 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.

CVE JSON Record Format version 5.1.0 Release Candidate 1

Add CVSS v4.0 support.
Bump minor version to 5.1

v5.0.1-test: Merge pull request #245 from kernelsmith/patch-1

Ignore this release.

CVE JSON Record Format version 5.0.1 Release Candidate 1

Bug fixes and improved schema definitions, descriptions.
Prevent misplaced or typo in field names using additionalProperties set to false in objects that do not expect them.
Allow VersionType for single versions.

CVE JSON Record Format 5.0.0

Final published version of CVE JSON 5.0.0 schema.
Docs: https://cveproject.github.io/cve-schema/schema/v5.0/docs/
Mindmap: https://cveproject.github.io/cve-schema/schema/v5.0/docs/mindmap.html

CVE JSON Record Format version Release Candidate 8

#174 Fix 5.0 Schema timestamp regexp bug causing incorrect validations

CVE JSON Record Format version Release Candidate 7

• Change the regex for CWE-ID to accept one digit CWE IDs.
• Don’t allow dots in additional property field names that start with x_

CVE JSON Record Format version Release Candidate 6

• Changed some minLength, maxLnegth values
• Updated some descriptions
• Fixed a typo in schema definition