Discuss whether Cve-Services should enforce/validate affected versions

[jdaigneau5]

Summary

Affected versions in the 5.0 schema follow a semantic versioning pattern, which could be validated by Cve-Services, but currently is not because it's an optional field. However, this allows invalid semantic versions to be submitted in CVE records.

Definition of Done

• Discuss whether Cve-Services should validate and enforce affected version field

Note
This is related to an overall discussion about whether optional fields should be validated by Cve-Services at all or not.

[andrewpollock]

Ultimately, I would very much love to see such enforcement happen. Where it becomes impossible to sufficiently validate the version by schema specification alone, CVE Services could then get involved at submission time, but ideally a record author would have a pretty clear idea of how their record is going to be treated by CVE Services by offline validation against the schema, prior to submission.

My thoughts on how to get to this state:

1. A future revision of the JSON schema (say 5.2.0) defines what values are acceptable for affected[].versions[].versionType and how these values influence expectations of the values of

• affected[].versions[].version
• affected[].versions[].lessThan
• affected[].versions[].lessThanOrEqual

2. Generation tools like Vulnogram then start adhering with the schema on this (I note today that Vulnogram seems to have its own idea of what it will generate that may be above and beyond what the schema mandates today)
3. CVE Services continues(?) to enforce schema compliance

[jdaigneau5]

Note from 4/16/24 AWG: Discussed having smaller subschemas for validating versions. Could be warnings at first, and potentially incorporated into main schema in following releases.

[mprpic]

Note from AWG meeting on Jul 30, 2024: this issue is actively being discussed in QWG issues CVEProject/cve-schema#263, CVEProject/cve-schema#264, CVEProject/cve-schema#279, and others. Nothing actionable for AWG right now. Schema-specific enforcement of data quality should be preferred over any backend-implemented validation rules. For example, if semver version data should be validated, it can be enforced at the schema level with a specific regex that checks for valid semver versions.