Closed karthickm512 closed 10 months ago
Thanks for the report @karthickm512!
@kzantow @spiffcs - this is another case of the sometimes wild CPE generation logic in syft (particularly for java packages)
grype file:~/Downloads/apache-karaf-4.3.8.tar.gz | grep CVE-2021-26291
✔ Vulnerability DB [no update available]
✔ Indexed /private/var/folders/tk/41r4j_qs09vdh0jhvh05v_9c0000gp/T/syft-archive-contents-1301327164
✔ Cataloged packages [341 packages]
✔ Scanned image [837 vulnerabilities]
maven-resolver-api 1.8.2 java-archive CVE-2021-26291 Critical
maven-resolver-connector-basic 1.8.2 java-archive CVE-2021-26291 Critical
maven-resolver-impl 1.8.2 java-archive CVE-2021-26291 Critical
maven-resolver-named-locks 1.8.2 java-archive CVE-2021-26291 Critical
maven-resolver-spi 1.8.2 java-archive CVE-2021-26291 Critical
maven-resolver-transport-wagon 1.8.2 java-archive CVE-2021-26291 Critical
maven-resolver-util 1.8.2 java-archive CVE-2021-26291 Critical
It ends up generating a maven CPE as upstream for all of the maven-* artifacts, but most are versioned independently (with much lower versions than maven-core) and so always result in a ton of false positives being reported. I'm not sure that we have any great solutions here yet, but since we do have the match quality gate in place now it might be worth revisting if there are some changes we could make to the cpe generation logic in syft to help reduce these. I do have alot of examples of similar cases that we could potentially use to help with this.
Hey!
Just wanted to chime in here and say we're seeing this in some of our images that include Apache Maven as well:
% docker pull cgr.dev/chainguard/maven
% grype cgr.dev/chainguard/maven:latest
✔ Vulnerability DB [no update available]
New version of grype is available: 0.61.1 (currently running: 0.61.0)
✔ Loaded image
✔ Parsed image
✔ Cataloged packages [95 packages]
✔ Scanning image... [10 vulnerabilities]
├── 10 critical, 0 high, 0 medium, 0 low, 0 negligible
└── 0 fixed
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
maven-resolver-api 1.9.7 java-archive CVE-2021-26291 Critical
maven-resolver-connector-basic 1.9.7 java-archive CVE-2021-26291 Critical
maven-resolver-impl 1.9.7 java-archive CVE-2021-26291 Critical
maven-resolver-named-locks 1.9.7 java-archive CVE-2021-26291 Critical
maven-resolver-spi 1.9.7 java-archive CVE-2021-26291 Critical
maven-resolver-transport-file 1.9.7 java-archive CVE-2021-26291 Critical
maven-resolver-transport-http 1.9.7 java-archive CVE-2021-26291 Critical
maven-resolver-transport-wagon 1.9.7 java-archive CVE-2021-26291 Critical
maven-resolver-util 1.9.7 java-archive CVE-2021-26291 Critical
maven-shared-utils 3.3.4 java-archive CVE-2021-26291 Critical
These are all from that same style CPE mismatch logged above.
These false positives should not longer be found now that we have changed our vulnerability matching method (as described: https://anchore.com/blog/say-goodbye-to-false-positives/) -- I'll go ahead and close this issue but please feel free to open up any new false positives you see. Thanks!
What happened: We use Apache Karaf 4.3.8 and Anchore Grype reported CVE-2021-26291 https://nvd.nist.gov/vuln/detail/CVE-2021-26291 on that package
What you expected to happen: As per https://issues.apache.org/jira/browse/KARAF-7579 and https://issues.apache.org/jira/browse/KARAF-7223, Karaf has already bumped Maven artifacts to non-impacted latest 3.8.6, so the vulnerability which affects only till maven 3.8.1 should not have been reported by Grype.
How to reproduce it (as minimally and precisely as possible): Download Apache Karaf runtime 4.3.8 or 4.4.2 from https://karaf.apache.org/download and scan with Anchore Grype
Environment:
grype version
: 0.53.1cat /etc/os-release
or similar): SLES15.4 SP4