JSON5.0 - CVSS hard coded version numbers

[MrSeccubus]

See: https://github.com/Vulnogram/Vulnogram/issues/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.