Skip to content

Add support for Package URLs #397

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
131 changes: 123 additions & 8 deletions schema/CVE_Record_Format.json
Original file line number Diff line number Diff line change
Expand Up @@ -212,7 +212,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. NOTE: Consider using the newer cpeApplicability block for defining CPE data using the CPE Applicability Language which includes more options for defining CPE Names.",
"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. NOTE: Consider using the newer applicability block for defining CPE data using the CPE Applicability Language which includes more options for defining CPE Names.",
"uniqueItems": true,
"items": {
"title": "CPE Name",
Expand Down Expand Up @@ -500,6 +500,93 @@
"required": ["orgId"],
"additionalProperties": false
},
"applicability": {
"type": "array",
"items": {
"$ref": "#/definitions/applicabilityElement"
}
},
"applicabilityElement": {
"description": "Affected products defined using one or more software identifiers and applicability parameters. An operator property allows AND or OR logic between identifiers or combinations thereof. The negate and vulnerable Boolean properties allow applicability combinations to be inverted and/or defined as vulnerable or not. Multiple version fields are provided for capturing ranges of products when defining a Match String Range. NOTE: When defining an applicability block, it is recommended that it align with (as much as possible) the product data provided within the affected block.",
"properties": {
"operator": {
"type": "string",
"enum": ["AND", "OR"]
},
"negate": {
"type": "boolean"
},
"nodes": {
"type": "array",
"items": {
"$ref": "#/definitions/node"
}
}
}
},
"node": {
"description": "Defines a configuration node in an applicability statement.",
"properties": {
"operator": {
"type": "string",
"enum": ["AND", "OR"]
},
"negate": {
"type": "boolean"
},
"cpeMatch": {
"type": "array",
"items": {
"$ref": "#/definitions/cpe_match"
}
},
"purlMatch": {
"type": "array",
"items": {
"$ref": "#/definitions/purl_match"
}
}
},
"allOf": [
{ "required": ["operator"] },
{
"anyOf": [
{ "required": ["cpeMatch"] },
{ "required": ["purlMatch"] }

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use purl_match?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, this appears to be a naming error. Will correct it.

]
}
]
},
"purl_match": {
"description": "purl match string or range",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean by purl_match?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

purl_match is the internal name of the object type as it exists in the schema, it is not a user-facing name, and is named thus to stylistically match the equivalent existing cpe_match structure.

"type": "object",
"properties": {
"vulnerable": {
"type": "boolean"
},
"criteria": {
"description": "Placeholder until we find a formal purl schema",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you elaborate?

"$ref": "#/definitions/uriType"
},
"matchCriteriaId": {
"$ref": "#/definitions/uuidType"
},
"versionStartExcluding": {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, our plan is to not use the vers spec, but instead to reuse the existing mechanism for expressing version constraints used for CPE. We expect this will both be easier to existing consumers of CVE data and will mitigate concerns around the vers spec's readiness for production use.

"$ref": "#/definitions/version"
},
"versionStartIncluding": {
"$ref": "#/definitions/version"
},
"versionEndExcluding": {
"$ref": "#/definitions/version"
},
"versionEndIncluding": {
"$ref": "#/definitions/version"
}
},
"required": ["vulnerable", "criteria"],
"additionalProperties": false
},
"cpeApplicabilityElement": {
"description": "Affected products defined using an implementation of the CPE Applicability Language, mostly copied/forked from the NIST NVD CVE API v2.0 schema (optional). An operator property allows AND or OR logic between CPEs or combinations of CPEs. The negate and vulnerable Boolean properties allow CPEs to be inverted and/or defined as vulnerable or not. Multiple version fields are provided for capturing ranges of products when defining a CPE Match String Range. NOTE: When defining a cpeApplicability block, it is recommended that it align with (as much as possible) the product data provided within the affected block.",
"properties": {
Expand Down Expand Up @@ -608,6 +695,12 @@
"affected": {
"$ref": "#/definitions/affected"
},
"applicability": {
"type": "array",
"items": {
"$ref": "#/definitions/applicabilityElement"
}
},
"cpeApplicability": {
"type": "array",
"items": {
Expand Down Expand Up @@ -654,11 +747,20 @@
"$ref": "#/definitions/taxonomyMappings"
}
},
"required": [
"providerMetadata",
"descriptions",
"affected",
"references"
"allOf": [
{
"required": [
"providerMetadata",
"descriptions",
"affected",
"references"
]
},
{
"not": {
"required": ["applicability", "cpeApplicability"]
}
}
],
"patternProperties": {
"^x_[^.]*$": {}
Expand Down Expand Up @@ -720,6 +822,12 @@
"affected": {
"$ref": "#/definitions/affected"
},
"applicability": {
"type": "array",
"items": {
"$ref": "#/definitions/applicabilityElement"
}
},
"cpeApplicability": {
"type": "array",
"items": {
Expand Down Expand Up @@ -766,8 +874,15 @@
"$ref": "#/definitions/taxonomyMappings"
}
},
"required": [
"providerMetadata"
"allOf": [
{
"required": ["providerMetadata"]
},
{
"not": {
"required": ["applicability", "cpeApplicability"]
}
}
],
"minProperties": 2,
"patternProperties": {
Expand Down