Maven项目漏洞管理：手动指定无漏洞传递依赖版本是否为最佳实践？

场景描述 #

我搭建了一个Jenkins pipeline，每日对我的Java项目（基于Maven和Spring Boot）执行漏洞检测（使用OWASP Dependency-Check工具）。检测中常遇到两类漏洞情况：

• 直接依赖漏洞：通常更新依赖版本就能解决；如果暂无新版本，只能暂时抑制漏洞等待更新。
• 传递依赖漏洞：我始终保持Spring Boot为最新2.x版本，但偶尔会出现Spring Boot引入的传递依赖存在漏洞，且该依赖已有无漏洞的新版本。

问题：在pom中手动指定该传递依赖的无漏洞版本是否为最佳实践？还是等待Spring Boot后续版本更新该依赖更合适？（Spring Boot仅为示例，其他依赖同理）

处理策略分析 #

没有绝对的“最佳实践”，需根据漏洞风险、兼容性等场景灵活选择：

手动指定传递依赖版本的情况 #

• 高危/临界漏洞，业务无法承受风险：如果漏洞是CVSS评分高的高危类型（比如远程代码执行、敏感数据泄露），且没有其他临时缓解手段，直接在pom.xml的<dependencyManagement>中锁定无漏洞版本是合理的——能快速阻断风险，不用被动等待官方更新。
• 依赖版本兼容无问题：提前验证该传递依赖的新版本和当前Spring Boot版本、业务其他依赖的兼容性。比如Jackson、Netty这类基础库的小版本更新通常兼容性良好，这种情况下锁定版本不会引入额外问题。

等待Spring Boot官方更新的情况 #

• 低危漏洞，不影响核心业务：如果漏洞是低危类型（比如非敏感信息泄露、需要特定触发条件才能利用），可以选择等待Spring Boot的维护版本更新。Spring Boot团队会定期梳理依赖漏洞并推送适配后的版本，这样能避免手动维护版本带来的后续兼容性隐患。
• 依赖版本兼容性存疑：如果该传递依赖的新版本和Spring Boot的其他组件存在潜在冲突（比如某些框架依赖特定版本的底层库），盲目锁定版本可能引发新的业务问题，这种情况下优先等官方适配后的版本更稳妥。

额外实操建议 #

• 用<dependencyManagement>锁定版本：如果决定手动指定，务必在<dependencyManagement>中声明，而非直接添加为直接依赖，这样能统一管控项目中该依赖的版本，避免多模块版本不一致。
• 定期重新评估：手动锁定的依赖版本，要在后续Spring Boot更新后检查官方是否已同步升级该依赖，若已升级则可移除手动锁定配置，回归官方版本管控。
• 漏洞抑制要规范：如果暂时无法更新（无论直接还是传递依赖），在OWASP Dependency-Check中添加抑制规则时，要注明抑制原因、到期时间，避免遗忘跟进。

内容的提问来源于stack exchange，提问作者Lako12