Open jdaigneau5 opened 12 months ago
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:
affected[].versions[].versionType
and how these values influence expectations of the values of
affected[].versions[].version
affected[].versions[].lessThan
affected[].versions[].lessThanOrEqual
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.
Note from AWG meeting on Jul 30, 2024: this issue is actively being discussed in QWG issues https://github.com/CVEProject/cve-schema/issues/263, https://github.com/CVEProject/cve-schema/issues/264, https://github.com/CVEProject/cve-schema/issues/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.
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
Note This is related to an overall discussion about whether optional fields should be validated by Cve-Services at all or not.