用 OWASP CVE Lite CLI 为 JavaScript 与 TypeScript 项目建立依赖漏洞扫描流程

当 JavaScript 或 TypeScript 项目准备合并代码、发布版本或部署到生产环境时，依赖漏洞扫描应该先回答一个具体问题：当前项目的锁文件里，哪些依赖存在已知漏洞，以及应该从哪里开始修复。OWASP CVE Lite CLI 的定位就是在本地扫描项目锁文件，识别已知漏洞，并给出依赖路径和修复方向。它不需要账号，也不要求把项目上传到云端。

先明确扫描对象：项目锁文件

CVE Lite CLI 面向 JavaScript 和 TypeScript 项目的依赖扫描，核心输入不是业务源代码，而是项目已有的锁文件。锁文件记录了实际安装的依赖版本以及依赖之间的关系，因此扫描前应先确认项目已经完成依赖安装，并且锁文件处于可追踪、可复现的状态。

准备项目时，重点检查三个方面：

• 当前目录是否确实是目标项目根目录；
• 项目是否存在并使用对应包管理器生成的锁文件；
• 最近一次依赖变更是否已经同步到锁文件。

不要只根据 package.json 中声明的版本判断风险。直接依赖可能会带入间接依赖，而真正被安装和发布的版本通常需要结合锁文件确认。扫描结果中的“直接依赖”和“间接依赖”也应分别处理：直接依赖通常可以直接调整项目清单，间接依赖则可能需要升级上游依赖、重新解析依赖树，或者在确认风险后采取其他修复措施。

安装并执行第一次扫描

根据资料提供的用法，可以先全局安装 CLI：

npm install -g cve-lite-cli

进入项目目录后，执行本地扫描：

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

这里的 /path/to/project 应替换为实际项目路径。若当前终端已经位于项目目录，也应以工具文档支持的项目路径写法为准，不要自行添加未确认的参数。

第一次扫描建议保留详细输出。详细结果有助于回答以下问题：

• 哪个依赖或依赖路径触发了漏洞匹配；
• 该依赖是项目直接声明的，还是由其他依赖间接引入；
• 工具建议更新哪个依赖；
• 修复是否可能涉及依赖树中的其他版本变化。

资料显示，CVE Lite CLI 会使用 OSV 数据库识别已知漏洞，并根据依赖关系提供修复路径。它的价值不只是输出漏洞编号，而是把“发现问题”进一步连接到“应该检查哪条依赖链”。

先读懂结果，再执行修复

扫描结果不应被简单理解为一张需要全部立即清除的漏洞清单。更稳妥的处理顺序是先确认漏洞、依赖关系和项目实际使用情况，再决定升级方式。

确认漏洞对应的依赖路径

同一个存在风险的包，可能是项目直接依赖，也可能由构建工具、测试工具或其他运行时依赖间接引入。两种情况的修复动作不同。

如果是直接依赖，通常先检查项目清单中声明的版本范围，再评估升级到修复版本对接口、构建和运行时行为的影响。不要只修改一个版本字符串后就结束，因为锁文件也需要随依赖变更重新生成并纳入审查。

如果是间接依赖，应沿着工具给出的依赖路径向上检查。优先判断上游直接依赖是否存在可用升级版本，而不是立即手工修改锁文件中的某个嵌套条目。直接编辑锁文件可能在下一次安装依赖时被重新解析，导致修复消失，也可能造成依赖树不一致。

区分“发现漏洞”和“确认可利用”

依赖扫描工具通常依据公开漏洞信息与版本匹配来提示风险。这个结果说明项目使用的依赖版本与已知漏洞信息存在关联，但它不等同于已经证明当前应用一定可以被利用。

复核时应结合项目实际情况检查：

• 受影响依赖是否会进入生产环境；
• 相关功能是否在项目中启用；
• 依赖的调用路径是否可能接收外部输入；
• 升级后是否改变构建、测试或运行时行为。

这些复核不会让扫描结果失效，而是帮助团队确定修复优先级。对于无法立即升级的情况，也应记录原因、影响范围和后续处理人，而不是用忽略规则简单掩盖结果。

使用修复辅助功能时保持可审查

资料中提到，CVE Lite CLI 支持复制并运行的修复建议，也提供 --fix 自动修复能力。自动修复适合减少重复操作，但不应替代代码评审和依赖变更审查。

