Describe the bug
My understanding is that JarAnalyzer extracts the pom.xml files of the shaded dependencies and analyze those (See this commit). I suspect that the issue is that some dependencies don't have pom.xml files (ie. commons-fileupload 1.0) and hence are not found.
* Version of dependency-check used *
dependency-check-maven version 5.2.3
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I expect commons-fileupload to be reported as a shaded vulnerable dependency but it is not reported at all. If I run the dependency-checker on the shaded module itself, it reports it successfully.
Please, let me know if you need more info.
Thank you for your work.
Unfortunately - shaded jars represent a challenge. In the cases when the dependent library that is "shaded" contains a pom.xml in the META-INF directory (i.e. was built by maven or uses the maven plugin for gradle) - then we can extract information and detect the dependency. However, in the case of commons-fileupload they do not have a pom.xml in the META-INF (not entirely sure what build system they use). As such, dependency-check will not be able to identify the dependency. The situation is unfortunately rather bleak for shaded or uber jars (actually - its worse for uber jars). Even several of the commercial products have difficulty with this.
I wish I had a better solution for this - but the only thing I can come up with would be to create a couple of specific package rules that would be specific to apache and possible a few other common packages. But this could become a fairly arduous and likely unreliable maintenance task for this project.
shade overlap introduces further complications
[WARNING] core-io-1.6.2.jar, jackson-core-2.10.2.jar define 3 overlapping resources:
[WARNING] - META-INF/maven/com.fasterxml.jackson.core/jackson-core/pom.properties
[WARNING] - META-INF/maven/com.fasterxml.jackson.core/jackson-core/pom.xml
[WARNING] - META-INF/services/com.fasterxml.jackson.core.JsonFactory
[WARNING] commons-codec-1.9.jar, commons-configuration-1.8.jar, commons-io-2.4.jar, commons-lang-2.6.jar, commons-lang3-3.7.jar define 2 overlapping resources:
[WARNING] - META-INF/LICENSE.txt
[WARNING] - META-INF/NOTICE.txt
[WARNING] httpcore-4.4.4.jar, log4j-api-2.10.0.jar, log4j-core-2.8.2.jar, log4j-to-slf4j-2.10.0.jar, org.apache.commons.io-2.4.jar define 1 overlapping resource:
[WARNING] - META-INF/DEPENDENCIES
[WARNING] logback-classic-1.2.3.jar, slf4j-nop-1.6.1.jar define 3 overlapping classes:
[WARNING] - org.slf4j.impl.StaticLoggerBinder
[WARNING] - org.slf4j.impl.StaticMDCBinder
[WARNING] - org.slf4j.impl.StaticMarkerBinder
[WARNING] core-io-1.6.2.jar, jackson-databind-2.9.10.jar define 3 overlapping resources:
[WARNING] - META-INF/maven/com.fasterxml.jackson.core/jackson-databind/pom.properties
[WARNING] - META-INF/maven/com.fasterxml.jackson.core/jackson-databind/pom.xml
[WARNING] - META-INF/services/com.fasterxml.jackson.core.ObjectCodec
[WARNING] core-io-1.6.2.jar, jackson-annotations-2.9.10.jar define 2 overlapping resources:
[WARNING] - META-INF/maven/com.fasterxml.jackson.core/jackson-annotations/pom.properties
[WARNING] - META-INF/maven/com.fasterxml.jackson.core/jackson-annotations/pom.xml
[WARNING] HdrHistogram-2.1.9.jar, core-io-1.6.2.jar define 2 overlapping resources:
[WARNING] - META-INF/maven/org.hdrhistogram/HdrHistogram/pom.properties
[WARNING] - META-INF/maven/org.hdrhistogram/HdrHistogram/pom.xml
[WARNING] maven-shade-plugin has detected that some class files are
[WARNING] present in two or more JARs. When this happens, only one
[WARNING] single version of the class is copied to the uber jar.
[WARNING] Usually this is not harmful and you can skip these warnings,
[WARNING] otherwise try to manually exclude artifacts based on
[WARNING] mvn dependency:tree -Ddetail=true and the above output.
[WARNING] See http://maven.apache.org/plugins/maven-shade-plugin/
pay attention to the pom.xml entries
also take a look at how relocation can obfuscate the inclusion of vulnerable classes
https://github.com/couchbase/couchbase-jvm-core/blob/1.6.2/pom.xml#L349-L352
Most helpful comment
Unfortunately - shaded jars represent a challenge. In the cases when the dependent library that is "shaded" contains a pom.xml in the META-INF directory (i.e. was built by maven or uses the maven plugin for gradle) - then we can extract information and detect the dependency. However, in the case of commons-fileupload they do not have a pom.xml in the META-INF (not entirely sure what build system they use). As such, dependency-check will not be able to identify the dependency. The situation is unfortunately rather bleak for shaded or uber jars (actually - its worse for uber jars). Even several of the commercial products have difficulty with this.
I wish I had a better solution for this - but the only thing I can come up with would be to create a couple of specific package rules that would be specific to apache and possible a few other common packages. But this could become a fairly arduous and likely unreliable maintenance task for this project.