| name | dependency-audit |
| description | 依赖审计方法论 —— CVE 扫描、许可证合规、版本锁定与升级策略 |
| category | security |
| loading | on-demand |
| triggers | {"keywords":["依赖检查","依赖审计","CVE","npm audit","pip audit","漏洞扫描"]} |
这是什么
依赖审计是对项目所引用的第三方库进行安全性、合规性和健康度的系统性评估。现代软件 80% 以上的代码来自第三方依赖,依赖安全是软件供应链安全的核心。
何时使用
- 新项目初始化,选择依赖时评估风险
- 定期审计(建议每次发布前执行)
- 收到 CVE 通报后评估影响
- 许可证合规审查
- 决定是否升级或替换某个依赖
核心规则
- 所有依赖都有风险:每个引入的第三方库都是一条信任链。依赖越少,风险面越小。
- 已知 CVE 必须处理:存在已知严重或高危 CVE 的依赖应立即升级或替换。中低危漏洞应制定修复计划。
- 许可证必须兼容:在商业产品中使用 GPL 依赖可能导致法律风险。使用前确认项目的许可证策略。
- 锁定版本:生产构建应使用 lockfile 确保可重现性。不受信任的版本范围(
^、~)可能导致意外引入问题。
- 最小间接依赖:引入一个直接依赖可能带入数十个间接依赖。评估时应考虑完整的依赖树。
工作流程
-
审计扫描
- 运行包管理器的审计命令扫描已知 CVE
- 使用专门的 SCA 工具(软件组合分析)进行深度扫描
- 检查间接依赖的漏洞,它们和直接依赖同样危险
-
漏洞评估
- 查看 CVE 的 CVSS 评分:9.0+ 为严重,7.0-8.9 为高危,4.0-6.9 为中危,4.0 以下为低危
- 评估实际影响:漏洞是否在当前使用场景下可被利用?
- 评估利用难度:是否有公开的 PoC 或利用代码?
- 优先修复「可远程利用 + 无需认证 + 严重」的漏洞
-
许可证检查
- 提取所有依赖的许可证类型
- 标记与项目许可证策略冲突的依赖
- 注意多许可证和双重许可证的依赖
- 区分宽松许可证(MIT、Apache 2.0、BSD)和传染性许可证(GPL、AGPL)
-
版本评估
- 检查依赖是否过期:与最新版本差距超过一个大版本应计划升级
- 检查依赖的维护状态:最近提交时间、Issue 响应速度、贡献者数量
- 对已停止维护的依赖制定替换计划
-
修复执行
- 优先直接升级到修复版本
- 无法升级时使用 Snyk、GitHub Advisory 等平台寻找缓解措施
- 记录无法立即修复的漏洞及缓解措施
- 更新 lockfile 并运行完整测试确保兼容性
漏洞分级与响应时间
| 严重程度 | CVSS 分数 | 响应时间 | 操作 |
|---|
| 严重 | 9.0-10.0 | 24 小时内 | 立即升级或临时下线受影响功能 |
| 高危 | 7.0-8.9 | 72 小时内 | 制定修复计划并尽快执行 |
| 中危 | 4.0-6.9 | 下一发布周期 | 加入迭代计划 |
| 低危 | 0.1-3.9 | 按需 | 评估后决定是否修复 |
版本锁定策略
- lockfile 必须进版本控制:确保团队和 CI 环境使用完全相同的依赖版本
- 定期更新 lockfile:建议每月执行一次依赖更新,而非积压一年
- 区分开发依赖和生产依赖:开发依赖的漏洞不影响用户,但仍需关注
- 依赖固定:关键依赖(加密库、框架核心)使用精确版本,避免自动升级
依赖健康度指标
- 维护活跃度:最近 3 个月有提交,Issue 响应时间在 2 周内
- 社区规模:贡献者数量、Star 数、使用量(下载量)
- 文档质量:有完善的文档和变更日志
- 安全记录:历史上的 CVE 数量、修复速度
- 向后兼容承诺:是否遵循 SemVer
许可证分类速查
| 许可证 | 类型 | 商业使用 | 修改后闭源 | 传染性 |
|---|
| MIT | 宽松 | 允许 | 允许 | 无 |
| Apache 2.0 | 宽松 | 允许 | 允许 | 无 |
| BSD 2-Clause | 宽松 | 允许 | 允许 | 无 |
| GPL 2.0/3.0 | 强传染 | 允许 | 不允许 | 强 |
| AGPL 3.0 | 强传染(含网络) | 允许 | 不允许 | 极强 |
| LGPL | 弱传染 | 允许 | 允许(动态链接) | 弱 |
| MPL 2.0 | 弱传染 | 允许 | 允许(文件级) | 弱 |
| BSL(Business Source) | 时限 | 有限制 | 到期后开放 | 按条款 |
供应链安全额外措施
- 签名验证:验证下载的依赖包是否有维护者的数字签名
- 镜像仓库:使用内部代理或镜像仓库,避免依赖突然不可用(左移安全)
- 依赖锁定:提交 lockfile 到版本库,确保所有环境使用相同版本
- 构建可重现:相同的源代码和依赖版本应产生完全相同的构建产物
- SLSA 框架:供应链级别安全保证框架,评估构建管道的完整性等级
审计自动化集成
- 在 CI 中集成依赖审计,每次提交自动检查新增依赖的漏洞
- 设置漏洞门槛:存在严重/高危漏洞时 CI 失败
- 定期生成 SBOM 报告并归档
- 配置依赖更新机器人自动提交 PR 更新依赖
参考标准
- NIST National Vulnerability Database (NVD) —— CVE 权威数据库
- CVSS v3.1 —— 通用漏洞评分系统
- OpenSSF Scorecard —— 开源项目安全评分
- SPDX 标准 —— 软件物料清单(SBOM)格式
- OWASP Dependency-Check —— 开源依赖检查工具