Need CVE auto-linking disambiguation to CVEs that belong to more than 1 project

[joakime]

Description:

A CVE reference auto-linking should not link to a Github advisory if Github didn't assign the CVE ID (meaning the CVE came from somewhere else).
These kinds of CVE auto-linking should instead link to the MITRE (or other online CVE database) for that entry instead.
This will make it obvious that the CVE is bigger than the one project on github that is using the existing CVE id to update the impacted packages entries.

History:

The recent big CVE, CVE-2023-44487 (HTTP/2 Rapid Reset) was originally filed as a spec level CVE (against the HTTP/2 spec itself).

Over time, many projects have referenced CVE-2023-44487 in discussions, pull requests, issues, etc.

The use of CVE-2023-4487 auto-links to the GHSA-qppj-fm5r-hxr3 advisory, which is for a limited set of impacted packages on the swift-nio-http2 project. (see long listing of impacted packages at https://nvd.nist.gov/vuln/detail/CVE-2023-44487)
See concern brought up at #2860

This results in confusing links to an unrelated project and advisory.

Examples in Discussions:

• Container Image - v2.3.5 Azure/api-management-self-hosted-gateway#255

Examples in Release Notes:

• https://github.com/jetty/jetty.project/releases/tag/jetty-12.0.2

Examples in Issues:

• Impacted by CVE-2023-44487? linkedin/cruise-control#2070

Examples in PRs:

• Fixes #10679 - Review HTTP/2 rate control (CVE-2023-44487) jetty/jetty.project#10682
• OCPBUGS-20388: fix: CVE-2023-44487 openshift/lvm-operator#452
• [RHODS-12555] - CVE-2023-44487 opendatahub-io/rest-proxy#20
• Document non-impact of CVE-2023-44487 apache/httpd-site#10

[joakime]

Some other github advisories referring to CVE-2023-44487

• GHSA-qppj-fm5r-hxr3 - using the assigned CVE ID field as CVE-2023-44487
• GHSA-xpw8-rcwv-8f8p - simply a reference in the description
• GHSA-vx74-f528-fxqg - a reference in the description
• GHSA-2m7v-gc89-fjqf - using CVE-2023-44487 as the assigned CVE ID

[dpippenger]

The github advisory database seems to be enforcing a 1:1 mapping of CVE ID to software project, see here #2868 The problem this creates is the NVD doesn't have this limitation. The CPE data for https://nvd.nist.gov/vuln/detail/CVE-2023-44487 spans a number of software projects including all of the referenced GHSA above.

This seems like something that could use a redesign to both address the disambiguation of links as well as making the GHSA metadata more accurate by allowing for multiple GHSA to reference the same CVE ID when it makes sense. The implication is downstream tools that consume the advisory-database currently have no way indicate these various GHSA all refer to https://nvd.nist.gov/vuln/detail/CVE-2023-44487 and when I'm reviewing my software for vulnerability to this issue it's much more cumbersome to correlate GHSA ids with randomized names. It also hurts my ability to communicate this with other members of my team and customers since they will all know the CVE ID for this, but few will know the GHSA.

I love the advisory-database and feel it provides amazing detail on fix versions in projects that may otherwise never file their own CVE. I just want to also be able to have those projects reference relevant CVE ID in a coherent manner.

[KateCatlin]

Hey all, thank you for writing in about this issue. We're considering approaches to resolve it. I'll leave this issue open for now in case other want to chime in and comment.