albuch / sbt-dependency-check

SBT Plugin for OWASP DependencyCheck. Monitor your dependencies and report if there are any publicly known vulnerabilities (e.g. CVEs). :rainbow:

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Override on guava still reported on avro-1.8.2.jar (shaded: com.google.guava:guava:11.0.2)

reidrac opened this issue · comments

dependencyCheck reports a vulnerability on a transitive dependency, and when the version of the transitive dependency is bumped via dependencyOverrides, the problem still shows in the report.

The tool reports a vulnerability (CVE-2018-10237) in guava 11.0.2, because of avro 1,8.2.

Guava was updated to 27.0-jre, from my build.sbt:

dependencyOverrides += "com.google.guava" % "guava" % "27.0-jre"

I've added a suppression on cpe:/a:google:guava:11.0.2.

Thanks!

@reidrac Could you tell me which dependency contains the vulnerable guava version so that I can reproduce the issue?

Edit: never mind, you mentioned it in the bug title as well as in the bug report.

As far as I understand it this is not a false positive that can and should be handled/filtered by dependency-check automatically.
You are overriding the guava package in your classpath, but you still retain the shaded classes that were copied from the vulnerable guava version.
So it's actually a good thing that DC reports the issue.
You should then analyze if the attack vector of the CVE is exploitable in your context via the shaded classes or not. If so report it to the avro maintainers to apply a fix. If not go with a local suppression rule.

I'll double check with the folks of dependency-check-core though if they think otherwise.

It's all because avro-1.8.2.jar; and you're right it includes guava 11.0.2.

When I run show update on sbt there's no guava:11.0.2, only guava:27.0-jre (as expected). That's why I thought this could be a false positive.

Yes, though it still contains the pom.xml of the shaded guava version, which is indexed by dependency-check as well.
A side note on your suppression: you shouldn't exclude the CPE for guava though, because when you re-introduce a vulnerable guava version later on it wouldn't be reported as well.
You should rather exclude the pom.xml file in the meta-inf directory.

<suppress>
    <filePath regex="true">.*\bMETA-INF\b.*\/guava\/pom\.xml$</filePath>
    <cve>CVE-2018-10237</cve>
</suppress>

Lovely, thanks for the tip!