validation fails because of rounding in anyOf/baseScore/baseSeverity

[ElectricNroff]

A large fraction of valid CNA containers with CVSS scores get

"error":"INVALID_JSON_SCHEMA","message":"CVE cnaContainer JSON schema validation FAILED."

when submitting to CVE Services 2.3.0. For example, although the CVSS "LOW" range is 0.1 through 3.9, "LOW" works with a 2.2 CVSS score but does not work with a 2.3 CVSS score. This occurs because schema validation uses ajv without a mitigation for IEEE 754 rounding rules. The CVE Records (regardless of 2.2 versus 2.3) do validate with some other JSON validators such as jsonschemavalidator.net (when using exactly the same schema) but it will probably be necessary to continue using ajv to avoid large software integration costs and to maintain the user experience for error messages.

Solutions might include:

1. try one of the workarounds discussed at Validation of multipleOf keyword with decimal numbers ajv-validator/ajv#652 such as use of the number-precision package (note that https://github.com/nefe/number-precision is perhaps not actively maintained, is not widely used, and has unresolved bug reports)
2. look for other solutions that are compatible with ajv
3. do not use multipleOf and simply accept the risk that a provider may enter more than one decimal digit such as an anomalous CVSS score of 2.25
4. remove all comparisons of baseScore and baseSeverity from the current release, and research solutions later

(options 3 and 4 mean that CVE Services would be less strict than the schema advocated by the QWG)

We could instead ask FIRST to change their CVSS schema to use approaches like:

"lowScoreType": {
  "type": "number",
  "enum": [0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9, 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9]
},

which may make it interoperable with both ajv and a number of other schema validators.

This affects, for example, both CVSS 3.1 and CVSS 4.0 because CVE Services is implementing baseScore/baseSeverity checks for both in essentially the same way. The baseScore/baseSeverity checks for CVSS 4.0 in CVE Services are inherently part of https://www.first.org/cvss/cvss-v4.0.json and thus it's not possible to use ajv as-is and still comply with the FIRST specification.

Note that the problem is not limited to CNAs who intentionally choose strange CVSS scores. A CNA who simply goes to Vulnogram, and clicks on the buttons under Metrics in a completely normal way, will often end up with a CNA container that cannot successfully be submitted to CVE Services, even though it's in exactly the correct format according to the schema. In other words, addressing this GitHub issue is almost certainly a blocker for the production release.

It is also easy to reproduce the issue from a command line. For example, this CNA container can be submitted:

{"cnaContainer":{"providerMetadata": {
"orgId": "00000000-0000-4000-9000-000000000000"},
"affected": [{"vendor": "v","product": "p",
"defaultStatus": "affected"}],
"descriptions": [{"lang": "en","value": "abc def ghi"}],
"metrics": [{"format": "CVSS","scenarios": [{"lang": "en","value": "GENERAL"}],
"cvssV4_0": {
"baseScore": 2.2,
"baseSeverity": "LOW",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:L",
"version": "4.0"
}}],
"references": [{
"url": "https://example.org/ESA-22-11-CVE-1337-1234"}]}}

but this one cannot (it gets the INVALID_JSON_SCHEMA error) even though the only difference is increasing 2.2 to 2.3:

{"cnaContainer":{"providerMetadata": {
"orgId": "00000000-0000-4000-9000-000000000000"},
"affected": [{"vendor": "v","product": "p",
"defaultStatus": "affected"}],
"descriptions": [{"lang": "en","value": "abc def ghi"}],
"metrics": [{"format": "CVSS","scenarios": [{"lang": "en","value": "GENERAL"}],
"cvssV4_0": {
"baseScore": 2.3,
"baseSeverity": "LOW",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:L",
"version": "4.0"
}}],
"references": [{
"url": "https://example.org/ESA-22-11-CVE-1337-1234"}]}}

[pandatix]

Hi, as it seems to be an issue related to ajv-validator/ajv#652 I don't think it is the FIRST responsibility to come up with a variant of the current JSON schema to avoid a bug in another spec (JSON Schema) implementation.

As with this we end up in a dead end, I see two options: the CVEProject overloads the FIRST Schema to fit its own implementation details (might not be a good idea for many reasons), or overload the multipleOf as suggested by 1. Another but less realistic is 2.

[ElectricNroff]

The rationale for asking FIRST to change their schema is that use of multipleOf with floating point is a known interoperability problem with JSON schema that has affected multiple validator implementations over about the past ten years, and a change could benefit their wider community, e.g.,

https://swagger.io/docs/specification/data-models/data-types/ (recommendation from the Swagger project: "multipleOf may be used with floating-point numbers, but in practice this can be unreliable due to the limited precision or floating point math.")

https://news.ycombinator.com/item?id=34588911 (2023)
json-schema-org/json-schema-spec#312 (comment) (2017)
python-jsonschema/jsonschema#247 (2015)