· log4j-core-2.11.1.jarlocated at sdnr/wt/common/target/elasticsearch0/lib
· log4j-core-2.11.1.jarlocated at sdnr/wt/data-provider/provider/target/elasticsearch0/lib
· log4j-core-2.11.1.jarlocated at sdnr/wt/data-provider/setup/target/elasticsearch0/lib
Those specific directories aren’t part of the onap-ccsdk-features docker images : they’re actually created as part of unit testing, and are not included in the deployed artifacts.
The repo was checked using the maven “dependency:tree” command , which dumps all the various nested dependencies for our code and verified that there are no dependencies on log4j-core. The docker images were checked to verify that log4j-core version 2.11.1 is not installed. onap-ccsdk-features installs pax-logging version 2.0.14, which embeds log4j-core version 2.17.1.
Thank you for the question. For IQ to be as accurate as the maven dependency:tree command, one needs to use the CLM for Maven plugin. The plugin can do an IQ evaluation on its own or combined with other Nexus IQ plugins. To evaluate on its own, use the evaluate goal. To integrate with other plugins, use the index goal.
Thanks for your reply Chris, the use case is the one mentioned in the beginning of the thread where we have a module called onap-ccsdk-features which pulls dependencies outside this repo which are flagged as log4j threats.
The solution you mentioned might work for us. Let me test it