可以采用这样的工作方式：

1. 先执行普通扫描，保存初始结果；
2. 阅读漏洞对应的依赖路径和建议变更；
3. 在独立分支中执行建议的升级操作，或评估 --fix 的修改内容；
4. 检查项目清单、锁文件和构建结果；
5. 运行项目已有的测试与安全相关检查；
6. 再次扫描，确认原问题是否消失，以及是否产生新的依赖变化。

如果工具给出了针对包管理器的修复命令，应先确认命令作用范围，再执行。不要把修复命令直接用于生产分支，也不要在不了解变更内容的情况下批量接受升级。依赖升级可能改变间接依赖版本，甚至引入新的兼容性问题，因此“扫描结果变干净”仍然需要配合构建和测试验证。

用 JSON 结果接入复核流程

当需要把扫描结果交给其他工具处理，或者希望在代码评审中保存机器可读结果时，可以使用资料中出现的 JSON 输出方式：

cve-lite . --json

该输出可以用于保留扫描记录、辅助分析发现项，或作为发布前检查的输入。实际接入时，应注意结果文件中是否包含项目路径、依赖名称或其他内部信息，并根据团队的仓库权限决定是否提交。

JSON 结果的作用是提高处理一致性，不是自动替团队完成风险判断。安全工程师或开发者仍需要确认漏洞与依赖路径、评估升级影响，并在合并请求中说明修复或暂缓修复的理由。

发布前建立一个可重复的检查节点

依赖扫描最适合放在开发者能够及时处理问题的阶段，而不是等到发布流程末尾才第一次发现漏洞。对于 JavaScript 或 TypeScript 项目，可以把扫描安排在以下节点：

• 依赖发生变更时；
• 合并依赖升级分支前；
• 创建发布候选版本前；
• 发布生产版本前；
• 项目需要复核历史依赖风险时。

发布前检查不必只看“是否存在任意漏洞”。更重要的是明确团队的处置规则：哪些结果必须阻止发布，哪些结果可以在记录风险后继续，哪些结果需要安全人员进行人工复核。具体门槛应由项目的运行环境、数据敏感程度和发布策略决定，不能在没有依据的情况下套用统一阈值。

如果工具支持离线扫描场景，也要确认本地漏洞数据是否满足当前复核需要。离线能力适合受限网络或不希望上传项目内容的环境，但漏洞数据本身需要保持适当更新，否则扫描结果可能无法反映新的公告变化。

它与静态代码分析不是一回事

CVE Lite CLI 的主要对象是项目锁文件中的依赖漏洞，静态代码分析则关注源代码中的潜在安全问题。两者可以协同使用，但不能互相替代。

依赖扫描主要帮助回答：

• 项目实际安装了哪些依赖版本；
• 某个依赖版本是否匹配已知漏洞信息；
• 风险依赖是直接引入还是间接引入；
• 应从哪条依赖链开始升级和复核。

静态代码分析主要用于检查业务代码和配置中的安全模式，例如不安全的输入处理、危险的数据流、权限判断缺失或不安全的 API 使用。即使所有依赖漏洞都已经处理，业务代码仍可能存在安全缺陷；反过来，代码分析也无法替代对锁文件中第三方依赖版本的核对。

因此，发布前的安全检查应把两类结果分开记录：依赖扫描负责依赖版本与漏洞关系，静态分析负责源代码和配置逻辑。出现问题时，修复路径也不同，不能因为静态分析没有发现问题，就认为依赖风险已经消失。

常见误区：把扫描通过当成安全证明

扫描没有报告结果，只能说明在当前锁文件、当前漏洞数据和工具识别范围内没有发现匹配项。它不能证明项目没有业务漏洞，也不能证明所有依赖风险都已经被人工确认。

更可靠的闭环应包括：扫描、理解依赖路径、选择升级方式、验证项目行为、再次扫描，以及在必要时记录无法立即修复的风险。对于一次性执行命令后就丢弃结果的做法，团队很难判断漏洞是否反复出现，也无法确认后续依赖变更有没有重新引入问题。

把扫描结果转化为行动时，最小可行流程是：先定位实际受影响的依赖，再选择可审查的升级变更，随后运行项目验证，最后在发布前重新检查。这样，工具输出的就不再只是漏洞数量，而是一组能够进入依赖维护和发布决策的证据。