Apache ServiceComb Java Chassis 项目中 netty-tcnative-boringssl-static 依赖的安全问题分析

背景

在 Apache ServiceComb Java Chassis 项目的基础模块 foundation-ssl 中，存在一个名为 netty-tcnative-boringssl-static 的依赖项。这是一个由 Netty 提供的用于支持 SSL/TLS 功能的原生库，基于 Google 的 BoringSSL 实现。近期安全扫描发现该依赖存在多个已知的安全问题。

安全问题详情

安全扫描报告指出，netty-tcnative-boringssl-static 的 2.0.65.Final 版本存在以下安全问题：

1. CVE-2022-28331：这是一个与 SSL/TLS 实现相关的问题，可能导致信息泄露或服务拒绝攻击。
2. CVE-2017-12613：一个较早的问题，涉及加密协议实现中的缺陷。
3. CVE-2023-49582：最新的一个问题，可能影响加密通信的安全性。

问题分析

经过深入调查，我们发现：

1. 虽然该依赖存在安全问题，但实际上 foundation-ssl 模块并未真正使用这个依赖项。
2. 尝试升级到 2.0.66.Final 版本后，发现该版本仍然使用了 2.0.65 版本的 Windows DLL 文件，这意味着问题并未得到根本解决。
3. 目前 netty-tcnative-boringssl-static 的最高版本是 2.0.66.Final，但该版本并未完全修复所有已知问题。

解决方案

基于以上分析，我们决定采取以下措施：

1. 从项目中完全移除 netty-tcnative-boringssl-static 依赖，因为：

   • 该依赖并非项目必需
   • 当前版本存在安全风险
   • 升级到最新版本也无法完全解决问题

2. 对于确实需要 SSL/TLS 支持的情况，建议考虑以下替代方案：

   • 使用 JDK 内置的 SSL 实现
   • 评估其他经过安全审计的 SSL/TLS 实现

技术建议

对于类似情况，我们建议开发团队：

1. 定期进行依赖项安全扫描
2. 建立依赖项使用评估机制，确保每个依赖都是必要的
3. 对于安全敏感的依赖项，建立更严格的版本升级策略
4. 考虑使用软件物料清单(SBOM)工具来跟踪项目依赖关系

总结

在软件开发中，依赖管理是一个需要特别关注的领域。Apache ServiceComb Java Chassis 项目通过这次对 netty-tcnative-boringssl-static 依赖的处理，展示了良好的安全实践：及时识别风险依赖、评估实际需求、采取果断措施。这种处理方式不仅解决了当前的安全问题，也为项目的长期安全维护奠定了基础。