OWASP CVE Lite CLI 实战经验

依赖漏洞扫描最怕两件事：一上来就被漏洞数量吓住，或者看到扫描通过就以为项目安全了。我的做法是把 OWASP CVE Lite CLI 当成发布前的“依赖体检单”：先确认锁文件里的真实依赖，再沿着依赖路径判断从哪里修，而不是盯着漏洞编号发愁。

第一次扫描，先把对象搞清楚

CVE Lite CLI 面向 JavaScript 和 TypeScript 项目，扫描重点不是业务源代码，而是项目已经生成的锁文件。执行前，我会先确认当前目录确实是目标项目根目录，依赖安装已经完成，最近的依赖变更也同步进了锁文件。

安装可以使用：

npm install -g cve-lite-cli

进入项目后执行：

cve-lite /path/to/project --verbose

第一次最好保留详细输出。真正有用的信息，不只是发现了哪个漏洞，还包括它属于直接依赖还是间接依赖、沿着哪条依赖链引入，以及工具建议从哪里开始升级。CVE Lite CLI 使用 OSV 数据库识别已知漏洞，这让扫描结果更接近“下一步该查什么”，而不是一串让人头大的编号。

修复时，别急着改锁文件

如果风险来自直接依赖，我会先检查项目清单中的版本范围，再评估升级对构建、测试和运行时的影响。修改版本后，锁文件也要重新生成并纳入审查，不能只改一个版本字符串就宣布胜利。

间接依赖则要沿依赖路径向上追踪，优先判断上游直接依赖是否有可用升级。直接手工修改锁文件里的嵌套条目看似省事，下一次安装时却可能被重新解析，修复也可能悄悄消失。

工具支持 --fix，也可以用 cve-lite . --json 保存机器可读结果。我更倾向于先普通扫描，再在独立分支中评估自动修复内容，随后检查项目清单、锁文件、构建结果和测试，最后重新扫描。扫描变干净只是一个信号，不是安全证明。

把扫描放进发布流程

依赖变更、合并升级分支、创建发布候选版本和生产发布前，都适合设置检查节点。遇到漏洞时，还要确认受影响依赖是否进入生产环境、相关功能是否启用，以及外部输入是否可能触发对应路径。

我会把依赖扫描和静态代码分析分开记录：前者检查锁文件中的依赖版本与已知漏洞关系，后者关注业务代码和配置逻辑。两者配合，才能把“发现问题、选择修复、验证行为、再次扫描”真正连成闭环。