JSON5.0 - CVSS hard coded version numbers

[MrSeccubus]

See: Vulnogram/Vulnogram#64

CVSS record forat is:

        {
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ],
          "cvssV3_1": {
            "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"
          }
        },

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.

[MrSeccubus]

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"
          }
          ]
        },

[sei-vsarvepalli]

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

[david-waltermire]

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.

[MrSeccubus]

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?

[chandanbn]

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.

[chandanbn]

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.

[ccoffin]

While this request is perfectly valid and probably the better approach, changing this would break all previous content. We will not implement this currently. We may want to reconsider this and other CVSS changes in a major/model update.