nexB
Inconsistent package and version ranges
See:
- https://github.com/github/advisory-database/pull/5032#issuecomment-2930738938
and https://public.vulnerablecode.io/vulnerabilities/VCID-a2bb-91uk-hqbg?search=CVE-2024-47535
This vulnerability's records are a problematic as pointed by @AB-xdev ... and there are more issues beyond CVSS, but also wrt. to the package and versions.
from
- https://github.com/github/advisory-database/pull/5032#issuecomment-2930738938
It is normal that these three data source do not agree on the package name and the versions ranges:
- GitHub: https://github.com/advisories/GHSA-xq3w-v528-46rv
- Upstream: https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv
- CVE.org https://github.com/CVEProject/cvelistV5/blob/027ef3e8f36744185584dc5deaa41af4025eb07f/cves/2024/47xxx/CVE-2024-47535.json#L5
See also a related but different issue:
- https://github.com/aboutcode-org/vulnerablecode/issues/1892
See also a related but different issue:
- https://github.com/aboutcode-org/vulnerablecode/issues/1892
Sorry but since I am constantly mentioned and I find the linked issue quite hilarious, here are some thoughts:
I don't really see any reason why one would discuss about the version range when the CVE (from the linked issue) is from 2018... that was 7 years ago. If you still have some software running this: Maybe update ASAP and stop nit-picking versions?
Also it seems like you guys ingest from multiple sources. There will be always be some conflicts between these sources (example: <=1.2.3 is effectively the same as < 1.2.4 yet it's different). Maybe it's better to account for that possibility instead of trying to get a single "truth" from all CVE sources.
PS: I opened https://github.com/github/advisory-database/issues/5058 a while ago because GitHub was/is regularly tampering with CVSS scores, might be interesting here.
Since I was also on the other advisory and got the ping I'll add my €0.02. The advisory in the user repository (repo advisory) and the one in the github database are two different objects. One controlled by the user and the other validated by the github advisory team (the reviewed/global advisory). The repo advisory informs but does not determine the global advisory and the reason for that comes down to a lack of validation/tooling on the repo side as well as that people could lie. Imagine you're a github user and dependabot sends you an alert on some important library and that turns out to have been a lie. Bad user experience. Hence manual review. Observationally I'd say that the repo advisories are often written in what I'll call a per-project shorthand where users would use abbreviated language or version identifiers as we can see in this netty example. While I was at github I had advocated for tooling to help users write/translate to what we needed for automation. Alas that was not a high priority.
Fwiw this same basic question has come up here https://github.com/google/osv.dev/issues/3156 so I'll link that in for extra context.
As for the CVE record. The product and vendor on the CVE record come from some logic which populates the org and repo name (https://github.com/ netty/netty). All CVEs published by github should have that pattern in them, so a CVE originating from some repo foo/bar would have foo as a vendor and bar as a product. You can reconstruct the origin repo from the cve record, but repos are not packages (usually). I know there's interest in publishing the package info back to the cve, but the record spec isn't ready for that yet and so that's been blocked.
Maybe it's better to account for that possibility instead of trying to get a single "truth" from all CVE sources.
I do think there should be some rooted truth in the initial advisory, but given that we live in an imperfect world with imperfect tools and imperfect information I do agree with this from a philosophical perspective. Not that we shouldn't strive for a single truth, but we are clearly not there today.
