Skip to content

Commit

Permalink
Fix typos in descriptions, add one more example to platforms.
Browse files Browse the repository at this point in the history
No structural changes.
  • Loading branch information
chandanbn committed Oct 26, 2022
1 parent bd2b0cd commit f8f54d5
Show file tree
Hide file tree
Showing 3 changed files with 24 additions and 22 deletions.
16 changes: 8 additions & 8 deletions schema/v5.0/CVE_JSON_5.0_schema.json
Original file line number Diff line number Diff line change
Expand Up @@ -121,7 +121,7 @@
"maxLength": 2048
},
"collectionURL": {
"description": "URL identifying a package collection (determines meaning of packageName).",
"description": "URL identifying a package collection (determines the meaning of packageName).",
"$ref": "#/definitions/uriType",
"examples": [
"https://access.redhat.com/downloads/content/package-browser",
Expand Down Expand Up @@ -197,7 +197,7 @@
},
"cpes": {
"type": "array",
"description": "Affected products defined by CPE. This is an array of CPE values (vulnerable and not), we use an array so that we can make multiple statements about the same version and they are separate (if we used a JSON object we'd essentially be keying on the CPE name and they would have to overlap). Also this allows things like cveDataVersion or cveDescription to be applied directly to the product entry. This also allows more complex statements such as \"Product X between versions 10.2 and 10.8\" to be put in a machine-readable format. As well since multiple statements can be used multiple branches of the same product can be defined here.",
"description": "Affected products defined by CPE. This is an array of CPE values (vulnerable and not), we use an array so that we can make multiple statements about the same version and they are separate (if we used a JSON object we'd essentially be keying on the CPE name and they would have to overlap). Also, this allows things like cveDataVersion or cveDescription to be applied directly to the product entry. This also allows more complex statements such as \"Product X between versions 10.2 and 10.8\" to be put in a machine-readable format. As well since multiple statements can be used multiple branches of the same product can be defined here.",
"uniqueItems": true,
"items": {
"title": "CPE Name",
Expand Down Expand Up @@ -236,7 +236,7 @@
"uniqueItems": true,
"items": {
"type": "object",
"description": "Object describing program routine.",
"description": "An object describing program routine.",
"required": [
"name"
],
Expand All @@ -252,13 +252,13 @@
},
"platforms": {
"title": "Platforms",
"description": "List of specific platforms if the vulnerability is only relevant in the context of these platforms (optional). Platforms may include execution environments, operating systems, virtualization technologies, hardware models, or computing architectures. Lack of this field or an empty array implies that the other fields are applicable for all relevant platforms.",
"description": "List of specific platforms if the vulnerability is only relevant in the context of these platforms (optional). Platforms may include execution environments, operating systems, virtualization technologies, hardware models, or computing architectures. The lack of this field or an empty array implies that the other fields are applicable to all relevant platforms.",
"type": "array",
"minItems": 1,
"uniqueItems": true,
"items": {
"type": "string",
"examples": ["iOS", "Android", "Windows", "macOS", "x86", "ARM", "64 bit", "Big Endian", "iPad", "Chromebook", "Docker"],
"examples": ["iOS", "Android", "Windows", "macOS", "x86", "ARM", "64 bit", "Big Endian", "iPad", "Chromebook", "Docker", "Model T"],
"maxLength": 1024
}
},
Expand Down Expand Up @@ -497,7 +497,7 @@
},
"title": {
"type": "string",
"description": "A title, headline, or a brief phrase summarizing the of the CVE record. Eg., Buffer overflow in Example Soft.",
"description": "A title, headline, or a brief phrase summarizing the CVE record. Eg., Buffer overflow in Example Soft.",
"minLength": 1,
"maxLength": 256
},
Expand Down Expand Up @@ -848,7 +848,7 @@
"properties": {
"format": {
"type": "string",
"description": "Name of the score format. This provides a bit future proofing. Additional properties are not prohibited, so this will support inclusion of proprietary formats. It also provides an easy future conversion mechanism when future score formats become part of the schema. example: cvssV4_4, format = 'cvssV4_4', other = cvssV4_4 json object. In the future the other properties can be converted to score properties when they become part of the schema.",
"description": "Name of the scoring format. This provides a bit of future proofing. Additional properties are not prohibited, so this will support the inclusion of proprietary formats. It also provides an easy future conversion mechanism when future score formats become part of the schema. example: cvssV44, format = 'cvssV44', other = cvssV4_4 JSON object. In the future, the other properties can be converted to score properties when they become part of the schema.",
"minLength": 1,
"maxLength": 64
},
Expand Down Expand Up @@ -1146,7 +1146,7 @@
"$ref": "#/definitions/cveMetadataPublished"
},
"containers": {
"description": "A set of structures (called containers) used to store vulnerability information related to a specific CVE ID provided by a specific organization participating in the CVE program. Each container includes information provided by a different source.\n\nAt minimum, a 'cna' container containing the vulnerability information provided by the CNA who initially assigned the CVE ID must be included.\n\nThere can only be one 'cna' container, as there can only be one assigning CNA. However, there can be multiple 'adp' containers, allowing multiple organizations participating in the CVE program to add additional information related to the vulnerability. For the most part, the 'cna' and 'adp' containers contain the same properties. The main differences are the source of the information and the 'cna' container requires the CNA include certain fields, while the 'adp' container does not.",
"description": "A set of structures (called containers) used to store vulnerability information related to a specific CVE ID provided by a specific organization participating in the CVE program. Each container includes information provided by a different source.\n\nAt a minimum, a 'cna' container containing the vulnerability information provided by the CNA who initially assigned the CVE ID must be included.\n\nThere can only be one 'cna' container, as there can only be one assigning CNA. However, there can be multiple 'adp' containers, allowing multiple organizations participating in the CVE program to add additional information related to the vulnerability. For the most part, the 'cna' and 'adp' containers contain the same properties. The main differences are the source of the information. The 'cna' container requires the CNA to include certain fields, while the 'adp' container does not.",
"type": "object",
"properties": {
"cna": {"$ref": "#/definitions/cnaPublishedContainer"},
Expand Down
19 changes: 10 additions & 9 deletions schema/v5.0/docs/CVE_JSON_5.0_bundled.json
Original file line number Diff line number Diff line change
Expand Up @@ -169,7 +169,7 @@
"maxLength": 2048
},
"collectionURL": {
"description": "URL identifying a package collection (determines meaning of packageName).",
"description": "URL identifying a package collection (determines the meaning of packageName).",
"$ref": "#/definitions/uriType",
"examples": [
"https://access.redhat.com/downloads/content/package-browser",
Expand Down Expand Up @@ -245,7 +245,7 @@
},
"cpes": {
"type": "array",
"description": "Affected products defined by CPE. This is an array of CPE values (vulnerable and not), we use an array so that we can make multiple statements about the same version and they are separate (if we used a JSON object we'd essentially be keying on the CPE name and they would have to overlap). Also this allows things like cveDataVersion or cveDescription to be applied directly to the product entry. This also allows more complex statements such as \"Product X between versions 10.2 and 10.8\" to be put in a machine-readable format. As well since multiple statements can be used multiple branches of the same product can be defined here.",
"description": "Affected products defined by CPE. This is an array of CPE values (vulnerable and not), we use an array so that we can make multiple statements about the same version and they are separate (if we used a JSON object we'd essentially be keying on the CPE name and they would have to overlap). Also, this allows things like cveDataVersion or cveDescription to be applied directly to the product entry. This also allows more complex statements such as \"Product X between versions 10.2 and 10.8\" to be put in a machine-readable format. As well since multiple statements can be used multiple branches of the same product can be defined here.",
"uniqueItems": true,
"items": {
"title": "CPE Name",
Expand Down Expand Up @@ -284,7 +284,7 @@
"uniqueItems": true,
"items": {
"type": "object",
"description": "Object describing program routine.",
"description": "An object describing program routine.",
"required": [
"name"
],
Expand All @@ -300,7 +300,7 @@
},
"platforms": {
"title": "Platforms",
"description": "List of specific platforms if the vulnerability is only relevant in the context of these platforms (optional). Platforms may include execution environments, operating systems, virtualization technolgies, hardware models, or computing architectures. Lack of this field or an empty array implies that the other fields are applicable for all relevant platforms.",
"description": "List of specific platforms if the vulnerability is only relevant in the context of these platforms (optional). Platforms may include execution environments, operating systems, virtualization technologies, hardware models, or computing architectures. The lack of this field or an empty array implies that the other fields are applicable to all relevant platforms.",
"type": "array",
"minItems": 1,
"uniqueItems": true,
Expand All @@ -317,7 +317,8 @@
"Big Endian",
"iPad",
"Chromebook",
"Docker"
"Docker",
"Model T"
],
"maxLength": 1024
}
Expand Down Expand Up @@ -582,7 +583,7 @@
},
"title": {
"type": "string",
"description": "A title, headline, or a brief phrase summarizing the of the CVE record. Eg., Buffer overflow in Example Soft.",
"description": "A title, headline, or a brief phrase summarizing the CVE record. Eg., Buffer overflow in Example Soft.",
"minLength": 1,
"maxLength": 256
},
Expand Down Expand Up @@ -656,7 +657,7 @@
},
"replacedBy": {
"type": "array",
"description": "Contains an array of CVE IDs that this CVE ID was rejected in favor of because the this CVE ID was assigned to the vulnerabilities.",
"description": "Contains an array of CVE IDs that this CVE ID was rejected in favor of because this CVE ID was assigned to the vulnerabilities.",
"minItems": 1,
"uniqueItems": true,
"items": {
Expand Down Expand Up @@ -961,7 +962,7 @@
"properties": {
"format": {
"type": "string",
"description": "Name of the score format. This provides a bit future proofing. Additional properties are not prohibitied, so this will support inclusion of proprietary formats. It also provides an easy future conversion mechanism when future score formats become part of the schema. example: cvssV4_4, format = 'cvssV4_4', other = cvssV4_4 json object. In the future the other properties can be converted to score properties when they become part of the schema.",
"description": "Name of the scoring format. This provides a bit of future proofing. Additional properties are not prohibited, so this will support the inclusion of proprietary formats. It also provides an easy future conversion mechanism when future score formats become part of the schema. example: cvssV44, format = 'cvssV44', other = cvssV4_4 JSON object. In the future, the other properties can be converted to score properties when they become part of the schema.",
"minLength": 1,
"maxLength": 64
},
Expand Down Expand Up @@ -1966,7 +1967,7 @@
"$ref": "#/definitions/cveMetadataPublished"
},
"containers": {
"description": "A set of structures (called containers) used to store vulnerability information related to a specific CVE ID provided by a specific organization participating in the CVE program. Each container includes information provided by a different source.\n\nAt minimum, a 'cna' container containing the vulnerability information provided by the CNA who initially assigned the CVE ID must be included.\n\nThere can only be one 'cna' container, as there can only be one assigning CNA. However, there can be multiple 'adp' containers, allowing multiple organizations participating in the CVE program to add additional information related to the vulnerability. For the most part, the 'cna' and 'adp' containers contain the same properties. The main differences are the source of the information and the 'cna' container requires the CNA include certain fields, while the 'adp' container does not.",
"description": "A set of structures (called containers) used to store vulnerability information related to a specific CVE ID provided by a specific organization participating in the CVE program. Each container includes information provided by a different source.\n\nAt a minimum, a 'cna' container containing the vulnerability information provided by the CNA who initially assigned the CVE ID must be included.\n\nThere can only be one 'cna' container, as there can only be one assigning CNA. However, there can be multiple 'adp' containers, allowing multiple organizations participating in the CVE program to add additional information related to the vulnerability. For the most part, the 'cna' and 'adp' containers contain the same properties. The main differences are the source of the information. The 'cna' container requires the CNA to include certain fields, while the 'adp' container does not.",
"type": "object",
"properties": {
"cna": {
Expand Down
11 changes: 6 additions & 5 deletions schema/v5.0/docs/index.html

Large diffs are not rendered by default.

0 comments on commit f8f54d5

Please sign in to comment.