Releases: CVEProject/cve-schema
CVE Record Format version 5.1.1
Changes in CVE Record Format 5.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 CNA 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.
-
Example CVE Records (in docs) have been updated to use CVE-1900-xxxx example IDs.
CVE JSON producing tools or CVE client implementation considerations:
✅ If a tool is producing CVE 5.1.0 Records then no changes to client-side tooling are required. However, it is recommended to upgrade to the CVE Record Format 5.1.1 to support the new features listed above.
CVE data consumer considerations:
✅ If a CVE data consumer is not validating the JSON data against the CVE Record Format schema, then no changes are required to the consumer side code.
CVE Record Format version 5.1.1 Release Candidate 2
Changes in CVE Record Format 5.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 CNA 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.
-
Example CVE Records (in docs) have been updated to use CVE-1900-xxxx example IDs.
CVE JSON producing tools or CVE client implementation considerations:
✅ If a tool is producing CVE 5.1.0 Records then no changes to client-side tooling are required. However, it is recommended to upgrade to the CVE Record Format 5.1.1 to support the new features listed above.
CVE data consumer considerations:
✅ If a CVE data consumer is not validating the JSON data against the CVE Record Format schema, then no changes are required to the consumer side code.
CVE Record Format version 5.1.1 Release Candidate 1
Changes in CVE Record Format 5.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 CNA 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.
-
Example CVE Records (in docs) have been updated to use CVE-1900-xxxx example IDs.
CVE JSON producing tools or CVE client implementation considerations:
✅ If a tool is producing CVE 5.1.0 Records then no changes to client-side tooling are required. However, it is recommended to upgrade to the CVE Record Format 5.1.1 to support the new features listed above.
CVE data consumer considerations:
✅ If a CVE data consumer is not validating the JSON data against the CVE Record Format schema, then no changes are required to the consumer side code.
CVE Record Format version 5.1.0
Changes in CVE Record Format 5.1.0:
-
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.
-
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.
-
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.
-
Other changes include: Added clarity to multiple field definitions in the schema, improved examples and bugs in schema syntax.
-
Name Change: The CVE JSON schema is now the CVE Record Format.
-
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:
Suggested solution: Please remove the extra fields or fix the field names to resolve this error.
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.
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.
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:
-
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.
-
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.
-
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.
-
Other changes include: Added clarity to multiple field definitions in the schema, improved examples and bugs in schema syntax.
Compatibility considerations:
Suggested solution: Please remove the extra fields or fix the field names to resolve this error.
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.
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.
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