在我的工作中，扫描器工具检测到我们的应用程序使用了Log4j易受攻击的版本(著名的RCE漏洞Log4j -core version <= 2.17.0)，这是非常非常难以检测到的，因为即使我们运行mvn dependency:tree -Dverbose也不会显示依赖项。
经过几个小时的检查，每个直接依赖声明在主pom.xml，我们发现如下:
有一个直接依赖:
<dependency>
<groupId>org.ops4j.pax.logging</groupId>
<artifactId>pax-logging-log4j2</artifactId>
<version>2.0.5</version>
</dependency>
如果我们打开pax-logging-log4j2。现在我们可以看到它正在添加log4j-core，并提供了作用域:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<scope>provided</scope>
</dependency>
事实证明，这个具有提供范围的传递依赖没有被mvn dependency:tree目标检测到，我甚至用一个简单的项目做了一个测试，只添加pax-logging-log4j2作为依赖，树的输出如下:
com.ram:testdependencies:jar:0.0.1-SNAPSHOT
- org.ops4j.pax.logging:pax-logging-log4j2:jar:2.0.5:compile
+- org.ops4j.pax.logging:pax-logging-api:jar:2.0.5:compile
| +- (org.osgi:osgi.core:jar:7.0.0:compile - omitted for duplicate)
| - (org.osgi:osgi.cmpn:jar:7.0.0:compile - omitted for duplicate)
+- org.osgi:osgi.core:jar:7.0.0:compile
- org.osgi:osgi.cmpn:jar:7.0.0:compile
我们可以看到，即使在pax-logging-log4j2中添加了log4j-core依赖，也没有出现log4j-core依赖。如果mvn依赖树没有显示所有内容，即使指定了-Dverbose，那么我们如何轻松地检测是否确实使用了某些依赖?关于提供的作用域依赖，我所知道的是它们用于编译而不是在运行时(这些是由实际运行环境提供的，例如servlet api是由Tomcat提供的)，即使如此，我真的不明白这个工件中的log4j-core jar最终是如何被使用并因此被扫描仪拾取的。
pax-logging-log4j2工件是一个fat jar，其中还包括来自log4j-core的类。
没有通用的方法来检测脂肪罐:在这种情况下，原始的log4j-corePOM文件包含在META-INF/maven文件夹中，但情况并非总是如此。
fat jar的作者使用各种技巧来声明它们的"依赖项"。其中之一是在provided范围内添加依赖项(这通常意味着完全不同的东西)。
在您的具体情况下(参见Maven Repository):
log4j-api是一个必须由运行时环境提供的依赖项(IMHOosgi.core和osgi.cmpn也应该在这个范围内)， 不需要提供
log4j-coreis，因为它包含在jar文件中。