guava fail guava 31.1-re, false positive?

[THausherr]

We're using 3.2 and getting this fail:

[ERROR] Failed to execute goal org.sonatype.ossindex.maven:ossindex-maven-plugin:3.2.0:audit (audit-dependencies) on project tika-core: Detected 1 vulnerable components:
[ERROR] com.google.guava:guava:jar:31.1-jre:test; https://ossindex.sonatype.org/component/pkg:maven/com.google.guava/guava@31.1-jre?utm_source=ossindex-client&utm_medium=integration&utm_content=1.8.1
[ERROR] * 1 vulnerability found (6.2); null

There is no known CVE for guava 31.1-jre . The website above mentions a MEDIUM vulnerability and tries to nudge me on subscribing, and that "There are some breaking changes" with even more confusion.

[ken-duck]

Hi!

OSS Index knows of many vulnerabilities beyond what are available in the National Vulnerability Database. Indeed the "breaking changes" mentioned is the fact that we have moved from our original data set to a new one which contains even MORE vulnerabilities than previously mentioned, but had different IDs (and we dropped support for a few ecosystems).

We have a sizeable research team that scour GitHub (and other sources) looking for unpublished vulnerabilities and verifying them before adding them to the database, and are rather confident in our results, so it is likely the vulnerability being reported is real and true.

An account at OSS Index is free and does not come encumbered with any additional requirements, and indeed ups the rate limits and data access that you might otherwise run into.

[tballison]

Y, so I got an account, and there are like 4 or 5 dependencies that are flagged that are false positives. Like the C++ library is vulnerable, but not our java one, or the issue your database cites is for a far older version.

Now that you're rolling this out, builds are breaking across the world because of bad data. And, this is good for you (and those who rely on your free service) because people will complain, and your database will get better, but my goodness this is painful. Really painful.

So, I'm grateful for your resource, but wow that was not the best move.

[ken-duck]

I can understand your consternation, however I will stand by the quality of our data. If you could send specifics of vulnerabilities and the packages that you feel we are misidentifying I can have the team look at the research, but at this point no one has found a false positive that stands up to scrutiny. Thanks for the help, Ken Duck Sonatype

…

On May 27, 2022, at 3:41 PM, Tim Allison ***@***.***> wrote: Y, so I got an account, and there are like 4 or 5 dependencies that are flagged that are false positives. Like the C++ library is vulnerable, but not our java one, or the issue your database cites is for a far older version. Now that you're rolling this out, builds are breaking across the world because of bad data. And, this is good for you (and those who rely on your free service) because people will complain, and your database will get better, but my goodness this is painful. Really painful. So, I'm grateful for your resource, but wow that was not the best move. — Reply to this email directly, view it on GitHub <#76 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHHSFLOHOSD7A2K3VSNMHYLVMEJOFANCNFSM5W7VY5GQ>. You are receiving this because you commented.

[tballison]

Thank you for your feedback. Should I open separate issues or list them here? Thank you again.

[ken-duck]

Listing here is fine. Even better would be if you could email us at ossindex@sonatype.org, which will go directly to the research team, but if you post them here I can forward them along.

[tballison]

K. Email sent.

@THausherr this is the issue that sonatype references for guava 31.1-jre: google/guava#4011

[tballison]

Our project will have to weigh the cost-benefit of continuing to use ossindex if we continue to get failed builds because of issues that affect up-to-date dependencies that we cannot upgrade our way out of.

Again, this is a free service, and I'm enormously grateful, but the churn over this update in your backend db is frustrating.

[ken-duck]

@tballison Thanks for the details!

I understand the pain that the update is surely causing. The main thrust of the update was moving OSS Index on to a new vulnerability database which has more vulnerabilities, is updated more frequently, has much fewer false positives and negatives, and has a far larger research team behind it. As you might expect it required a significant amount of effort and time as the entire backend has been changed out. It is unfortunate that it is and will cause pain during the transition, but in the end I think you will find it is well worth the effort.

There should not be any similar upgrades in the future, as it is very unlikely we will be moving to a new database and research team at any other point.

