From 05ece545303329b9715d8932d863ba6d233a0b17 Mon Sep 17 00:00:00 2001 From: Andrew Lilley Brinker Date: Thu, 21 Aug 2025 14:24:51 -0700 Subject: [PATCH 1/9] chore: remove unused `datestamp` type This is a type defined in the schema but never actually used. As such, its removal doesn't break anything. Fixes: https://github.com/CVEProject/cve-schema/issues/353 Fixes: https://github.com/CVEProject/cve-schema/issues/288 Signed-off-by: Andrew Lilley Brinker --- schema/CVE_Record_Format.json | 6 ------ 1 file changed, 6 deletions(-) diff --git a/schema/CVE_Record_Format.json b/schema/CVE_Record_Format.json index fde05ad5962..9d18b85266d 100644 --- a/schema/CVE_Record_Format.json +++ b/schema/CVE_Record_Format.json @@ -82,12 +82,6 @@ "minLength": 2, "maxLength": 32 }, - "datestamp": { - "description": "Date/time format based on RFC3339 and ISO ISO8601.", - "type": "string", - "format": "date", - "pattern": "^((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30))$" - }, "timestamp": { "type": "string", "description": "Date/time format based on RFC3339 and ISO ISO8601, with an optional timezone in the format 'yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM'. If timezone offset is not given, GMT (+00:00) is assumed.", From fd35d36d943308aeea1ef67f3d4edfe4f3ece841 Mon Sep 17 00:00:00 2001 From: Andrew Lilley Brinker Date: Thu, 21 Aug 2025 14:40:36 -0700 Subject: [PATCH 2/9] feat: make timestamp tz mandatory and remove sub-seconds Sub-seconds are a level of fidelity beyond what's needed for CVE Records, and in practice are rarely used. Timezones are essential for correctly interpreting time data, and rather than defaulting to a (likely wrong) assumption that without a timezone a timestamp is in UTC (or GMT) we should require timezones at submission. Fixes: https://github.com/CVEProject/cve-schema/issues/353 Fixes: https://github.com/CVEProject/cve-schema/issues/314 Fixes: https://github.com/CVEProject/cve-schema/issues/289 Signed-off-by: Andrew Lilley Brinker --- schema/CVE_Record_Format.json | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/schema/CVE_Record_Format.json b/schema/CVE_Record_Format.json index 9d18b85266d..cf9aed75788 100644 --- a/schema/CVE_Record_Format.json +++ b/schema/CVE_Record_Format.json @@ -84,8 +84,11 @@ }, "timestamp": { "type": "string", - "description": "Date/time format based on RFC3339 and ISO ISO8601, with an optional timezone in the format 'yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM'. If timezone offset is not given, GMT (+00:00) is assumed.", - "pattern": "^(((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30)))T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])(\\.[0-9]+)?(Z|[+-][0-9]{2}:[0-9]{2})?$" + "description": "Date/time format based on RFC3339 and ISO ISO8601, with a mandatory timezone in the format 'yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM'.", + "pattern": "^(((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30)))T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])(Z|[+-][0-9]{2}:[0-9]{2})$", + "examples": [ + "2025-01-04T12:01:01+05:30" + ] }, "version": { "description": "A single version of a product, as expressed in its own version numbering scheme.", @@ -1075,7 +1078,6 @@ ], "properties": { "time": { - "description": "Timestamp representing when the event in the timeline occurred. The timestamp format is based on RFC3339 and ISO ISO8601, with an optional timezone. yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM - if the timezone offset is not given, GMT (+00:00) is assumed.", "$ref": "#/definitions/timestamp" }, "lang": { From 5b28e7ea5aa95907c079da77548a80559f2157b1 Mon Sep 17 00:00:00 2001 From: Andrew Lilley Brinker Date: Thu, 21 Aug 2025 14:50:56 -0700 Subject: [PATCH 3/9] chore: Update schema description This amends the schema's own self-description to be clearer. Signed-off-by: Andrew Lilley Brinker --- schema/CVE_Record_Format.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/schema/CVE_Record_Format.json b/schema/CVE_Record_Format.json index cf9aed75788..2ccfcca3a26 100644 --- a/schema/CVE_Record_Format.json +++ b/schema/CVE_Record_Format.json @@ -2,7 +2,7 @@ "$schema": "http://json-schema.org/draft-07/schema#", "$id": "https://cveproject.github.io/cve-schema/schema/CVE_Record_Format.json", "title": "CVE JSON record format", - "description": "cve-schema specifies the CVE JSON record format. This is the blueprint for a rich set of JSON data that can be submitted by CVE Numbering Authorities (CNAs) and Authorized Data Publishers (ADPs) to describe a CVE Record. Some examples of CVE Record data include CVE ID number, affected product(s), affected version(s), and public references. While those specific items are required when assigning a CVE, there are many other optional data in the schema that can be used to enrich CVE Records for community benefit. Learn more about the CVE program at [the official website](https://www.cve.org). This CVE JSON record format is defined using JSON Schema. Learn more about JSON Schema [here](https://json-schema.org/).", + "description": "The CVE Record Format is the blueprint for a rich set of JSON data that can be submitted by CVE Numbering Authorities (CNAs) and Authorized Data Publishers (ADPs) to describe a CVE Record. Some examples of CVE Record data include CVE ID number, affected product(s), affected version(s), and public references. While those specific items are required when assigning a CVE, there are many other optional data in the schema that can be used to enrich CVE Records for community benefit. Learn more about the CVE program at [the official website](https://www.cve.org). This CVE JSON record format is defined using JSON Schema. Learn more about JSON Schema [here](https://json-schema.org/).", "definitions": { "uriType": { "description": "A universal resource identifier (URI), according to [RFC 3986](https://tools.ietf.org/html/rfc3986).", From 597146c5cfa394ab549c71fcd21c5139d682d760 Mon Sep 17 00:00:00 2001 From: Andrew Lilley Brinker Date: Thu, 21 Aug 2025 14:53:50 -0700 Subject: [PATCH 4/9] feat: Add "preformatted" bool to descriptions. Adds a boolean field to indicate when a description is preformatted, meaning its formatting should be preserved when it is displayed, if possible. Fixes: https://github.com/CVEProject/cve-schema/issues/341 Signed-off-by: Andrew Lilley Brinker --- schema/CVE_Record_Format.json | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/schema/CVE_Record_Format.json b/schema/CVE_Record_Format.json index 2ccfcca3a26..0b49fc706de 100644 --- a/schema/CVE_Record_Format.json +++ b/schema/CVE_Record_Format.json @@ -832,6 +832,10 @@ ], "additionalProperties": false } + }, + "preformatted": { + "type": "boolean", + "description": "If true, indicates the 'description' is preformatted text that should be rendered to preserve spacing and other formatting. If false, will be rendered without preserving formatting." } }, "required": [ From dce16b3885a3829e1e07a26b8260b3dd04eda9cd Mon Sep 17 00:00:00 2001 From: Andrew Lilley Brinker Date: Thu, 21 Aug 2025 15:00:29 -0700 Subject: [PATCH 5/9] feat: fill out "source" field, adapted from Vulnogram This fills out the previously-broken "source" field, which was intended to be adapted from Vulnogram, by completing the adaptation. See: https://github.com/Vulnogram/Vulnogram/blob/de7a77c20d849222f748922c55a5c2bc3503e14c/default/cve5/cve5.schema.json#L3180-L3250 Fixes: https://github.com/CVEProject/cve-schema/issues/339 Fixes: https://github.com/CVEProject/cve-schema/issues/317 Signed-off-by: Andrew Lilley Brinker --- schema/CVE_Record_Format.json | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/schema/CVE_Record_Format.json b/schema/CVE_Record_Format.json index 0b49fc706de..1f9416ca78c 100644 --- a/schema/CVE_Record_Format.json +++ b/schema/CVE_Record_Format.json @@ -1147,7 +1147,38 @@ "source": { "type": "object", "description": "This is the source information (who discovered it, who researched it, etc.) and optionally a chain of CNA information (e.g. the originating CNA and subsequent parent CNAs who have processed it before it arrives at the MITRE root).\n Must contain: IF this is in the root level it MUST contain a CNA_chain entry, IF this source entry is NOT in the root (e.g. it is part of a vendor statement) then it must contain at least one type of data entry.", - "minProperties": 1 + "minProperties": 1, + "properties": { + "defect": { + "title": "Defects", + "type": "array", + "description": "CNA specific bug or defect tracking IDs (optional).", + "uniqueItems": true, + "items": { + "type": "string", + "maxLength": 64 + } + }, + "advisory": { + "title": "Advisory ID", + "type": "string", + "description": "CNA specific advisory IDs (optional).", + "maxLength": 64 + }, + "discovery": { + "type": "string", + "title": "Source of vulnerability discovery", + "enum": [ + "INTERNAL", + "EXTERNAL", + "USER", + "UPSTREAM", + "UNKNOWN" + ], + "description": "Source of vulnerability discovery. This may be a factor for some consumers in prioritizing vulnerability response. \nINTERNAL: this vulnerability was found by the CNA's internal research.\nEXTERNAL: this vulnerability was found during research external to a CNA.\nUSER: This vulnerability was discovered during product use.\nUPSTREAM: This vulnerability was found by an upstream vendor or producer.\nUNKNOWN: Source of discovery is not defined or is unknown", + "default": "UNKNOWN" + } + } }, "language": { "type": "string", From 104bba64d81342c9350a3de2b8f27177e3c6beed Mon Sep 17 00:00:00 2001 From: Andrew Lilley Brinker Date: Thu, 21 Aug 2025 15:04:41 -0700 Subject: [PATCH 6/9] feat: require more date information on records. There are currently several date fields which are filled out by CVE Services generally, but which aren't officially required, and where some records slip through which do not include them. Fixes: https://github.com/CVEProject/cve-schema/issues/334 Signed-off-by: Andrew Lilley Brinker --- schema/CVE_Record_Format.json | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/schema/CVE_Record_Format.json b/schema/CVE_Record_Format.json index 1f9416ca78c..676ad0f53db 100644 --- a/schema/CVE_Record_Format.json +++ b/schema/CVE_Record_Format.json @@ -382,7 +382,9 @@ "required": [ "cveId", "assignerOrgId", - "state" + "state", + "datePublished", + "dateReserved" ], "properties": { "cveId": { @@ -432,7 +434,9 @@ "required": [ "cveId", "assignerOrgId", - "state" + "state", + "datePublished", + "dateReserved" ], "properties": { "cveId": { @@ -655,7 +659,8 @@ "providerMetadata", "descriptions", "affected", - "references" + "references", + "datePublic" ], "patternProperties": { "^x_[^.]*$": {} From b7bfb61420af847c709ec9f6a4c4c16691f0e12d Mon Sep 17 00:00:00 2001 From: Andrew Lilley Brinker Date: Thu, 21 Aug 2025 15:32:15 -0700 Subject: [PATCH 7/9] chore: correct Markdown formatting in `versions.md` This updates the Markdown formatting of `versions.md` to correctly follow the Markdown spec, including correct spacing of lists. It also wraps all code blocks and ASCII diagrams in backticks to preserve formatting. Signed-off-by: Andrew Lilley Brinker --- schema/docs/versions.md | 912 +++++++++++++++++++++------------------- 1 file changed, 472 insertions(+), 440 deletions(-) diff --git a/schema/docs/versions.md b/schema/docs/versions.md index 073457e5aed..f5f3508df7d 100644 --- a/schema/docs/versions.md +++ b/schema/docs/versions.md @@ -1,398 +1,434 @@ # CVE 5.0 Product and Version Encodings -CVE 5.0 introduces a simpler schema for defining a product -and a clearer schema for encoding the vulnerable versions of a product. -This document explains how to use these new schemas. +CVE 5.0 introduces a simpler schema for defining a product and a clearer schema +for encoding the vulnerable versions of a product. This document explains how +to use these new schemas. ## Product Objects In earlier versions of CVE, the `affected` object contained a `vendors` array, -and each `vendor` object contained a `products` array. -This forced specifying a vendor name even for products without vendors, -such as open source software. - -To make it clearer how to identify open-source software, the CVE 5.0 `affected` object -contains the `products` array directly. Each product object can provide these properties: - - - `vendor`: the name of the organization, project, community, individual, or user - that created or maintains the product or hosted service. - When `collectionURL` and `packageName` are used, - this field may specify the user or account associated with the package - within the package collection. - Formerly `vendorName` in the `vendor` object. - - - `product`: the name of the product itself. - Formerly `productName`. - - - `collectionURL`: a URL identifying a software package collection. - For example: `https://registry.npmjs.org` or `https://rubygems.org`. - - - `packageName`: the name of the package within the collection. - For example: `left-pad`. - - - `cpes`: a list of affected products encoded in - Common Platform Enumeration (CPE) 2.2 or 2.3 format. - Formerly `affectsCpes` in the `affected` object. - - - `modules`: a list of the the affected components, features, modules, sub-components, - sub-products, APIs, commands, utilities, programs, or functionalities`. - - - `programFiles`: a list of the affected source code files. - - - `programRoutines`: a list of the affected source code functions, - methods, subroutines, or procedures. - Each entry in the list is an object, and the `name` property is required. - Other properties may be added as appropriate depending on the context. - - - `platforms`: a list of the affected platforms. When omitted, all platforms are assumed affected - by this product description. - Platforms may include execution environments, operating systems, virtualization technolgies, - hardware models, or computing architectures. - For example: `Android`, `iOS`, `macOS`, `Windows`, `x86`, `ARM`, `iPad`, `Chromebook`, `Docker`. - Formerly in the `version` object. - - - `versions` and `defaultStatus`: a description of which versions are affected. - (See next section for details.) - -Most of these properties are optional. -The only requirements are identifying information and version information. -Identifying information may be provided by -_either_ `vendor` and `product` (for commercial offerings) -_or_ `collectionURL` and `packageName` (for open-source packages). -It is fine to list both pairs, such as in the case of a -commercial offering of packaged open-source products. -Version information is provided by `versions` and/or `defaultStatus`, detailed in the next section. +and each `vendor` object contained a `products` array. This forced specifying a +vendor name even for products without vendors, such as open source software. + +To make it clearer how to identify open source software, the CVE 5.0 `affected` +object contains the `products` array directly. Each product object can provide +these properties: + +- `vendor`: the name of the organization, project, community, individual, or + user that created or maintains the product or hosted service. When + `collectionURL` and `packageName` are used, this field may specify the user + or account associated with the package within the package collection. + Formerly `vendorName` in the `vendor` object. +- `product`: the name of the product itself. Formerly `productName`. +- `collectionURL`: a URL identifying a software package collection. For + example: `https://registry.npmjs.org` or `https://rubygems.org`. +- `packageName`: the name of the package within the collection. For example: + `left-pad`. +- `cpes`: a list of affected products encoded in Common Platform Enumeration + (CPE) 2.2 or 2.3 format. Formerly `affectsCpes` in the `affected` object. +- `modules`: a list of the the affected components, features, modules, + sub-components, sub-products, APIs, commands, utilities, programs, or + functionalities. +- `programFiles`: a list of the affected source code files. +- `programRoutines`: a list of the affected source code functions, methods, + subroutines, or procedures. Each entry in the list is an object, and the + `name` property is required. Other properties may be added as appropriate + depending on the context. +- `platforms`: a list of the affected platforms. When omitted, all platforms + are assumed affected by this product description. Platforms may include + execution environments, operating systems, virtualization technologies, + hardware models, or computing architectures. For example: `Android`, `iOS`, + `macOS`, `Windows`, `x86`, `ARM`, `iPad`, `Chromebook`, `Docker`. Formerly in + the `version` object. +- `versions` and `defaultStatus`: a description of which versions are affected. + (See next section for details.) + +Most of these properties are optional. The only requirements are identifying +information and version information. + +Identifying information may be provided by _either_ `vendor` and `product` +(for commercial offerings) _and/or_ `collectionURL` and `packageName` (for open +source packages). It is fine to list both pairs, such as in the case of a +commercial offering of packaged open source products. + +Version information is provided by `versions` and/or `defaultStatus`, detailed +in the next section. For example, a minimal entry for a commercial product: - "affected": [ - { - "vendor": "Widgets LLC", - "product": "Flux Capacitor", - "versions": [ ... ] - } - ] - -And for an open-source package: - - "affected": [ - { - "collectionURL": "https://registry.npmjs.org", - "packageName": "left-pad", - "versions": [ ... ] - } - ] - -A product's affected versions may differ by platform. -In this case, multiple product objects would be listed in `affected` to -encode the different version information, with `platforms` restricting -each object to the relevant platform. +```json +"affected": [ + { + "vendor": "Widgets LLC", + "product": "Flux Capacitor", + "versions": [ ... ] + } +] +``` + +And for an open source package: + +```json +"affected": [ + { + "collectionURL": "https://registry.npmjs.org", + "packageName": "left-pad", + "versions": [ ... ] + } +] +``` + +A product's affected versions may differ by platform. In this case, multiple +product objects would be listed in `affected` to encode the different version +information, with `platforms` restricting each object to the relevant platform. + For example: - "affected": [ - { - "vendor": "Widgets LLC", - "product": "Flux Capacitor", - "platforms": ["macOS"], - "versions": [ ... macOS versions ... ] - }, - { - "vendor": "Widgets LLC", - "product": "Flux Capacitor", - "platforms": ["Linux", "Windows"], - "versions": [ ... Linux and Windows versions ... ] - } - ] +```json +"affected": [ + { + "vendor": "Widgets LLC", + "product": "Flux Capacitor", + "platforms": ["macOS"], + "versions": [ ... macOS versions ... ] + }, + { + "vendor": "Widgets LLC", + "product": "Flux Capacitor", + "platforms": ["Linux", "Windows"], + "versions": [ ... Linux and Windows versions ... ] + } +] +``` ## Version Status Decisions -The version encoding in CVE 5.0 comes with a clear algorithm for deciding -the status of a given product version—affected, unaffected, or unknown—while -still being easy for analysts and users to read and reason about. +The version encoding in CVE 5.0 comes with a clear algorithm for deciding the +status of a given product version—affected, unaffected, or unknown—while still +being easy for analysts and users to read and reason about. In the product object, the `versions` and `defaultStatus` fields together -define an algorithmic mapping from any product version to its vulnerability status, -which is one of these strings: +define an algorithmic mapping from any product version to its vulnerability +status, which is one of these strings: - - `affected`: The version is affected by the vulnerability. - - `unaffected`: The version is unaffected by the vulnerability. - - `unknown`: It is unknown or unspecified whether the version is affected by the vulnerability. - There can be many reasons for this status, including that an investigation - has not been undertaken or that a vendor has not disclosed the status. +- `affected`: The version is affected by the vulnerability. +- `unaffected`: The version is unaffected by the vulnerability. +- `unknown`: It is unknown or unspecified whether the version is affected by + the vulnerability. There can be many reasons for this status, including that + an investigation has not been undertaken or that a vendor has not disclosed + the status. The `versions` field contains a list of version objects, each of which matches -a single version or a range of versions and specifies the status for the matched versions. -The versions matched by different objects should be disjoint; +a single version or a range of versions and specifies the status for the +matched versions. The versions matched by different objects should be disjoint; that is, any specific version should be matched by at most one version object. -Versions not matched by any version object take the status listed in `defaultStatus`. -When `defaultStatus` is itself omitted, it defaults to `unknown`. +Versions not matched by any version object take the status listed in +`defaultStatus`. When `defaultStatus` is itself omitted, it defaults to +`unknown`. -Omitting for the moment the details of how a particular entry -encodes the status for the versions it matches, -the algorithm for deciding the status of any particular version V is: +Omitting for the moment the details of how a particular entry encodes the +status for the versions it matches, the algorithm for deciding the status of +any particular version V is: - for entry in product.versions { - if entry matches V { - return status specified by entry for V - } +``` +for entry in product.versions { + if entry matches V { + return status specified by entry for V } - return product.defaultStatus - -For example, this is an encoding in which versions 2.0.0 through 2.5.1 are affected, -2.5.2 and later 2.x.x are unaffected, and all other versions have unknown vulnerability status: - - "versions": [ - { ... 2.0.0 through 2.5.1 affected ... }, - { ... 2.5.2 through 2.x.x unaffected ... } - ] - -For contrast, this is an encoding in which version 2.0.0 through 2.5.1 are affected, -and all other versions, both before 2.0.0 and after 2.5.1, are considered unaffected: - - "versions": [ - { ... 2.0.0 through 2.5.1 affected ... } - ], - "defaultStatus": "unaffected" - -It is also possible to say that 2.5.2 and later are unaffected and everything else affected: - - "versions": [ - { ... 2.5.2 and later unaffected ... } - ], - "defaultStatus": "affected" +} +return product.defaultStatus +``` + +For example, this is an encoding in which versions 2.0.0 through 2.5.1 are +affected, 2.5.2 and later 2.x.x are unaffected, and all other versions have +unknown vulnerability status: + +``` +"versions": [ + { ... 2.0.0 through 2.5.1 affected ... }, + { ... 2.5.2 through 2.x.x unaffected ... } +] +``` + +For contrast, this is an encoding in which version 2.0.0 through 2.5.1 are +affected, and all other versions, both before 2.0.0 and after 2.5.1, are +considered unaffected: + +``` +"versions": [ + { ... 2.0.0 through 2.5.1 affected ... } +], +"defaultStatus": "unaffected" +``` + +It is also possible to say that 2.5.2 and later are unaffected and everything +else affected: + +``` +"versions": [ + { ... 2.5.2 and later unaffected ... } +], +"defaultStatus": "affected" +``` The specific choice of default depends mainly on how much the author of the CVE -understands about the affected version set. For example, a vulnerability researcher -who has tested a few specific versions and is making no claims about others might write: +understands about the affected version set. For example, a vulnerability +researcher who has tested a few specific versions and is making no claims about +others might write: - "versions": [ - { ... 2.4 affected ... }, - { ... 2.5 affected ... }, - { ... 2.6 unaffected ... } - ] +``` +"versions": [ + { ... 2.4 affected ... }, + { ... 2.5 affected ... }, + { ... 2.6 unaffected ... } +] +``` -In this case, `defaultStatus` defaults to `unknown`, which is correct for this report. +In this case, `defaultStatus` defaults to `unknown`, which is correct for this +report. On the other hand, a vendor that knows there are exactly two affected versions might write: - "versions": [ - { ... 2.4 affected ... }, - { ... 2.5 affected ... } - ], - "defaultStatus": "unaffected" +``` +"versions": [ + { ... 2.4 affected ... }, + { ... 2.5 affected ... } +], +"defaultStatus": "unaffected" +``` The CVE schema itself does not encourage or discourage any particular choice -of `defaultStatus`. -CVE encodings can use the `defaultStatus` that makes their status description clearest. +of `defaultStatus`. CVE encodings can use the `defaultStatus` that makes their +status description clearest. ## Versions and Version Ranges -As mentioned above, each version object matches a single version -or a range of versions and specifies the status for the matched versions. +As mentioned above, each version object matches a single version or a range of +versions and specifies the status for the matched versions. + +A version object specifies the status for a single version by setting only the +`version` and `status` fields. For example: + +```json +{ + "version": "2.4", + "status": "affected" +} +``` + +Therefore, the full encoding of the final example in the previous section, in +which only 2.4 and 2.5 are affected, would be: + +```json +"versions": [ + {"version": "2.4", "status": "affected"}, + {"version": "2.5", "status": "affected"} +], +"defaultStatus": "unaffected" +``` + +A version object can also specify the status for a range of versions, by adding +the `versionType` field as well as either the `lessThan` or `lessThanOrEqual` +field. For example, this version object specifies that semantic versions +starting at 2.0.0 up to and including 2.5.1 are affected: + +```json +{ + "version": "2.0.0", + "versionType": "semver", + "lessThanOrEqual": "2.5.1", + "status": "affected" +} +``` + +More precisely, this kind of version object matches any version V such that +`version` ≤ V ≤ `lessThanOrEqual`. If the `lessThan` field is used instead of +`lessThanOrEqual`, then the condition is `version` ≤ V \< `lessThanOrEqual`. +For example, this version object specifies that semantic versions starting at +2.0.0 up to but not including 2.5.2 are affected: + +```json +{ + "version": "2.0.0", + "versionType": "semver", + "lessThan": "2.5.2", + "status": "affected" +} +``` + +When identifying a precise range of affected versions, the `lessThan` form is +more common, since it allows naming the exact version that introduced the fix. + +The `versionType` is required when specifying ranges, because there is no +single definition of “less than” for versions. Each different version numbering +system has its own ordering rules. For example, in [semantic +versioning][semver], `1.0.0-cr1` \< `1.0.0-m1`, while [in Maven, the opposite +is true][maven_ver]. Example version types include `maven`, `python`, `rpm`, +and `semver`. Another version type is `git`, described later. + +The version type `custom` is also defined, to mean an otherwise unspecified +ordering, specific to the vendor or product. Using `custom` means that the +version status algorithm cannot be executed, so its use is discouraged; it is +included in order to be able to convert older CVE data that had no concept of +version type. + +In any version range, the details of the version syntax and semantics depend on +the version type, but by convention, `"version": "0"` means that the range has +no lower bound, and a `*` in an upper bound denotes “infinity”, as in +`"lessThan": "2.*"`, which denotes a range where the 2.X version series is the +upper bound, or `"lessThan": "*"`, which denotes a range with no upper bound at +all. -A version object specifies the status for a single version by setting only -the `version` and `status` fields. For example: - - { - "version": "2.4", - "status": "affected" - } +Note that `*` is “infinity”, not a wildcard pattern. For example, -Therefore, the full encoding of the final example in the previous section, -in which only 2.4 and 2.5 are affected, would be: +```json +{ + "version": "1.0.0", + "versionType": "semver", + "lessThan": "2.*", + "status": "affected" +} +``` - "versions": [ - {"version": "2.4", "status": "affected"}, - {"version": "2.5", "status": "affected"} - ], - "defaultStatus": "unaffected" +says that the entire 1.X and 2.X version series are affected. -A version object can also specify the status for a range of versions, -by adding the `versionType` field as well as either the `lessThan` or `lessThanOrEqual` field. -For example, this version object specifies that semantic versions starting at 2.0.0 up to and including 2.5.1 are affected: +We saw above the example of a product in which 2.0.0 up to but not including +2.5.2 are affected, which we wrote as: - { - "version": "2.0.0", - "versionType": "semver", - "lessThanOrEqual": "2.5.1", - "status": "affected" - } +``` +"versions": [ + { ... 2.0.0 through 2.5.1 affected ... }, + { ... 2.5.2 through 2.x.x unaffected ... } +] +``` -More precisely, this kind of version object matches any version V -such that `version` ≤ V ≤ `lessThanOrEqual`. -If the `lessThan` field is used instead of `lessThanOrEqual`, then -the condition is `version` ≤ V \< `lessThanOrEqual`. -For example, this version object specifies that semantic versions starting at 2.0.0 up to but not including 2.5.2 are affected: +Now that we know how to encode version objects, that would be written as: +```json +"versions": [ { - "version": "2.0.0", - "versionType": "semver", - "lessThan": "2.5.2", + "version": "2.0.0", "versionType": "semver", "lessThan": "2.5.2", "status": "affected" + }, + { + "version": "2.5.2", "versionType": "semver", "lessThan": "2.*", + "status": "unaffected" } +] +``` + +## Version Status Changes -When identifying a precise range of affected versions, -the `lessThan` form is more common, -since it allows naming the exact version that introduced the fix. - -The `versionType` is required when specifying ranges, -because there is no single definition of “less than” for versions. -Each different version numbering system has its own ordering rules. -For example, in [semantic versioning](https://semver.org/), `1.0.0-cr1` \< `1.0.0-m1`, -while [in Maven, the opposite is true](https://octopus.com/blog/maven-versioning-explained). -Example version types include `maven`, `python`, `rpm`, and `semver`. -Another version type is `git`, described later. - -The version type `custom` is also defined, to mean an otherwise unspecified ordering, -specific to the vendor or product. Using `custom` means that the version status -algorithm cannot be executed, so its use is discouraged; it is included in order -to be able to convert older CVE data that had no concept of version type. - -In any version range, the details of the version syntax and semantics depend on the version type, -but by convention, `"version": "0"` means that the range has no lower bound, -and a `*` in an upper bound denotes “infinity”, -as in `"lessThan": "2.*"`, which denotes a range where the 2.X version series is the upper bound, -or `"lessThan": "*"`, which denotes a range with no upper bound at all. +As presented in the previous section, a version object's range form (with +`versionType` and `lessThan` or `lessThanOrEqual`) specifies a single status +for every version in the range it describes. It is also possible for the +version object to indicate status changes at transition points, breaking the +range up into segments with different status. This allows a compact way to +explain the full status of a particular version branch. -Note that `*` is “infinity”, not a wildcard pattern. For example, +Using status changes, the previous example can be shortened to a single version +object: +```json +"versions": [ { - "version": "1.0.0", - "versionType": "semver", - "lessThan": "2.*", - "status": "affected" + "version": "2.0.0", "versionType": "semver", "lessThan": "2.*", + "status": "affected", + "changes": [ + {"at": "2.5.2", "status": "unaffected"} + ] } +] +``` -says that the entire 1.X and 2.X version series are affected. - -We saw above the example of a product in which 2.0.0 up to but not including 2.5.2 are affected, -which we wrote as: +Note that in this form, the version 2.5.2 is no longer listed twice. - "versions": [ - { ... 2.0.0 through 2.5.1 affected ... }, - { ... 2.5.2 through 2.x.x unaffected ... } - ] +A more complex situation, such as when 2.6.0 had also been released with the +vulnerability and was fixed in 2.6.3, is also easily encoded: -Now that we know how to encode version objects, that would be written as: +```json +"versions": [ + { + "version": "2.0.0", "versionType": "semver", "lessThan": "2.*", + "status": "affected", + "changes": [ + {"at": "2.5.2", "status": "unaffected"}, + {"at": "2.6.0", "status": "affected"}, + {"at": "2.6.3", "status": "unaffected"} + ] + } +] +``` + +When a version is matched by a version range object `entry`, we have assumed +until now that its status is `entry.status`. With the addition of status +changes, the computation of the status of a matching version is: + +``` +status = entry.status +for change in entry.changes, sorted in increasing order { + if change.at ≤ V { + status = change.status + } +} +return status +``` - "versions": [ - { - "version": "2.0.0", "versionType": "semver", "lessThan": "2.5.2", - "status": "affected" - }, - { - "version": "2.5.2", "versionType": "semver", "lessThan": "2.*", - "status": "unaffected" - } - ] +For any versioning system with a strict linear ordering (including semantic +versioning), a status change form can always be rewritten into an equivalent, +longer list of version objects without status changes. Status changes become +particularly important for non-linear versions, such as in source control +systems. -## Version Status Changes +## Source Control Versions -As presented in the previous section, -a version object's range form (with `versionType` and `lessThan` or `lessThanOrEqual`) -specifies a single status for every version in the range it describes. -It is also possible for the version object to indicate status changes at -transition points, breaking the range up into segments with different status. -This allows a compact way to explain the full status of a particular version branch. - -Using status changes, the previous example can be shortened to a single version object: - - "versions": [ - { - "version": "2.0.0", "versionType": "semver", "lessThan": "2.*", - "status": "affected", - "changes": [ - {"at": "2.5.2", "status": "unaffected"} - ] - } - ] +For vulnerabilities in open source software, it can be very helpful to list the +precise changes that introduced and fixed the vulnerability. To allow this, +ranges using `versionType` set to `git` (or `hg` and so on) can use version +control identifiers, such as Git commit hashes, as version strings. -Note that in this form, the version 2.5.2 is no longer listed twice. +The previous example might add the source control information to the `versions` +list as follows: -A more complex situation, such as when 2.6.0 had also been released with the vulnerability -and was fixed in 2.6.3, is also easily encoded: - - "versions": [ - { - "version": "2.0.0", "versionType": "semver", "lessThan": "2.*", - "status": "affected", - "changes": [ - {"at": "2.5.2", "status": "unaffected"}, - {"at": "2.6.0", "status": "affected"}, - {"at": "2.6.3", "status": "unaffected"} - ] - } - ] - -When a version is matched by a version range object `entry`, -we have assumed until now that its status is `entry.status`. -With the addition of status changes, the computation of the status -of a matching version is: - - status = entry.status - for change in entry.changes, sorted in increasing order { - if change.at ≤ V { - status = change.status - } +```json +"versions": [ + { + "version": "2.0.0", "versionType": "semver", "lessThan": "2.*", + "status": "affected", + "changes": [ + {"at": "2.5.2", "status": "unaffected"}, + {"at": "2.6.0", "status": "affected"}, + {"at": "2.6.3", "status": "unaffected"} + ] + }, + { + "version": "0", "versionType": "git", "lessThan": "*", + "repo": "https://github.com/example/test", + "status": "unaffected", + "changes": [ + {"at": "123abc...", "status": "affected"}, + {"at": "234bcd...", "status": "unaffected"}, + {"at": "567ef0...", "status": "unaffected"} + ] } - return status - -For any versioning system with a strict linear ordering (including semantic versioning), -a status change form can always be rewritten into an equivalent, longer list of version objects -without status changes. -Status changes become particularly important for non-linear versions, -such as in source control systems. - -## Source Control Versions - -For vulnerabilities in open-source software, it can be very helpful to list the -precise changes that introduced and fixed the vulnerability. -To allow this, ranges using `versionType` set to `git` (or `hg` and so on) -can use version control identifiers, such as Git commit hashes, -as version strings. - -The previous example might add the source control information to the -`versions` list as follows: - - "versions": [ - { - "version": "2.0.0", "versionType": "semver", "lessThan": "2.*", - "status": "affected", - "changes": [ - {"at": "2.5.2", "status": "unaffected"}, - {"at": "2.6.0", "status": "affected"}, - {"at": "2.6.3", "status": "unaffected"} - ] - }, - { - "version": "0", "versionType": "git", "lessThan": "*", - "repo": "https://github.com/example/test", - "status": "unaffected", - "changes": [ - {"at": "123abc...", "status": "affected"}, - {"at": "234bcd...", "status": "unaffected"}, - {"at": "567ef0...", "status": "unaffected"} - ] - } - ] +] +``` Note that the list now contains two different kinds of version information: -semantic versions that users are likely to see -as well as Git commit hashes that are more useful to developers trying to -understand the vulnerability. - -Focusing on the Git version range, -the overall range is written to match all Git commits, -declaring them `unaffected` unless specified otherwise by status changes. -(The conventional `0` and `*` specify -“no lower bound, no upper bound” for the range.) -Because the Git version identifiers cannot be understood without -reference to a specific Git repository, this form adds a new `repo` field -containing the URL of the repository. Let's suppose the repository's commit -graph looks like this: - +semantic versions that users are likely to see as well as Git commit hashes +that are more useful to developers trying to understand the vulnerability. + +Focusing on the Git version range, the overall range is written to match all +Git commits, declaring them `unaffected` unless specified otherwise by status +changes. (The conventional `0` and `*` specify “no lower bound, no upper bound” +for the range.) Because the Git version identifiers cannot be understood +without reference to a specific Git repository, this form adds a new `repo` +field containing the URL of the repository. Let's suppose the repository's +commit graph looks like this: + +``` 1.0.0 1.0.3 ↓ ↓ o---o---o---o---o---o---o---o ← 012fab... @@ -408,129 +444,125 @@ graph looks like this: o---o---o---o---o---o---o---o---o---o---o ← 678f01... ↑ ↑ ↑ 2.6.0 2.6.2 2.6.3 - -In the graph, time moves left to right: if a commit A (denoted by an `o`) -is connected by one or more lines to another commit B to the right of A, -then A is an _ancestor_ of B, and B is a _descendant_ of A. -For source control version types, the less than operator on versions -A \< B is defined to mean that A is an ancestor of B in the commit graph, -and similarly A ≤ B means that A = B or A \< B. -The complete set of less-than relations between the pictured commits is: - - - `123abc...` \< `234bcd...`, `345cde...`, `456def...`, `567ef0...`, and `678f01...`. - - `234bcd...` \< `345cde...`. - - `456def...` \< `567ef0...` and `678f01...`. - - `567ef0...` \< `678f01...`. - -The matching and status algorithms then proceed as before, -using that definition of \<. -The iteration “in sorted order” allows any topological sort: -when A \< B, then a status change at A -must be considered before a status change at B. -In this example, the changes list can be processed in two -possible orders: `123abc...` must be first, and then the -other two can be considered in either order, -since neither is less than the other. - -Given this repository graph and the source control version information, -we can see exactly what happened with this vulnerability: - - - It was introduced in `123abc...` (released in 2.0.0). - - It was fixed in `234bcd...` (between 2.5.1 and 2.5.2 on the 2.5 branch). - - It was fixed in `567ef0...` (between 2.6.2 and 2.6.3 on the 2.6 branch). +``` + +In the graph, time moves left to right: if a commit A (denoted by an `o`) is +connected by one or more lines to another commit B to the right of A, then A is +an _ancestor_ of B, and B is a _descendant_ of A. For source control version +types, the less than operator on versions A \< B is defined to mean that A is +an ancestor of B in the commit graph, and similarly A ≤ B means that A = B or +A \< B. The complete set of less-than relations between the pictured commits +is: + +- `123abc...` \< `234bcd...`, `345cde...`, `456def...`, `567ef0...`, and + `678f01...`. +- `234bcd...` \< `345cde...`. +- `456def...` \< `567ef0...` and `678f01...`. +- `567ef0...` \< `678f01...`. + +The matching and status algorithms then proceed as before, using that +definition of \<. The iteration “in sorted order” allows any topological sort: +when A \< B, then a status change at A must be considered before a status +change at B. In this example, the changes list can be processed in two possible +orders: `123abc...` must be first, and then the other two can be considered in +either order, since neither is less than the other. + +Given this repository graph and the source control version information, we can +see exactly what happened with this vulnerability: + +- It was introduced in `123abc...` (released in 2.0.0). +- It was fixed in `234bcd...` (between 2.5.1 and 2.5.2 on the 2.5 branch). +- It was fixed in `567ef0...` (between 2.6.2 and 2.6.3 on the 2.6 branch). The status change list specifies these exact events, which makes it possible -for us to decide whether any given commit has the vulnerability. -For example: +for us to decide whether any given commit has the vulnerability. For example: - - `012fab...` is unaffected: it is not a descendant of `123abc...`. - - `345cde...` is unaffected: it is a descendant of `123abc...` but also of `234bcd...`. - - `456def...` is affected: it is a descendant of `123abc...` and not a descendant of `234bcd...` or `567ef0...`. +- `012fab...` is unaffected: it is not a descendant of `123abc...`. +- `345cde...` is unaffected: it is a descendant of `123abc...` but also of + `234bcd...`. +- `456def...` is affected: it is a descendant of `123abc...` and not a + descendant of `234bcd...` or `567ef0...`. Given this kind of precise source control-level information about which changes -introduced and fixed a vulnerability, it is possible to derive the -affected version ranges automatically. -The [OSV project](https://osv.dev/) is building tooling to do exactly that. - -When the `lessThan` field in a source control range is set to something other than `*`, -it has the effect of limiting the commits to which the range applies -to just those commits with `lessThan` as a descendant. -This is typically not useful, but it does allow encoding the -(unusual) practice of issuing different CVEs for different version branches. -For example, if the 2.5 branch and 2.6 branch instances of this -vulnerability needed to be in two different CVE entries, they could be -encoded by giving the CVE for the 2.5 branch this information: - - "defaultStatus": "unaffected" - "versions": [ - { - "version": "123abc...", "versionType": "git", "lessThan": "234bcd...", - "status": "affected" - } - ] +introduced and fixed a vulnerability, it is possible to derive the affected +version ranges automatically. The [OSV project][osv] is building tooling to do +exactly that. + +When the `lessThan` field in a source control range is set to something other +than `*`, it has the effect of limiting the commits to which the range applies +to just those commits with `lessThan` as a descendant. This is typically not +useful, but it does allow encoding the (unusual) practice of issuing different +CVEs for different version branches. For example, if the 2.5 branch and 2.6 +branch instances of this vulnerability needed to be in two different CVE +entries, they could be encoded by giving the CVE for the 2.5 branch this +information: + +```json +"defaultStatus": "unaffected" +"versions": [ + { + "version": "123abc...", "versionType": "git", "lessThan": "234bcd...", + "status": "affected" + } +] +``` And by giving the CVE for the 2.6 branch this information: - "defaultStatus": "unaffected" - "versions": [ - { - "version": "123abc...", "versionType": "git", "lessThan": "567ef0...", - "status": "affected" - } - ] +```json +"defaultStatus": "unaffected" +"versions": [ + { + "version": "123abc...", "versionType": "git", "lessThan": "567ef0...", + "status": "affected" + } +] +``` -Again, this is an unusual choice and should typically be discouraged. -It is more useful in many ways to have a single CVE for each vulnerability. +Again, this is an unusual choice and should typically be discouraged. It is +more useful in many ways to have a single CVE for each vulnerability. ## Version Objects For reference, here are all the fields defined for version objects: - - `version`: the single version being described, - or the version at the start of the range. - By convention, `0` typically denotes the earliest possible version. - - - `versionType`: the version numbering system used for specifying the range. - This defines the exact semantics of the comparison (\< and ≤) operations - on versions, which is necessary to understand the range itself. - The value `custom` indicates that the version type is unspecified, - which should be avoided whenever possible: - it is included primarily for use in conversion of older data files. - - - `lessThan` or `lessThanOrEqual`: the upper limit of the range. - Only one of these can be specified. - For `lessThan`, the least version _not_ in the range. - For `lessThanOrEqual`, the greatest version in the range; - this form is discouraged in favor of writing `lessThan` - with the version that introduced the fix. - - When using `lessThan` (only), the usual version syntax - is expanded to allow a pattern - to end in an asterisk (`*`), indicating an arbitrarily large number - in the version ordering. - For example, `"lessThan": "1.*"` describes the remainder of the 1.X branch, - while `"lessThan": "*"` describes all versions greater than or equal to - the base `version`. - - - `status`: the vulnerability status for the version or range of versions. - For a range, the status may be refined by the 'changes' list. - - - `changes`: a list of status changes that take place during a range. - The list should be sorted in (linearly or topologically) - increasing order by the 'at' field, according to the `versionType`, - but clients must not assume this. - Instead, clients must re-sort the list themselves before using it. - -A version object describing a single version must specify -both `version` and `status`, and no other fields. - -A version object describing a range must specify -`version`, `versionType`, one of `lessThan` or `lessThanOrEqual`, and `status`. -The `changes` field is optional. +- `version`: the single version being described, or the version at the start of + the range. By convention, `0` typically denotes the earliest possible + version. +- `versionType`: the version numbering system used for specifying the range. + This defines the exact semantics of the comparison (\< and ≤) operations on + versions, which is necessary to understand the range itself. The value + `custom` indicates that the version type is unspecified, which should be + avoided whenever possible: it is included primarily for use in conversion of + older data files. +- `lessThan` or `lessThanOrEqual`: the upper limit of the range. Only one of + these can be specified. For `lessThan`, the least version _not_ in the range. + For `lessThanOrEqual`, the greatest version in the range; this form is + discouraged in favor of writing `lessThan` with the version that introduced + the fix. When using `lessThan` (only), the usual version syntax is expanded + to allow a pattern to end in an asterisk (`*`), indicating an arbitrarily + large number in the version ordering. For example, `"lessThan": "1.*"` + describes the remainder of the 1.X branch, while `"lessThan": "*"` describes + all versions greater than or equal to the base `version`. +- `status`: the vulnerability status for the version or range of versions. For + a range, the status may be refined by the 'changes' list. +- `changes`: a list of status changes that take place during a range. The list + should be sorted in (linearly or topologically) increasing order by the 'at' + field, according to the `versionType`, but clients must not assume this. + Instead, clients must re-sort the list themselves before using it. + +A version object describing a single version must specify both `version` and +`status`, and no other fields. + +A version object describing a range must specify `version`, `versionType`, one +of `lessThan` or `lessThanOrEqual`, and `status`. The `changes` field is +optional. Each change object in the `changes` list has two fields: - - `at`: the version at which a status change occurs. - - - `status`: the new status in the range starting at the given version. +- `at`: the version at which a status change occurs. +- `status`: the new status in the range starting at the given version. +[semver]: https://semver.org/ +[maven_ver]: https://octopus.com/blog/maven-versioning-explained +[osv]: https://osv.dev/ From a6382bf042c4ba45f46ce4a5923aa98721ee6e9c Mon Sep 17 00:00:00 2001 From: Andrew Lilley Brinker Date: Thu, 21 Aug 2025 15:35:58 -0700 Subject: [PATCH 8/9] chore: introduced expectation that "repo" is cloneable. Based on feedback in [1]. [1]: https://github.com/CVEProject/cve-schema/issues/280 Signed-off-by: Andrew Lilley Brinker --- schema/docs/versions.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/schema/docs/versions.md b/schema/docs/versions.md index f5f3508df7d..4e95c1d2293 100644 --- a/schema/docs/versions.md +++ b/schema/docs/versions.md @@ -425,8 +425,11 @@ Git commits, declaring them `unaffected` unless specified otherwise by status changes. (The conventional `0` and `*` specify “no lower bound, no upper bound” for the range.) Because the Git version identifiers cannot be understood without reference to a specific Git repository, this form adds a new `repo` -field containing the URL of the repository. Let's suppose the repository's -commit graph looks like this: +field containing the URL of the repository. This URL is expected to be +"Git-cloneable," meaning a `git clone` command which used the URL would +succeed. + +Let's suppose the repository's commit graph looks like this: ``` 1.0.0 1.0.3 From fc1861418e9e0929842b70f977939c4a8f749b71 Mon Sep 17 00:00:00 2001 From: Andrew Lilley Brinker Date: Tue, 26 Aug 2025 12:31:11 -0700 Subject: [PATCH 9/9] fix: update examples, correct mistaken timestamp regex Signed-off-by: Andrew Lilley Brinker --- .gitignore | 5 ++ schema/CVE_Record_Format.json | 2 +- schema/docs/CVE_Record_Format_bundled.json | 69 ++++++++++++++----- ...VE_Record_Format_bundled_adpContainer.json | 68 ++++++++++++++---- ..._Format_bundled_cnaPublishedContainer.json | 68 ++++++++++++++---- ...d_Format_bundled_cnaRejectedContainer.json | 68 ++++++++++++++---- .../docs/cnaContainer-advanced-example.json | 8 +-- schema/docs/cnaContainer-basic-example.json | 1 + schema/docs/full-record-advanced-example.json | 16 +++-- schema/docs/full-record-basic-example.json | 7 +- .../bundling-scripts/bundle-script-linux.sh | 0 .../bundling-scripts/bundle-script-win.sh | 0 12 files changed, 237 insertions(+), 75 deletions(-) mode change 100644 => 100755 schema/support/bundling-scripts/bundle-script-linux.sh mode change 100644 => 100755 schema/support/bundling-scripts/bundle-script-win.sh diff --git a/.gitignore b/.gitignore index 02709c03380..8fd52e76d45 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,8 @@ package-lock.json node_modules +schema/cve-schema.json +schema/docs/CVE_Record_Format_bundled.json +schema/docs/CVE_Record_Format_bundled_adpContainer.json +schema/docs/CVE_Record_Format_bundled_cnaPublishedContainer.json +schema/docs/CVE_Record_Format_bundled_cnaRejectedContainer.json diff --git a/schema/CVE_Record_Format.json b/schema/CVE_Record_Format.json index 676ad0f53db..645049b60fc 100644 --- a/schema/CVE_Record_Format.json +++ b/schema/CVE_Record_Format.json @@ -85,7 +85,7 @@ "timestamp": { "type": "string", "description": "Date/time format based on RFC3339 and ISO ISO8601, with a mandatory timezone in the format 'yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM'.", - "pattern": "^(((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30)))T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])(Z|[+-][0-9]{2}:[0-9]{2})$", + "pattern": "^(((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30)))T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])([+-][0-9]{2}:[0-9]{2})$", "examples": [ "2025-01-04T12:01:01+05:30" ] diff --git a/schema/docs/CVE_Record_Format_bundled.json b/schema/docs/CVE_Record_Format_bundled.json index f7fffebf8fd..f94e62d2ea9 100644 --- a/schema/docs/CVE_Record_Format_bundled.json +++ b/schema/docs/CVE_Record_Format_bundled.json @@ -2,7 +2,7 @@ "$schema": "http://json-schema.org/draft-07/schema#", "$id": "https://cveproject.github.io/cve-schema/schema/CVE_Record_Format.json", "title": "CVE JSON record format", - "description": "cve-schema specifies the CVE JSON record format. This is the blueprint for a rich set of JSON data that can be submitted by CVE Numbering Authorities (CNAs) and Authorized Data Publishers (ADPs) to describe a CVE Record. Some examples of CVE Record data include CVE ID number, affected product(s), affected version(s), and public references. While those specific items are required when assigning a CVE, there are many other optional data in the schema that can be used to enrich CVE Records for community benefit. Learn more about the CVE program at [the official website](https://cve.mitre.org). This CVE JSON record format is defined using JSON Schema. Learn more about JSON Schema [here](https://json-schema.org/).", + "description": "The CVE Record Format is the blueprint for a rich set of JSON data that can be submitted by CVE Numbering Authorities (CNAs) and Authorized Data Publishers (ADPs) to describe a CVE Record. Some examples of CVE Record data include CVE ID number, affected product(s), affected version(s), and public references. While those specific items are required when assigning a CVE, there are many other optional data in the schema that can be used to enrich CVE Records for community benefit. Learn more about the CVE program at [the official website](https://www.cve.org). This CVE JSON record format is defined using JSON Schema. Learn more about JSON Schema [here](https://json-schema.org/).", "definitions": { "uriType": { "description": "A universal resource identifier (URI), according to [RFC 3986](https://tools.ietf.org/html/rfc3986).", @@ -77,6 +77,7 @@ }, "cveId": { "type": "string", + "description": "The official CVE identifier contains the string 'CVE', followed by the year, followed by a 4 to 19 digit number. Note that the year-part of the identifier should indicate either the year the vulnerability was discovered, or the year the CVE ID is published in. CVE IDs must be unique.", "pattern": "^CVE-[0-9]{4}-[0-9]{4,19}$" }, "cpe22and23": { @@ -107,16 +108,13 @@ "minLength": 2, "maxLength": 32 }, - "datestamp": { - "description": "Date/time format based on RFC3339 and ISO ISO8601.", - "type": "string", - "format": "date", - "pattern": "^((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30))$" - }, "timestamp": { "type": "string", - "description": "Date/time format based on RFC3339 and ISO ISO8601, with an optional timezone in the format 'yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM'. If timezone offset is not given, GMT (+00:00) is assumed.", - "pattern": "^(((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30)))T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])(\\.[0-9]+)?(Z|[+-][0-9]{2}:[0-9]{2})?$" + "description": "Date/time format based on RFC3339 and ISO ISO8601, with a mandatory timezone in the format 'yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM'.", + "pattern": "^(((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30)))T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])([+-][0-9]{2}:[0-9]{2})$", + "examples": [ + "2025-01-04T12:01:01+05:30" + ] }, "version": { "description": "A single version of a product, as expressed in its own version numbering scheme.", @@ -345,7 +343,7 @@ }, "versions": { "type": "array", - "description": "Set of product versions or version ranges related to the vulnerability. The versions satisfy the CNA Rules [8.1.2 requirement](https://cve.mitre.org/cve/cna/rules.html#section_8-1_cve_entry_information_requirements). Versions or defaultStatus may be omitted, but not both.", + "description": "Set of product versions or version ranges related to the vulnerability. The versions help satisfy the CNA Rules [5.1.3 requirement](https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_5-1_Required_CVE_Record_Content). Versions or defaultStatus may be omitted, but not both.", "minItems": 1, "uniqueItems": true, "items": { @@ -465,7 +463,9 @@ "required": [ "cveId", "assignerOrgId", - "state" + "state", + "datePublished", + "dateReserved" ], "properties": { "cveId": { @@ -517,7 +517,9 @@ "required": [ "cveId", "assignerOrgId", - "state" + "state", + "datePublished", + "dateReserved" ], "properties": { "cveId": { @@ -743,7 +745,8 @@ "providerMetadata", "descriptions", "affected", - "references" + "references", + "datePublic" ], "patternProperties": { "^x_[^.]*$": {} @@ -924,6 +927,10 @@ ], "additionalProperties": false } + }, + "preformatted": { + "type": "boolean", + "description": "If true, indicates the 'description' is preformatted text that should be rendered to preserve spacing and other formatting. If false, will be rendered without preserving formatting." } }, "required": [ @@ -3239,7 +3246,6 @@ ], "properties": { "time": { - "description": "Timestamp representing when the event in the timeline occurred. The timestamp format is based on RFC3339 and ISO ISO8601, with an optional timezone. yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM - if the timezone offset is not given, GMT (+00:00) is assumed.", "$ref": "#/definitions/timestamp" }, "lang": { @@ -3305,7 +3311,38 @@ "source": { "type": "object", "description": "This is the source information (who discovered it, who researched it, etc.) and optionally a chain of CNA information (e.g. the originating CNA and subsequent parent CNAs who have processed it before it arrives at the MITRE root).\n Must contain: IF this is in the root level it MUST contain a CNA_chain entry, IF this source entry is NOT in the root (e.g. it is part of a vendor statement) then it must contain at least one type of data entry.", - "minProperties": 1 + "minProperties": 1, + "properties": { + "defect": { + "title": "Defects", + "type": "array", + "description": "CNA specific bug or defect tracking IDs (optional).", + "uniqueItems": true, + "items": { + "type": "string", + "maxLength": 64 + } + }, + "advisory": { + "title": "Advisory ID", + "type": "string", + "description": "CNA specific advisory IDs (optional).", + "maxLength": 64 + }, + "discovery": { + "type": "string", + "title": "Source of vulnerability discovery", + "enum": [ + "INTERNAL", + "EXTERNAL", + "USER", + "UPSTREAM", + "UNKNOWN" + ], + "description": "Source of vulnerability discovery. This may be a factor for some consumers in prioritizing vulnerability response. \nINTERNAL: this vulnerability was found by the CNA's internal research.\nEXTERNAL: this vulnerability was found during research external to a CNA.\nUSER: This vulnerability was discovered during product use.\nUPSTREAM: This vulnerability was found by an upstream vendor or producer.\nUNKNOWN: Source of discovery is not defined or is unknown", + "default": "UNKNOWN" + } + } }, "language": { "type": "string", @@ -3519,4 +3556,4 @@ "additionalProperties": false } ] -} +} \ No newline at end of file diff --git a/schema/docs/CVE_Record_Format_bundled_adpContainer.json b/schema/docs/CVE_Record_Format_bundled_adpContainer.json index 5f041e44ae1..980f77b6995 100644 --- a/schema/docs/CVE_Record_Format_bundled_adpContainer.json +++ b/schema/docs/CVE_Record_Format_bundled_adpContainer.json @@ -77,6 +77,7 @@ }, "cveId": { "type": "string", + "description": "The official CVE identifier contains the string 'CVE', followed by the year, followed by a 4 to 19 digit number. Note that the year-part of the identifier should indicate either the year the vulnerability was discovered, or the year the CVE ID is published in. CVE IDs must be unique.", "pattern": "^CVE-[0-9]{4}-[0-9]{4,19}$" }, "cpe22and23": { @@ -107,16 +108,13 @@ "minLength": 2, "maxLength": 32 }, - "datestamp": { - "description": "Date/time format based on RFC3339 and ISO ISO8601.", - "type": "string", - "format": "date", - "pattern": "^((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30))$" - }, "timestamp": { "type": "string", - "description": "Date/time format based on RFC3339 and ISO ISO8601, with an optional timezone in the format 'yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM'. If timezone offset is not given, GMT (+00:00) is assumed.", - "pattern": "^(((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30)))T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])(\\.[0-9]+)?(Z|[+-][0-9]{2}:[0-9]{2})?$" + "description": "Date/time format based on RFC3339 and ISO ISO8601, with a mandatory timezone in the format 'yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM'.", + "pattern": "^(((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30)))T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])([+-][0-9]{2}:[0-9]{2})$", + "examples": [ + "2025-01-04T12:01:01+05:30" + ] }, "version": { "description": "A single version of a product, as expressed in its own version numbering scheme.", @@ -345,7 +343,7 @@ }, "versions": { "type": "array", - "description": "Set of product versions or version ranges related to the vulnerability. The versions satisfy the CNA Rules [8.1.2 requirement](https://cve.mitre.org/cve/cna/rules.html#section_8-1_cve_entry_information_requirements). Versions or defaultStatus may be omitted, but not both.", + "description": "Set of product versions or version ranges related to the vulnerability. The versions help satisfy the CNA Rules [5.1.3 requirement](https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_5-1_Required_CVE_Record_Content). Versions or defaultStatus may be omitted, but not both.", "minItems": 1, "uniqueItems": true, "items": { @@ -465,7 +463,9 @@ "required": [ "cveId", "assignerOrgId", - "state" + "state", + "datePublished", + "dateReserved" ], "properties": { "cveId": { @@ -517,7 +517,9 @@ "required": [ "cveId", "assignerOrgId", - "state" + "state", + "datePublished", + "dateReserved" ], "properties": { "cveId": { @@ -743,7 +745,8 @@ "providerMetadata", "descriptions", "affected", - "references" + "references", + "datePublic" ], "patternProperties": { "^x_[^.]*$": {} @@ -924,6 +927,10 @@ ], "additionalProperties": false } + }, + "preformatted": { + "type": "boolean", + "description": "If true, indicates the 'description' is preformatted text that should be rendered to preserve spacing and other formatting. If false, will be rendered without preserving formatting." } }, "required": [ @@ -3239,7 +3246,6 @@ ], "properties": { "time": { - "description": "Timestamp representing when the event in the timeline occurred. The timestamp format is based on RFC3339 and ISO ISO8601, with an optional timezone. yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM - if the timezone offset is not given, GMT (+00:00) is assumed.", "$ref": "#/definitions/timestamp" }, "lang": { @@ -3305,7 +3311,38 @@ "source": { "type": "object", "description": "This is the source information (who discovered it, who researched it, etc.) and optionally a chain of CNA information (e.g. the originating CNA and subsequent parent CNAs who have processed it before it arrives at the MITRE root).\n Must contain: IF this is in the root level it MUST contain a CNA_chain entry, IF this source entry is NOT in the root (e.g. it is part of a vendor statement) then it must contain at least one type of data entry.", - "minProperties": 1 + "minProperties": 1, + "properties": { + "defect": { + "title": "Defects", + "type": "array", + "description": "CNA specific bug or defect tracking IDs (optional).", + "uniqueItems": true, + "items": { + "type": "string", + "maxLength": 64 + } + }, + "advisory": { + "title": "Advisory ID", + "type": "string", + "description": "CNA specific advisory IDs (optional).", + "maxLength": 64 + }, + "discovery": { + "type": "string", + "title": "Source of vulnerability discovery", + "enum": [ + "INTERNAL", + "EXTERNAL", + "USER", + "UPSTREAM", + "UNKNOWN" + ], + "description": "Source of vulnerability discovery. This may be a factor for some consumers in prioritizing vulnerability response. \nINTERNAL: this vulnerability was found by the CNA's internal research.\nEXTERNAL: this vulnerability was found during research external to a CNA.\nUSER: This vulnerability was discovered during product use.\nUPSTREAM: This vulnerability was found by an upstream vendor or producer.\nUNKNOWN: Source of discovery is not defined or is unknown", + "default": "UNKNOWN" + } + } }, "language": { "type": "string", @@ -3437,10 +3474,11 @@ } } }, + "type": "object", "properties": { "adpContainer": { "$ref": "#/definitions/adpContainer" } }, "additionalProperties": false -} +} \ No newline at end of file diff --git a/schema/docs/CVE_Record_Format_bundled_cnaPublishedContainer.json b/schema/docs/CVE_Record_Format_bundled_cnaPublishedContainer.json index 393d59873b8..968014be1b9 100644 --- a/schema/docs/CVE_Record_Format_bundled_cnaPublishedContainer.json +++ b/schema/docs/CVE_Record_Format_bundled_cnaPublishedContainer.json @@ -77,6 +77,7 @@ }, "cveId": { "type": "string", + "description": "The official CVE identifier contains the string 'CVE', followed by the year, followed by a 4 to 19 digit number. Note that the year-part of the identifier should indicate either the year the vulnerability was discovered, or the year the CVE ID is published in. CVE IDs must be unique.", "pattern": "^CVE-[0-9]{4}-[0-9]{4,19}$" }, "cpe22and23": { @@ -107,16 +108,13 @@ "minLength": 2, "maxLength": 32 }, - "datestamp": { - "description": "Date/time format based on RFC3339 and ISO ISO8601.", - "type": "string", - "format": "date", - "pattern": "^((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30))$" - }, "timestamp": { "type": "string", - "description": "Date/time format based on RFC3339 and ISO ISO8601, with an optional timezone in the format 'yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM'. If timezone offset is not given, GMT (+00:00) is assumed.", - "pattern": "^(((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30)))T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])(\\.[0-9]+)?(Z|[+-][0-9]{2}:[0-9]{2})?$" + "description": "Date/time format based on RFC3339 and ISO ISO8601, with a mandatory timezone in the format 'yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM'.", + "pattern": "^(((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30)))T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])([+-][0-9]{2}:[0-9]{2})$", + "examples": [ + "2025-01-04T12:01:01+05:30" + ] }, "version": { "description": "A single version of a product, as expressed in its own version numbering scheme.", @@ -345,7 +343,7 @@ }, "versions": { "type": "array", - "description": "Set of product versions or version ranges related to the vulnerability. The versions satisfy the CNA Rules [8.1.2 requirement](https://cve.mitre.org/cve/cna/rules.html#section_8-1_cve_entry_information_requirements). Versions or defaultStatus may be omitted, but not both.", + "description": "Set of product versions or version ranges related to the vulnerability. The versions help satisfy the CNA Rules [5.1.3 requirement](https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_5-1_Required_CVE_Record_Content). Versions or defaultStatus may be omitted, but not both.", "minItems": 1, "uniqueItems": true, "items": { @@ -465,7 +463,9 @@ "required": [ "cveId", "assignerOrgId", - "state" + "state", + "datePublished", + "dateReserved" ], "properties": { "cveId": { @@ -517,7 +517,9 @@ "required": [ "cveId", "assignerOrgId", - "state" + "state", + "datePublished", + "dateReserved" ], "properties": { "cveId": { @@ -743,7 +745,8 @@ "providerMetadata", "descriptions", "affected", - "references" + "references", + "datePublic" ], "patternProperties": { "^x_[^.]*$": {} @@ -924,6 +927,10 @@ ], "additionalProperties": false } + }, + "preformatted": { + "type": "boolean", + "description": "If true, indicates the 'description' is preformatted text that should be rendered to preserve spacing and other formatting. If false, will be rendered without preserving formatting." } }, "required": [ @@ -3239,7 +3246,6 @@ ], "properties": { "time": { - "description": "Timestamp representing when the event in the timeline occurred. The timestamp format is based on RFC3339 and ISO ISO8601, with an optional timezone. yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM - if the timezone offset is not given, GMT (+00:00) is assumed.", "$ref": "#/definitions/timestamp" }, "lang": { @@ -3305,7 +3311,38 @@ "source": { "type": "object", "description": "This is the source information (who discovered it, who researched it, etc.) and optionally a chain of CNA information (e.g. the originating CNA and subsequent parent CNAs who have processed it before it arrives at the MITRE root).\n Must contain: IF this is in the root level it MUST contain a CNA_chain entry, IF this source entry is NOT in the root (e.g. it is part of a vendor statement) then it must contain at least one type of data entry.", - "minProperties": 1 + "minProperties": 1, + "properties": { + "defect": { + "title": "Defects", + "type": "array", + "description": "CNA specific bug or defect tracking IDs (optional).", + "uniqueItems": true, + "items": { + "type": "string", + "maxLength": 64 + } + }, + "advisory": { + "title": "Advisory ID", + "type": "string", + "description": "CNA specific advisory IDs (optional).", + "maxLength": 64 + }, + "discovery": { + "type": "string", + "title": "Source of vulnerability discovery", + "enum": [ + "INTERNAL", + "EXTERNAL", + "USER", + "UPSTREAM", + "UNKNOWN" + ], + "description": "Source of vulnerability discovery. This may be a factor for some consumers in prioritizing vulnerability response. \nINTERNAL: this vulnerability was found by the CNA's internal research.\nEXTERNAL: this vulnerability was found during research external to a CNA.\nUSER: This vulnerability was discovered during product use.\nUPSTREAM: This vulnerability was found by an upstream vendor or producer.\nUNKNOWN: Source of discovery is not defined or is unknown", + "default": "UNKNOWN" + } + } }, "language": { "type": "string", @@ -3437,10 +3474,11 @@ } } }, + "type": "object", "properties": { "cnaContainer": { "$ref": "#/definitions/cnaPublishedContainer" } }, "additionalProperties": false -} +} \ No newline at end of file diff --git a/schema/docs/CVE_Record_Format_bundled_cnaRejectedContainer.json b/schema/docs/CVE_Record_Format_bundled_cnaRejectedContainer.json index d32f0da06ac..e9c32b19485 100644 --- a/schema/docs/CVE_Record_Format_bundled_cnaRejectedContainer.json +++ b/schema/docs/CVE_Record_Format_bundled_cnaRejectedContainer.json @@ -77,6 +77,7 @@ }, "cveId": { "type": "string", + "description": "The official CVE identifier contains the string 'CVE', followed by the year, followed by a 4 to 19 digit number. Note that the year-part of the identifier should indicate either the year the vulnerability was discovered, or the year the CVE ID is published in. CVE IDs must be unique.", "pattern": "^CVE-[0-9]{4}-[0-9]{4,19}$" }, "cpe22and23": { @@ -107,16 +108,13 @@ "minLength": 2, "maxLength": 32 }, - "datestamp": { - "description": "Date/time format based on RFC3339 and ISO ISO8601.", - "type": "string", - "format": "date", - "pattern": "^((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30))$" - }, "timestamp": { "type": "string", - "description": "Date/time format based on RFC3339 and ISO ISO8601, with an optional timezone in the format 'yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM'. If timezone offset is not given, GMT (+00:00) is assumed.", - "pattern": "^(((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30)))T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])(\\.[0-9]+)?(Z|[+-][0-9]{2}:[0-9]{2})?$" + "description": "Date/time format based on RFC3339 and ISO ISO8601, with a mandatory timezone in the format 'yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM'.", + "pattern": "^(((2000|2400|2800|(19|2[0-9](0[48]|[2468][048]|[13579][26])))-02-29)|(((19|2[0-9])[0-9]{2})-02-(0[1-9]|1[0-9]|2[0-8]))|(((19|2[0-9])[0-9]{2})-(0[13578]|10|12)-(0[1-9]|[12][0-9]|3[01]))|(((19|2[0-9])[0-9]{2})-(0[469]|11)-(0[1-9]|[12][0-9]|30)))T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])([+-][0-9]{2}:[0-9]{2})$", + "examples": [ + "2025-01-04T12:01:01+05:30" + ] }, "version": { "description": "A single version of a product, as expressed in its own version numbering scheme.", @@ -345,7 +343,7 @@ }, "versions": { "type": "array", - "description": "Set of product versions or version ranges related to the vulnerability. The versions satisfy the CNA Rules [8.1.2 requirement](https://cve.mitre.org/cve/cna/rules.html#section_8-1_cve_entry_information_requirements). Versions or defaultStatus may be omitted, but not both.", + "description": "Set of product versions or version ranges related to the vulnerability. The versions help satisfy the CNA Rules [5.1.3 requirement](https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_5-1_Required_CVE_Record_Content). Versions or defaultStatus may be omitted, but not both.", "minItems": 1, "uniqueItems": true, "items": { @@ -465,7 +463,9 @@ "required": [ "cveId", "assignerOrgId", - "state" + "state", + "datePublished", + "dateReserved" ], "properties": { "cveId": { @@ -517,7 +517,9 @@ "required": [ "cveId", "assignerOrgId", - "state" + "state", + "datePublished", + "dateReserved" ], "properties": { "cveId": { @@ -743,7 +745,8 @@ "providerMetadata", "descriptions", "affected", - "references" + "references", + "datePublic" ], "patternProperties": { "^x_[^.]*$": {} @@ -924,6 +927,10 @@ ], "additionalProperties": false } + }, + "preformatted": { + "type": "boolean", + "description": "If true, indicates the 'description' is preformatted text that should be rendered to preserve spacing and other formatting. If false, will be rendered without preserving formatting." } }, "required": [ @@ -3239,7 +3246,6 @@ ], "properties": { "time": { - "description": "Timestamp representing when the event in the timeline occurred. The timestamp format is based on RFC3339 and ISO ISO8601, with an optional timezone. yyyy-MM-ddTHH:mm:ss[+-]ZH:ZM - if the timezone offset is not given, GMT (+00:00) is assumed.", "$ref": "#/definitions/timestamp" }, "lang": { @@ -3305,7 +3311,38 @@ "source": { "type": "object", "description": "This is the source information (who discovered it, who researched it, etc.) and optionally a chain of CNA information (e.g. the originating CNA and subsequent parent CNAs who have processed it before it arrives at the MITRE root).\n Must contain: IF this is in the root level it MUST contain a CNA_chain entry, IF this source entry is NOT in the root (e.g. it is part of a vendor statement) then it must contain at least one type of data entry.", - "minProperties": 1 + "minProperties": 1, + "properties": { + "defect": { + "title": "Defects", + "type": "array", + "description": "CNA specific bug or defect tracking IDs (optional).", + "uniqueItems": true, + "items": { + "type": "string", + "maxLength": 64 + } + }, + "advisory": { + "title": "Advisory ID", + "type": "string", + "description": "CNA specific advisory IDs (optional).", + "maxLength": 64 + }, + "discovery": { + "type": "string", + "title": "Source of vulnerability discovery", + "enum": [ + "INTERNAL", + "EXTERNAL", + "USER", + "UPSTREAM", + "UNKNOWN" + ], + "description": "Source of vulnerability discovery. This may be a factor for some consumers in prioritizing vulnerability response. \nINTERNAL: this vulnerability was found by the CNA's internal research.\nEXTERNAL: this vulnerability was found during research external to a CNA.\nUSER: This vulnerability was discovered during product use.\nUPSTREAM: This vulnerability was found by an upstream vendor or producer.\nUNKNOWN: Source of discovery is not defined or is unknown", + "default": "UNKNOWN" + } + } }, "language": { "type": "string", @@ -3437,10 +3474,11 @@ } } }, + "type": "object", "properties": { "cnaContainer": { "$ref": "#/definitions/cnaRejectedContainer" } }, "additionalProperties": false -} +} \ No newline at end of file diff --git a/schema/docs/cnaContainer-advanced-example.json b/schema/docs/cnaContainer-advanced-example.json index 85f97195071..ba66aace74c 100644 --- a/schema/docs/cnaContainer-advanced-example.json +++ b/schema/docs/cnaContainer-advanced-example.json @@ -4,7 +4,7 @@ "orgId": "00000000-0000-4000-9000-000000000000" }, "title": "Buffer overflow in Example Enterprise allows Privilege Escalation.", - "datePublic": "2021-09-08T16:24:00.000Z", + "datePublic": "2021-09-08T16:24:00+03:00", "problemTypes": [ { "descriptions": [ @@ -259,17 +259,17 @@ ], "timeline": [ { - "time": "2001-09-01T07:31:00.000Z", + "time": "2001-09-01T07:31:00+03:00", "lang": "en", "value": "Issue discovered by Alice using Acme Autofuzz" }, { - "time": "2021-09-02T16:36:00.000Z", + "time": "2021-09-02T16:36:00+03:00", "lang": "en", "value": "Confirmed by Bob" }, { - "time": "2021-09-07T16:37:00.000Z", + "time": "2021-09-07T16:37:00+03:00", "lang": "en", "value": "Fixes released" } diff --git a/schema/docs/cnaContainer-basic-example.json b/schema/docs/cnaContainer-basic-example.json index 04ca59c65fd..e7370895cca 100644 --- a/schema/docs/cnaContainer-basic-example.json +++ b/schema/docs/cnaContainer-basic-example.json @@ -3,6 +3,7 @@ "providerMetadata": { "orgId": "00000000-0000-4000-9000-000000000000" }, + "datePublic": "2001-09-01T07:31:00+03:00", "problemTypes": [ { "descriptions": [ diff --git a/schema/docs/full-record-advanced-example.json b/schema/docs/full-record-advanced-example.json index d9c904c2c80..6a89646f21e 100644 --- a/schema/docs/full-record-advanced-example.json +++ b/schema/docs/full-record-advanced-example.json @@ -7,17 +7,19 @@ "assignerShortName": "example", "requesterUserId": "b3476cb9-2e3d-41a6-98d0-0f47421a65b6", "serial": 1, - "state": "PUBLISHED" + "state": "PUBLISHED", + "dateReserved": "2021-09-08T17:34:24+03:00", + "datePublished": "2021-09-08T17:34:24+03:00" }, "containers": { "cna": { "providerMetadata": { "orgId": "b3476cb9-2e3d-41a6-98d0-0f47421a65b6", "shortName": "example", - "dateUpdated": "2021-09-08T16:24:00.000Z" + "dateUpdated": "2021-09-08T16:24:00+03:00" }, "title": "Buffer overflow in Example Enterprise allows Privilege Escalation.", - "datePublic": "2021-09-08T16:24:00.000Z", + "datePublic": "2021-09-08T16:24:00+03:00", "problemTypes": [ { "descriptions": [ @@ -162,7 +164,7 @@ "value": "OS-komand-injekta vundebleco parseFilename funkcio de example.php en la Web Administrado-Interfaco de Example.org Example Enterprise ĉe Windows, macOS kaj XT-4500 permesas al malproksimaj neaŭtentikigitaj atakantoj eskaladi privilegiojn.

Ĉi tiu afero efikas:
  • 1.0-versioj antaŭ 1.0.6
  • 2.1-versioj de 2.1.6 ĝis 2.1.9.
" } ] - } + } ], "metrics": [ { @@ -272,17 +274,17 @@ ], "timeline": [ { - "time": "2001-09-01T07:31:00.000Z", + "time": "2001-09-01T07:31:00+03:00", "lang": "en", "value": "Issue discovered by Alice using Acme Autofuzz" }, { - "time": "2021-09-02T16:36:00.000Z", + "time": "2021-09-02T16:36:00+03:00", "lang": "en", "value": "Confirmed by Bob" }, { - "time": "2021-09-07T16:37:00.000Z", + "time": "2021-09-07T16:37:00+03:00", "lang": "en", "value": "Fixes released" } diff --git a/schema/docs/full-record-basic-example.json b/schema/docs/full-record-basic-example.json index 55e0b655a37..c9f204fd177 100644 --- a/schema/docs/full-record-basic-example.json +++ b/schema/docs/full-record-basic-example.json @@ -4,13 +4,16 @@ "cveMetadata": { "cveId": "CVE-1900-1234", "assignerOrgId": "b3476cb9-2e3d-41a6-98d0-0f47421a65b6", - "state": "PUBLISHED" + "state": "PUBLISHED", + "dateReserved": "2025-01-01T17:34:24+03:00", + "datePublished": "2025-01-01T17:34:24+03:00" }, "containers": { "cna": { "providerMetadata": { "orgId": "b3476cb9-2e3d-41a6-98d0-0f47421a65b6" }, + "datePublic": "2025-01-01T17:34:24+03:00", "problemTypes": [ { "descriptions": [ @@ -49,4 +52,4 @@ ] } } -} \ No newline at end of file +} diff --git a/schema/support/bundling-scripts/bundle-script-linux.sh b/schema/support/bundling-scripts/bundle-script-linux.sh old mode 100644 new mode 100755 diff --git a/schema/support/bundling-scripts/bundle-script-win.sh b/schema/support/bundling-scripts/bundle-script-win.sh old mode 100644 new mode 100755