Open tomersein opened 1 month ago
Thanks for the report! The short answer is I think this should be addressed by https://github.com/anchore/cve-data-enrichment/commit/ea0ffb3b446ffa9b2994834e662261415dcf2167 when a new grypedb is built and published tomorrow.
To explain a bit more of the detail here - alpine only provides a feed of fixes to vulnerabilities, so in grype we have to pair that with NVD matches in order to get the full picture including potentially unpatched vulnerabilties. That requires transforming from an alpine package name to a set of cpe candidates. NVD is no longer providing CPE node configurations on the majority of new vulnerabilities so we have to do that ourselves, and in this particular case I hadn't captured the lower bound for some of the CPE nodes, so tomorrows update should hopefully fix this particular instance. Also for OpenJDK in particular the NVD CPE data that does exist tends to be rather less than ideal, so we've attempted to improve them in our enrichment effort. So tomorrow the rendered NVD cpe configuration that will be used to build the grype db for CVE-2024-20932 is https://raw.githubusercontent.com/anchore/nvd-data-overrides/a58568aa103fd2a8ab1be6a866f923a37a1142dc/data/2024/CVE-2024-20932.json
thanks for the answer! I am currently using grype 0.74.4, will it require me to upgrade grype?
thanks!
No, just grype db update
tomorrow, or it should automatically download the latest db update on a subsequent scan
What happened: I am scanning an image of alpine 3.20 that contains a dependency of openjdk 8. I am receiving from Grype 0.74.4\0.78.0 the CVE of CVE-2024-20932. This CVE according to the DB is related to openjdk17 (alpine remediation) for version < 17.0.10_p7-r0 My version is 8.402.06-r0 I tried to debug, seems like Syft from the one hand tries to guess CPEs and Grype from the other hands does some heuristic which makes the jdk8 become jdk and than matches the mentioned CVE. The versions seems to be unrelated, which makes me think we have a FP.
What you expected to happen: Not to find this vulnerability. How to reproduce it (as minimally and precisely as possible): I can't attach the full SBOM, so ill attach only a sample:
Anything else we need to know?:
Environment:
grype version
: 0.78.0cat /etc/os-release
or similar): alpine 3.20.0