METABUG: Potential concrete data quality improvements for 5.2.0 #298

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?