# Issues with vulnerabilities on transitive dependencies **URL:** \ **Category:** Sonatype Lifecycle & Firewall\ **Tags:** nexus-iq\ **Created:** [March 2, 2022, 11:28pm UTC](https://community.sonatype.com/t/issues-with-vulnerabilities-on-transitive-dependencies/8324 "2022-03-02T23:28:42Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![linuxfoundation-01](https://yyz1.discourse-cdn.com/flex047/user_avatar/community.sonatype.com/linuxfoundation-01/32/1079_2.png) [@linuxfoundation-01](https://community.sonatype.com/u/linuxfoundation-01)\ **Post date:** [March 2, 2022, 11:28pm UTC](https://community.sonatype.com/t/issues-with-vulnerabilities-on-transitive-dependencies/8324/1 "2022-03-02T23:28:43Z")
Dear Sonatype team. Working with the ONAP organization, it was noticed that few false positives were detected in one component’s transitive dependencies which shouldn’t have been marked as threats The report in question is: [IQ Server - Management](https://nexus-iq.wl.linuxfoundation.org/assets/index.html#/applicationReport/onap-ccsdk-features/c35c8784358e48f0bbb39c6d45858b54/policy) And the marked threats are: · _log4j-core-2.11.1.jar_ _located at_ sdnr/wt/common/target/elasticsearch0/lib · _log4j-core-2.11.1.jar_ _located at_ sdnr/wt/data-provider/provider/target/elasticsearch0/lib · _log4j-core-2.11.1.jar_ _located 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. Could someone please help us investigating this? Thanks so much! ---
**Author:** ![jwilcox](https://avatars.discourse-cdn.com/v4/letter/j/e47774/32.png) [@jwilcox](https://community.sonatype.com/u/jwilcox)\ **Post date:** [March 3, 2022, 3:55pm UTC](https://community.sonatype.com/t/issues-with-vulnerabilities-on-transitive-dependencies/8324/2 "2022-03-03T15:55:16Z")
> [@linuxfoundation-01](#): > > [IQ Server - Management](https://nexus-iq.wl.linuxfoundation.org/assets/index.html#/applicationReport/onap-ccsdk-features/c35c8784358e48f0bbb39c6d45858b54/policy) Hi Andrew, 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. For more info, please refer to [Sonatype CLM for Maven](https://help.sonatype.com/integrations/sonatype-clm-for-maven). Kind Regards, Jim Wilcox Product Manager ---
**Author:** ![linuxfoundation-01](https://yyz1.discourse-cdn.com/flex047/user_avatar/community.sonatype.com/linuxfoundation-01/32/1079_2.png) [@linuxfoundation-01](https://community.sonatype.com/u/linuxfoundation-01)\ **Post date:** [March 8, 2022, 9:26pm UTC](https://community.sonatype.com/t/issues-with-vulnerabilities-on-transitive-dependencies/8324/3 "2022-03-08T21:26:51Z")
Thank you Jim! We are actually using: $MVN $MAVEN\_GOALS dependency:tree com.sonatype.clm:clm-maven-plugin:index Do both evaluate and index goals detect vulnerabilities in transitive dependencies. We are actually looking to avoid those being flagged is possible. Thanks! ---
**Author:** ![linuxfoundation-01](https://yyz1.discourse-cdn.com/flex047/user_avatar/community.sonatype.com/linuxfoundation-01/32/1079_2.png) [@linuxfoundation-01](https://community.sonatype.com/u/linuxfoundation-01)\ **Post date:** [March 29, 2022, 6:37pm UTC](https://community.sonatype.com/t/issues-with-vulnerabilities-on-transitive-dependencies/8324/4 "2022-03-29T18:37:26Z")
Hi Jim, Could you please help us commenting on my reply above? How can we avoid transitive dependencies from appearing in our reports? Thanks so much! ---
**Author:** ![ctolo](https://yyz1.discourse-cdn.com/flex047/user_avatar/community.sonatype.com/ctolo/32/57_2.png) [@ctolo](https://community.sonatype.com/u/ctolo)\ **Post date:** [March 29, 2022, 6:42pm UTC](https://community.sonatype.com/t/issues-with-vulnerabilities-on-transitive-dependencies/8324/5 "2022-03-29T18:42:39Z")
What is the use-case to avoid vulnerabilities in transitive dependencies? You can modify your policies to exclude transitive dependencies. ![image](https://canada1.discourse-cdn.com/flex047/uploads/communitysonatype/original/2X/b/bb983416f115f9effafc50b9e7d053f5597db788.png) ---
**Author:** ![ctolo](https://yyz1.discourse-cdn.com/flex047/user_avatar/community.sonatype.com/ctolo/32/57_2.png) [@ctolo](https://community.sonatype.com/u/ctolo)\ **Post date:** [March 29, 2022, 6:47pm UTC](https://community.sonatype.com/t/issues-with-vulnerabilities-on-transitive-dependencies/8324/6 "2022-03-29T18:47:50Z")
Sounds like you might want to just exclude those components from your scan though. [https://help.sonatype.com/integrations/sonatype-clm-for-maven#SonatypeCLMforMaven-ExcludingModuleInformationFilesinContinuousIntegrationTools](https://help.sonatype.com/integrations/sonatype-clm-for-maven#SonatypeCLMforMaven-ExcludingModuleInformationFilesinContinuousIntegrationTools) ---
**Author:** ![linuxfoundation-01](https://yyz1.discourse-cdn.com/flex047/user_avatar/community.sonatype.com/linuxfoundation-01/32/1079_2.png) [@linuxfoundation-01](https://community.sonatype.com/u/linuxfoundation-01)\ **Post date:** [March 29, 2022, 6:52pm UTC](https://community.sonatype.com/t/issues-with-vulnerabilities-on-transitive-dependencies/8324/7 "2022-03-29T18:52:12Z")
> [@linuxfoundation-01](#): > > onap-ccsdk-features 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 Thank you so much!