METABUG: Potential concrete data quality improvements for 5.2.0

[andrewpollock]

I thought I'd capture an umbrella issue for discussing a package of improvements for 5.2.0

A possible use-case based approach:

Use case 1: "Does this vulnerability apply to me?" "How do I make it not apply to me?"

• I have a programmatic way to identify the subject of the vulnerability
  • I can cross-reference the product against an inventory of products I am concerned about
  • I can scan a software source repository
    • 5.1.0 accepts versionType git without a Git commit hash #279
    • 5.1.0 allows use of versionType git without a repo field #280
  • I can scan a container image or other installation of software binary artefacts
• I have a way to programmatically determine the version of the subject the vulnerability applies to
  • I can determine if the installed version of software is affected by a vulnerability
    • 5.1.0 accepts versionType semver for non-semver data #263
    • 5.1.0 accepts versionType semver for non-semver lessThan #264

Use case 2: "How do I prioritize the vulnerabilities that apply to me?"

• I have CVSS, EPSS etc scores to stack rank the vulnerabilities identifiable from use case 1, so that I can determine the next steps for responding to them

Use case 3: "How can I perform aggregate, historical analytics on the vulnerabilities that apply/did apply to me?"

• I can broadly bucket vulnerabilities to answer questions like "How many memory safety vulnerabilities impacted me last year?"

Some other general input validation issues worth noting here:

• 5.1.0 accepts undefined properties under "affected" #259
• 5.1.0 accepts language of "eng" (instead of "en") in most places #260
• 5.1.0 accepts an object (instead of a string) for source.discovery #261

Related validation work happening elsewhere:

• mprpic/cvelint as of v0.3.0 is able to surface some of these failures (/cc @mprpic for further inspiration)
  • these are automatically surfaced at jgamblin/cvelint-action
• Discuss whether Cve-Services should enforce/validate affected versions cve-services#1135
  • Can we actively avoid needing to address this sequentially, to be able to make some tangible improvements to CVE data quality with a sense of urgency?

[jayjacobs]

@andrewpollock Maybe I am missing something, but this looks like a collection other issues and is not a unique request on its own. I would move to close this and we can group relevant issues with labels and milestones (hopefully in the next few weeks). Let me know if you have different thoughts.

[andrewpollock]

The overarching request here is for a future version of the schema to enable records to meet the three use cases described.

This could be achieved incrementally, by addressing one use case at a time.

Happy for this outcome to be reached by the most appropriate means.