| 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 —— 开源依赖检查工具
