很多项目上线前只检查页面和接口是否可用，却没有认真看依赖清单。真正危险的地方往往藏在传递依赖、过时版本、漏洞公告和许可证要求里。一次依赖审查不需要很复杂， 但必须能回答：项目用了什么、哪里有风险、应该先处理哪一类问题。

为什么上线前要做依赖审查

现代项目很少只依赖自己写的代码。一个小工具包可能继续引入十几个间接依赖，前端构建、服务端运行、测试脚本又各有不同的依赖范围。 如果只看 package.json 里的直接依赖，很容易漏掉实际进入安装树的版本。

  • 安全风险：某个包可能被 npm 或 GitHub 安全公告标记为有漏洞，需要确认影响范围和修复版本；
  • 许可证风险：MIT、Apache-2.0、GPL-3.0 等许可证对署名、分发和相同许可有不同要求；
  • 升级风险：大版本升级可能带来破坏性变更，补丁版本通常更适合优先处理；
  • 维护风险：长期未更新、重复版本过多或依赖层级过深，都会增加后续排查成本。
不要把工具提示当成最终结论
依赖分析器可以帮助你发现风险线索，但不能替代安全团队、法务或开源合规流程。真正上线前仍要结合实际运行路径、部署环境和许可证原文做确认。

应该上传哪些文件

在 依赖分析器 中，优先上传能还原实际安装结果的文件。只上传声明文件能看到直接依赖， 同时上传 lockfile 才更接近生产构建时安装到的具体版本。

  • Node.js 项目：上传 package.json，并配合 package-lock.json、yarn.lock 或 pnpm-lock.yaml；
  • Python 项目：上传 requirements.txt 或 Pipfile，确认生产环境和开发环境是否拆分；
  • Java 项目：上传 pom.xml，先看直接依赖和版本声明，再回到项目构建工具确认传递依赖。
lockfile 很重要
依赖声明写的是范围，lockfile 记录的是一次解析后的具体版本。排查漏洞和复现构建问题时，具体版本比“允许安装的版本范围”更有用。

一次实用的依赖体检流程

  1. 1
    先解析依赖树
    上传依赖文件后，先看项目名、包管理器、总依赖数、直接依赖和间接依赖比例，判断项目复杂度。
  2. 2
    按运行影响排序
    优先查看 production 依赖，再处理开发依赖。线上运行路径里的漏洞，通常比只在本地构建脚本里出现的风险更紧急。
  3. 3
    检查安全公告
    使用 Pro 安全检查查看漏洞数量、严重程度和来源提示，再回到官方公告确认影响版本、修复版本和利用条件。
  4. 4
    复核许可证
    关注 GPL-3.0、未知许可证和需要相同许可分发的依赖，把需要法务确认的条目单独列出来。
  5. 5
    导出可执行清单
    把高优先级依赖、建议升级版本、许可证问题和负责人整理成报告，方便进入 PR、工单或发布检查表。

免费版和 Pro 分别适合做什么

免费版适合快速看清依赖结构和基础统计；Pro 更适合上线前、客户交付前或团队审查时使用，因为它把安全、许可证和报告沉淀纳入同一个流程。

能力免费版Pro
依赖文件解析与基础统计支持支持
直接依赖与传递依赖梳理支持支持
依赖关系可视化树图 / 关系图等视图
漏洞检查与安全评分按严重程度查看
许可证合规分析识别风险级别
审查报告导出JSON / CSV 等格式

看漏洞时别只看数量

漏洞数量只能说明“有多少条提示”，不能直接代表项目一定可被攻击。真正需要判断的是：漏洞依赖是否进入生产包、当前版本是否落在影响范围内、 是否有可用修复版本，以及你的业务是否暴露了触发路径。

建议按 4 个层级处理

  • 立即处理：critical / high 且进入生产运行路径，并且已有明确修复版本；
  • 排期处理：medium 或只影响特定调用路径，但升级成本可控；
  • 人工确认：公告描述宽泛、影响范围不清楚，或依赖只在开发工具链中使用；
  • 记录接受：确认不影响当前项目，但保留证据和复查日期。