Our research team will look through the components/vulnerabilities you are concerned with and hopefully be able to provide you the information and assurance you need.

[tballison]

Got it. Thank you so much.

Two other items:

1. Do we really have to create an account to see what the underlying problem is? It feels like a needless gathering of privacy information for when our build breaks. I've given up on this and have registered my info, but other folks on our team might not be willing to take the same approach. And it will be frustrating to them that our build is broken and they can't figure out why.
2. If we can't upgrade our way out of a build failure, is there a general setting to ignore those cases where your db has identified a vuln in the most recent release of the dependency, but there's no fix available? The maintenance of our exclude lists is rather unpleasant, and I agree that you won't likely be migrating again, but the underlying database will be changing as new vulns are detected and possibly not remediated.

Thank you, again.

[OSSIndex-Admin]

Hi! Currently it is required to have an account to see details for the sonatype-* vulnerabilities. There are a number of reasons this restriction was added; I can get you in touch with someone with more authority than I to discuss the reasons, but I feel confident in saying the intent is not to unnecessarily pry into folk’s privacy. I myself usually balk at signing up for things for that very reason (and indeed fought against it in the early days of OSS index), but realize that in this situation there was no other reasonable option. As for your concern about how to handle these vulnerabilities in the absence of more data; I am considering writing a feature for dependency-check which will allow users to more easily manage the sonatype.* vulnerabilities for cases such as yours. Exclude lists are *definitely* unpleasant. I would of course argue against hiding these vulnerabilities as OSS index reports MANY vulnerabilities that otherwise do not get CVEs, however I definitely understand that folks often need to balance pressure from various competing pressures within their companies and the improved protection provided by Sonatype’s CVE data alone is much better than not using this data source. I will see what I can do for you. Ken

…

On May 27, 2022, at 6:14 PM, 'Tim Allison' via ossindex-admin ***@***.***> wrote: Got it. Thank you so much. Two other items: Do we really have to create an account to see what the underlying problem is? It feels like a needless gathering of privacy information for when our build breaks. I've given up on this and have registered my info, but other folks on our team might not be willing to take the same approach. And it will be frustrating to them that our build is broken and they can't figure out why. If we can't upgrade our way out of a build failure, is there a general setting to ignore those cases where your db has identified a vuln in the most recent release of the dependency, but there's no fix available? The maintenance of our exclude lists is rather unpleasant, and I agree that you won't likely be migrating again, but the underlying database will be changing as new vulns are detected and possibly not remediated. Thank you, again. — Reply to this email directly, view it on GitHub <#76 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADH3NUGJUK4Q5OFMFDCIHX3VME3M3ANCNFSM5W7VY5GQ>. You are receiving this because you are subscribed to this thread. -- You received this message because you are subscribed to the Google Groups "ossindex-admin" group. To unsubscribe from this group and stop receiving emails from it, send an email to ***@***.*** ***@***.***>. To view this discussion on the web visit https://groups.google.com/a/sonatype.com/d/msgid/ossindex-admin/sonatype/ossindex-maven/issues/76/1140045305%40github.com <https://groups.google.com/a/sonatype.com/d/msgid/ossindex-admin/sonatype/ossindex-maven/issues/76/1140045305%40github.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/a/sonatype.com/d/optout <https://groups.google.com/a/sonatype.com/d/optout>.

[ken-duck]

Whoops. @tballison , It occurs to me I made an assumption (based off of other feedback I am working with). I will look into making a PR for ossindex-maven as well which will allow you more control over the data.

[tballison]

And naturally, after signing up for an account so that I can figure out why our build is now failing, I get spam from ossindex about all the great features! I've now unsubscribed but this is just not right.

[ken-duck]

I have talked with the researchers, and not only does version 31.1-jre have a security vulnerability, but all versions of guava are vulnerable. The supporting information provided on the "references" on OSS Index verifies the finding.

[tballison]

Ok. So as a maintainer of an open source project that has a dependency with no available fix, my only option is to exclude that dependency from ossindex's checks?

[ken-duck]

Best bet would be to exclude that specific vulnerability, and not the dependency itself. Other than that I don't know of any other feasible solution.