Lighthouse CI 项目中 ws 包安全问题分析与修复方案

背景介绍

在持续集成领域，GoogleChrome 团队开发的 Lighthouse CI 作为自动化性能测试工具链中的重要组成部分，被广泛应用于现代 Web 项目的质量保障体系。近期该项目依赖链中发现的 ws 包安全问题（CVE-2024-37890）引起了开发者社区的关注，该问题可能影响使用 Lighthouse CI 进行自动化测试的稳定性。

问题技术分析

该安全问题属于 HTTP 协议层的高危问题（CVSS 评分 7.5），其核心问题在于 ws 包对 HTTP 请求头的异常处理机制。当异常客户端发送超过 server.maxHeadersCount 限制的请求头数量时，会导致 ws 服务端进程异常终止，形成服务不可用风险。

在 Lighthouse CI 的依赖树中，这个问题通过以下路径传播：

• 基础依赖：@lhci/cli → lighthouse@11.x → ws@8.x（受影响版本）
• 间接依赖：puppeteer-core@21.x → ws@8.x（受影响版本）

影响范围评估

该问题主要影响以下使用场景：

1. 运行 Lighthouse CI 服务器的生产环境
2. 暴露在公网的持续集成服务
3. 接受外部输入的自动化测试平台

值得注意的是，对于仅作为命令行工具使用的场景风险较低，因为通常不涉及长期运行的 HTTP 服务。

解决方案实施

项目维护团队通过依赖升级策略解决了该问题：

1. 将 lighthouse 依赖从 11.x 升级至 12.x 版本
2. 新版 lighthouse 12.x 使用修复后的 ws@8.16.0+ 版本
3. 确保 puppeteer-core 间接依赖也同步更新

最佳实践建议

对于使用 Lighthouse CI 的开发团队，建议采取以下措施：

1. 立即升级至包含修复的 @lhci/cli 最新版本
2. 定期执行 npm audit 进行依赖安全检查
3. 对于关键业务系统，考虑在网络层设置请求头数量限制
4. 监控项目依赖的 CVE 公告频道

技术启示

这个案例展示了现代 JavaScript 生态中依赖管理的复杂性。建议开发团队：

• 建立依赖更新机制
• 理解间接依赖的风险传导路径
• 对关键工具链组件实施问题监控
• 在 CI/CD 流程中加入安全扫描环节

通过这次安全事件的处理，Lighthouse CI 项目展现了开源社区对安全问题的快速响应能力，也为其他项目提供了依赖安全管理的参考范例。