实操案例

发版前发现 lodash 漏洞提示

团队在发版前上传了 package.json 和 lockfile，安全检查发现某个传递依赖链里出现 lodash 的漏洞提示。
  1. 1.先确认它是否在 production 依赖链中，而不是只出现在测试或构建工具里。
  2. 2.查看漏洞来源、当前版本和修复版本，再判断是否可以通过升级直接依赖来带动传递依赖更新。
  3. 3.如果无法当天升级，记录影响路径、临时缓解措施和下一次复查时间，不把“看到了提示”当成“已经修复”。
得到什么：风险被拆成可执行事项：哪些要升级、哪些要验证、哪些需要暂时接受，并能沉淀到发布记录里。

许可证检查要关注哪些信号

许可证合规不是只看“能不能商用”。同样是开源许可证，不同协议对署名、版权声明、修改分发、专利授权和相同许可有不同要求。 依赖分析器能帮你快速聚合许可证信息，但涉及分发、嵌入 SDK、闭源商业交付时，仍应让负责人复核许可证原文。

  • MIT、BSD、ISC 等宽松许可证通常风险较低，但仍要保留必要署名；
  • Apache-2.0 通常允许商用，同时包含专利授权和 NOTICE 相关要求；
  • GPL 类许可证可能带来相同许可分发义务，闭源交付前必须重点确认；
  • Unknown 或自定义许可证不应直接忽略，至少要追溯包仓库和发布说明。
面向协作的输出更有价值
给团队看的依赖报告不需要堆满全部原始 JSON。更实用的格式是：包名、当前版本、风险类型、建议动作、负责人和截止时间。

升级 Pro，把依赖审查变成可交付清单

PRO

在基础依赖解析之外，继续查看漏洞提示、许可证风险、可视化结构和可导出的审查结果，适合发版、交付和团队协作。

  • 按严重程度查看漏洞提示和安全评分
  • 识别许可证风险级别与商业使用信号
  • 用树图 / 关系图定位关键依赖链
  • 导出 JSON / CSV 审查结果用于工单和发版记录

上线前依赖审查清单

  • 上传声明文件和 lockfile，确认分析的是接近真实安装的版本；
  • 先处理 production 依赖里的 critical / high 提示，再看开发依赖；
  • 对 GPL、未知许可证和自定义许可证建立人工复核记录；
  • 把升级建议拆成小 PR，避免一次性大版本升级引入额外回归；
  • 导出结果并写入发版记录，注明已修复、已接受和待复查项目。

常见问题

只上传 package.json 可以吗？

可以做初步分析，但不够完整。package.json 常常只声明版本范围，lockfile 才记录实际安装的具体版本。检查漏洞、复现构建和定位传递依赖时，建议同时上传 lockfile。

漏洞扫描显示 0 个就代表安全吗？

不能这样理解。0 个提示只说明当前数据源没有返回匹配项，不代表代码没有安全问题。还要检查业务代码、配置、密钥管理、运行环境和依赖是否真的进入生产路径。

开发依赖里的漏洞需要马上修吗？

要看使用场景。如果漏洞只影响本地测试工具，优先级通常低于生产依赖；但如果它参与构建、发布、代码生成或 CI 流程，仍可能影响供应链安全，应该排期处理。

许可证显示可以商用就不用管了吗？

还需要看署名、NOTICE、修改分发、相同许可和专利条款等要求。工具提示适合快速筛查，高风险或未知许可证应回到许可证原文和项目仓库确认。

依赖关系图有什么实际作用？

关系图能帮助你看到某个风险包是由哪个上游依赖引入的。处理传递依赖时，通常不是直接改风险包，而是升级或替换把它带进来的直接依赖。

可以先用 依赖分析器 跑一遍当前项目，再把需要进一步验证的条目整理到JSON 格式化工具 或团队工单中。依赖审查的目标不是制造焦虑，而是让每个风险都有清楚的下一步。