RSUS accepts contradictory CVSS 3.1 data

[ElectricNroff]

This issue does not report a defect in CVE Services as the requirements are currently understood; however, there is some community interest in having business rules enforced at the RSUS API layer, and it is conceivable that new requirements may arise.

Yesterday, Microsoft successfully submitted data (shown at the https://cveawg.mitre.org/api/cve/CVE-2023-23374 URL) of

"cvssV3_1":{"version":"3.1","baseSeverity":"MEDIUM","baseScore":8.3,
"vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C"}

This is not allowed by the CVSS 3.1 specification:

https://www.first.org/cvss/specification-document
5. Qualitative Severity Rating Scale

Medium    4.0 - 6.9

High    7.0 - 8.9

Here, 8.3 is the correct baseScore, but baseSeverity must be HIGH, not MEDIUM.

[zmanion]

From 2023-02-28 AWG meeting, taking no action for hard-deploy, forward to QWG.

[zmanion]

JSON 5.0 schema checks for valid CVSS values, but does not enforce CVSS math/logic.

One other discussion item: The Program or another party may choose to perform various quality checks, such as CVSS math/logic validation. Quality issues could be flagged and fed back to the owning CNA/ADP.

[zmanion]

SPWG today agreed with the AWG proposal to reject upon submission CVE JSON with mismatched CVSS baseScore and baseSeverity. With an appropriatly clear error message.

[chandanbn]

Looks like it would be simple to enforce matching score and severity with a small schema refactoring as suggested below. Split definitions of scoreType and severityType into five definitions and use oneOf construct. This does not solve mismatched vector and score, since that would require either implementing the calculator math logic/code in a schema. JSON-schema doesn't allow embedding arbitrary code for a reason.

{
 "title": "Experimental: match CVSS score and severity", 
  "type": "object",
  "definitions": {
    "noneScoreType": {
      "const": 0,
    },
    "lowScoreType": {
      "type": "number",
      "minimum": 0.1,
      "maximum": 3.9,
      "multipleOf": 0.1
    },
    "mediumScoreType": {
      "type": "number",
      "minimum": 4.0,
      "maximum": 6.9,
      "multipleOf": 0.1
    },
    "highScoreType": {
      "type": "number",
      "minimum": 7.0,
      "maximum": 8.9,
      "multipleOf": 0.1
    },
    "criticalScoreType": {
      "type": "number",
      "minimum": 9.0,
      "maximum": 10,
      "multipleOf": 0.1
    },
    "noneSeverityType": {
      "const": "NONE"
    },
    "lowSeverityType": {
      "const": "LOW"
    },
    "mediumSeverityType": {
      "const": "MEDIUM"
    },
    "highSeverityType": {
      "const": "HIGH"
    },
    "criticalSeverityType": {
      "const": "CRITICAL"
    }
  },
  "properties": {
    "version": {
      "description": "CVSS Version",
      "type": "string",
      "enum": [
        "4.0"
      ]
    },
  },
  "oneOf": [
    {
      "properties": {
        "baseScore" : {
          "$ref": "#/definitions/noneScoreType"
        },
        "baseSeverity" : {
          "$ref": "#/definitions/noneSeverityType"
        }
      }
    },
    {
      "properties": {
        "baseScore" : {
          "$ref": "#/definitions/lowScoreType"
        },
        "baseSeverity" : {
          "$ref": "#/definitions/lowSeverityType"
        }
      }
    },
    {
      "properties": {
        "baseScore" : {
          "$ref": "#/definitions/mediumScoreType"
        },
        "baseSeverity" : {
          "$ref": "#/definitions/mediumSeverityType"
        }
      }
    },
    {
      "properties": {
        "baseScore" : {
          "$ref": "#/definitions/highScoreType"
        },
        "baseSeverity" : {
          "$ref": "#/definitions/highSeverityType"
        }
      }
    },
    {
      "properties": {
        "baseScore" : {
          "$ref": "#/definitions/criticalScoreType"
        },
        "baseSeverity" : {
          "$ref": "#/definitions/criticalSeverityType"
        }
      }
    }
  ],
  "required": [
    "version",
    "baseScore",
    "baseSeverity"
  ]
}

[andrewpollock]

This does not solve mismatched vector and score, since that would require either implementing the calculator math logic/code in a schema

I think you've reached the limits of what can be validated by the schema. Is there a particular reason for not just doing this validation in code in RSUS at submission time?

[chandanbn]

Yes that math check is best done by RSUS and throw an error (don't accept the submission) if score and vectors don't match.

Clients (cve-lib, cvelint, Vulnogram) doing the check before submission should reduce round trips to RSUS.

[zmanion]

For the record, this is payment on technical debt of supporting optional data (CVSS in this case) that is arguably not necessary to meet the CVE mission of identifing publicly disclosed vulnerabilities. There's no such thing as free optional data lunch.

[zmanion]

From today's AWG meeting, raise this to the CVE Board for guidance on whether and how to validate optional data elements.

Regardless of the source, poor quality data in CVE Records reflects badly on the CVE Program.

Stop supporting optional data?
Declare that all optional data is not validated?
Chose to validate on a case-by-case basis?

[andrewpollock]

Come up with a plan to progressively up-level the data quality, reinforced by automation, and implement it?

[jdaigneau5]

Closed by #1190