Open MrSeccubus opened 2 years ago
Proposal is to make this an array with multiple versions and format's allowed. E.g.:
{
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
],
"score": [
{
"version": "3.1",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "LOW",
"userInteraction": "NONE",
"scope": "CHANGED",
"confidentialityImpact": "LOW",
"integrityImpact": "HIGH",
"availabilityImpact": "NONE",
"baseScore": 8.5,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N"
}
]
},
Other scores such as SSVC #144 can also become part of a scores array when the CVE schema v6.0 or next major update is being considered.
Vijay
Changing the cvssV*
properties would be a backwards compatibility breaking change. As a result, we will need to wait until v6.0 to make this change.
Does that imply that if a new version of CVSS is released it cannot be adopted unless a new version of CVE records is released too?
No. Adding a new optional field is not a breaking change. It will not break any of the existing tools to produce/consume records. It will be done in a schema minor release 5.x.
Removing a field on the other hand means existing tools will produce a JSON that no longer validates, which means CNAs will have to change their tooling.
See: https://github.com/Vulnogram/Vulnogram/issues/64
CVSS record forat is:
This means that when the CVSS version changes to e.g. v3.2 the tag changes as well, meaning I have to update the code that renders CVEs records on https://csirt.divd.nl.
Having a version number as part of a tag is generally considered bad practice.