github / advisory-database

Security vulnerability database inclusive of CVEs and GitHub originated security advisories from the world of open source software.
Creative Commons Attribution 4.0 International
1.73k stars 328 forks source link

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

Open joakime opened 1 year ago

joakime commented 1 year ago

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 https://github.com/advisories/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 https://github.com/github/advisory-database/pull/2860

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

Examples in Discussions:

Examples in Release Notes:

Examples in Issues:

Examples in PRs:

joakime commented 1 year ago

Some other github advisories referring to CVE-2023-44487

dpippenger commented 1 year ago

The github advisory database seems to be enforcing a 1:1 mapping of CVE ID to software project, see here https://github.com/github/advisory-database/pull/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 commented 11 months ago

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.