17370845950

本教程探讨了在maven项目中升级传递性依赖（尤其当传统排除方法无效时）的策略。核心推荐是利用maven的``来统一管理和覆盖传递性依赖的版本，从而有效解决安全漏洞等问题。文章还深入分析了“胖jar”包可能导致排除失效的原因，并提供了相应的排查建议。

Maven 传递性依赖概述

在Maven项目中，我们声明的直接依赖可能会引入其自身的依赖，这些被称为传递性依赖。Maven通过一套复杂的机制来解析和管理这些依赖，确保项目能够获取所有必需的库。然而，这种自动化的便利性有时也会带来挑战，例如当传递性依赖中包含需要升级（如修复安全漏洞）的旧版本库时。

升级传递性依赖的挑战

当一个直接依赖（例如项目A依赖库B）引入了一个需要更新的传递性依赖（例如库B依赖库C的旧版本）时，常见的做法是在项目A的pom.xml中，对库B声明一个，将旧版本的库C排除掉，然后单独引入新版本的库C作为直接依赖，或者在中声明新版本。

然而，这种方法并非总是奏效。例如，当org.glassfish.metro:webservices-rt:2.4.3传递性依赖com.fasterxml.woodstox:woodstox-core:5.1.0，而后者存在严重安全漏洞，需要升级到6.4.0时，即使在webservices-rt的依赖声明中明确排除了woodstox-core，某些安全扫描工具（如Aqua Scan）仍可能报告旧版本存在。这表明，Maven的依赖树可能已显示排除成功，但实际运行时或在某些特定场景下，旧版本仍然存在。

以下是尝试使用exclusions但可能未能完全解决问题的pom.xml片段示例：

    
    
        
            com.fasterxml.woodstox
            woodstox-core
            6.4.0 
        
        
            org.glassfish.metro
            webservices-rt
            2.4.3
            
                
                    com.fasterxml.woodstox
                    woodstox-core 
                
            
        
    
    

尽管Maven的dependency:tree命令可能不再显示woodstox-core:5.1.0，但安全扫描工具的报告提示了一个更深层次的问题。

推荐的解决方案：使用

解决此类传递性依赖版本冲突和强制升级的最佳实践是利用Maven的部分。dependencyManagement允许你集中管理项目所有依赖的版本，而不会立即将它们引入到子模块中。当你在dependencyManagement中声明一个依赖的版本时，所有继承该pom的项目或该pom本身中声明的相同groupId和artifactId的依赖，都会默认使用dependencyManagement中指定的版本，即使它们通过传递性依赖引入了不同版本。

通过这种方式，你可以有效地“覆盖”任何传递性引入的旧版本。

    
    
        
            
                com.fasterxml.woodstox
                woodstox-core
                6.4.0 
            
        
    

    
        
        
            org.glassfish.metro
            webservices-rt
            2.4.3
            
        
        
        
    
    

优点：

• 版本统一性： 确保整个项目及其子模块都使用指定版本的依赖。
• 简洁性： 避免了在每个使用该依赖的地方都重复声明版本，减少了pom.xml的冗余。
• 优先级： dependencyManagement中的版本声明具有更高的优先级，能够有效覆盖传递性依赖引入的旧版本。
• 无需排除： 在大多数情况下，一旦在dependencyManagement中设置了版本，就不再需要复杂的exclusions配置。

当排除和版本管理均失效："胖Jar"包的考量

如果即使使用了，安全扫描工具仍然报告旧版本存在，这可能涉及到更深层次的问题：依赖的打包方式。

“胖Jar”（Fat Jar / Uber Jar） 是一种特殊的JAR包，它将自身及其所有或部分传递性依赖直接打包到同一个JAR文件中。这意味着，当你在项目中引入一个“胖Jar”作为依赖时，Maven的常规依赖解析机制（包括exclusions和dependencyManagement）可能无法对其内部已经捆绑的依赖生效。Maven只会看到并解析外部的“胖Jar”本身，而不会深入到其内部去管理那些已被打包的子依赖。

在这种情况下，即使Maven的依赖树不再显示有问题的传递性依赖，它实际上仍然存在于“胖Jar”内部，并可能在运行时被加载，从而被安全扫描工具检测到。

排查与应对策略：

1. 识别“胖Jar”： 检查导致问题的直接依赖（例如webservices-rt）是否是“胖Jar”。你可以通过解压该JAR文件并查看其内部结构来确认。通常，“胖Jar”会在lib目录或根目录下包含其他JAR文件。
2. 避免使用“胖Jar”作为依赖： 如果可能，尽量避免将“胖Jar”作为项目的直接依赖。寻找提供标准、非捆绑依赖版本的替代库，或者使用模块化的版本。
3. 直接替换或修改“胖Jar”： 在某些极端情况下，如果无法避免使用“胖Jar”且其内部依赖存在严重问题，你可能需要：
   • 尝试联系库的维护者，请求他们发布一个不包含有漏洞依赖的版本。
   • （不推荐，但有时是唯一的选择）手动修改“胖Jar”，替换或删除其内部的有问题依赖，但这会带来维护困难和潜在的兼容性问题。
4. 验证扫描工具： 确认安全扫描工具的报告是否准确。有时，扫描工具可能会误报，或者其检测逻辑与实际运行时环境存在差异。可以通过运行时类加载日志、调试器等方式进一步验证实际加载的类版本。

总结

管理Maven项目中的传递性依赖是确保项目安全和稳定的关键一环。优先使用来统一和覆盖传递性依赖的版本，这通常是解决版本冲突和升级问题的最有效方法。当这种方法失效时，应深入探究是否存在“胖Jar”等特殊打包形式，并根据具体情况采取相应的排查和应对策略。始终保持对项目依赖的清晰理解，并结合Maven工具和安全扫描报告进行综合分析，是维护高质量Maven项目的核心实践。