-
Notifications
You must be signed in to change notification settings - Fork 546
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
False positive - Ruby libraries identified as other software #244
Comments
@luislavena thanks for reporting this one. We have a few False Positive issues that are coming up that we are trying to resolve. Let's definitely keep this one open to track it - we appreciate the detail in the report! |
Expanding on here, I believe that this is again related to CPE matching being too broad:
|
Thank you @alfredodeza for your response and the context. Please let me know if there is anything else I could help with, including provide test repositories or similar 😊 (haven't learn Go in order to say can do some coding, hehe). Once again, thank you for making grype available! ❤️ ❤️ ❤️ Cheers. |
The same seems to have started happening for
output includes:
There are also some However the 3 zlib lines of type So grype shouldn't be reporting these CVEs for bugs in the actual zlib library, against the version of the Ruby zlib interface package. Is this the correct ticket for that, or should I open a separate one? |
Interestingly the very day after my comment, the vuln DB update (from
however it is still wrong - those CVEs are just not applicable to the Ruby gem interface package called |
Having the same issue with the Syft (0.56.0) defines the following cpes in the sbom:
Grype then flags it for CVE-2018-12453 (and a bunch of others) that actually impacts the redis server, and not the client lib. The versions are totally unrelated. This is because the
|
I'm still able to reproduce the issues mentioned in #244 (comment).
prints the following vulnerabilities:
I'm not able to reproduce the false positives from the original post on this issue, but it could be that In https://github.com/anchore/grype/releases/tag/v0.60.0, grype stopped matching on javascript CPEs by default for exactly this sort of issue, but I believe the Ruby ecosystem still matches on CPEs by default. It might be worth looking for a different way to match Ruby CVEs than relying on CPEs. |
Hi @luislavena, thanks for the report! The reason this was happening was that Grype used to use CPEs to match ruby gems to vulnerabilities, and CPEs don't have any mechanism to namespace them by ecosystem. Since the issue was opened, Grype has switched to using the information in PURLs for language ecosystem matching, so I believe this class of issue is no longer present on recent versions of Grype on default configuration, so I'm going to close this, since I think the original request is solved. Please let us know if we missed something. |
Hello @willmurphyscode, indeed this issue no longer appears (well, except for all the newer CVE's found in Alpine, but that has nothing to do with Grype! 😅 ) Thank you for following up on this! |
What happened:
grype reports certain Ruby gems as CVE for Drupal, Node and other non-programming related (ranges from High to Low).
What you expected to happen:
Grype states scans for vulnerabilities in Ruby (Bundler) which can be interpreted as gems (the package system used by Ruby).
How to reproduce it (as minimally and precisely as possible):
date
applies to Drupal module, not Ruby'sdate
gemIt appears most of these reports are false positives or other libraries with same names but different languages.
Environment:
grype version
:cat /etc/os-release
from container):Unsure how to proceed or how to help correct these false positives.
Thank you in advance for time and most importantly, for making grype available to the world! ❤️ ❤️ ❤️
Cheers.
The text was updated successfully, but these errors were encountered: