依赖健康检查

跨技术生态审计项目依赖项，涵盖安全性、时效性、许可证合规性以及未使用的冗余包。输出一份带风险评估的优先级升级计划。

适用场景：「检查我们的依赖项」、「我们是否已更新至最新版本」、「审计软件包」、「规划升级」、「查找未使用的依赖项」。

步骤 1 — 检测技术生态

# 自动识别包管理器
ls package.json package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null   # Node.js
ls requirements.txt Pipfile pyproject.toml setup.py 2>/dev/null           # Python
ls Cargo.toml Cargo.lock 2>/dev/null                                       # Rust
ls go.mod go.sum 2>/dev/null                                               # Go
ls composer.json composer.lock 2>/dev/null                                 # PHP
ls Gemfile Gemfile.lock 2>/dev/null                                        # Ruby

步骤 2 — 过时的软件包

Node.js

npm outdated --json 2>/dev/null | jq 'to_entries[] | {name: .key, current: .value.current, wanted: .value.wanted, latest: .value.latest}'
# 或
yarn outdated --json 2>/dev/null
pnpm outdated --format json 2>/dev/null

Python

pip list --outdated --format json 2>/dev/null | jq '.[] | {name, version, latest_version}'
# 或配合 pip-audit
pip-audit --format json 2>/dev/null

Rust

cargo outdated -R --format json 2>/dev/null

Go

go list -u -m -json all 2>/dev/null | jq 'select(.Update) | {Path, Version, Update: .Update.Version}'

PHP

composer outdated --format json 2>/dev/null

步骤 3 — 漏洞扫描

# Node.js
npm audit --json 2>/dev/null | jq '.vulnerabilities | to_entries[] | {name: .key, severity: .value.severity, fixAvailable: .value.fixAvailable}'

# Python
pip-audit --format json 2>/dev/null
# 或
safety check --json 2>/dev/null

# Rust
cargo audit --json 2>/dev/null

# Go
govulncheck ./... 2>/dev/null

# 通用方案（如已安装）
trivy fs --format json --scanners vuln . 2>/dev/null | jq '.Results[].Vulnerabilities[]? | {PkgName, Severity, Title}'

步骤 4 — 未使用的依赖项

Node.js

# depcheck 可发现未使用的依赖项
npx depcheck --json 2>/dev/null | jq '{unused: .dependencies, devUnused: .devDependencies, missing: .missing}'

Python

# 比对实际导入与 requirements 声明
pip install pipreqs 2>/dev/null
pipreqs . --print 2>/dev/null > /tmp/actual-imports.txt
diff <(sort requirements.txt | sed 's/[>=<].*//' | tr '[:upper:]' '[:lower:]') 
     <(sort /tmp/actual-imports.txt | sed 's/[>=<].*//' | tr '[:upper:]' '[:lower:]')

Rust

cargo udeps 2>/dev/null  # 需使用 nightly 工具链

步骤 5 — 许可证审计

# Node.js
npx license-checker --json 2>/dev/null | jq 'to_entries[] | {pkg: .key, license: .value.licenses}' | head -40

# Python
pip-licenses --format json 2>/dev/null | jq '.[] | {Name, License}'

# 通用方案
trivy fs --format json --scanners license . 2>/dev/null

需重点关注的情形：MIT 项目中引入 GPL 包、SaaS 产品中引入 AGPL 包、未知/无许可证包、双重许可证包。

步骤 6 — 风险评估

对每个过时的依赖项，需评估以下四点：

1. 严重程度：critical（存在已知 CVE）＞ high（落后 ≥2 个主版本）＞ medium（落后次版本）＞ low（仅落后补丁版本）
2. 破坏性变更：查阅当前版本与最新版本之间的变更日志（Changelog）或发布说明（Release Notes）
3. 使用频率：通过 grep 搜索导入语句 —— 使用越频繁的依赖，升级风险越高
4. 测试覆盖率：若该依赖所涉功能区域具备良好测试覆盖，则升级更安全

输出模板

# 依赖健康报告

**项目名称：** [name]
**扫描时间：** [date]
**技术生态：** Node.js、Python 等

## 概览
- 总依赖数：X
- 过时依赖：X（其中 Y 个为 critical，Z 个落后 ≥2 主版本）
- 已知漏洞：X（其中 Y 个为 critical，Z 个为 high）
- 未使用依赖：X（可安全移除）
- 许可证问题：X

## 高危项（立即修复）
| 软件包 | 当前版本 | 最新版本 | 问题 | 风险 |
|--------|----------|----------|------|------|
| lodash | 4.17.20 | 4.17.21 | CVE-2021-23337（原型污染） | 高 — 在 47 个文件中被引用 |

## 推荐升级（本迭代周期内）
| 软件包 | 当前版本 | 最新版本 | 是否含破坏性变更 | 预估工作量 |
|--------|----------|----------|------------------|------------|
| react | 17.0.2 | 18.3.1 | 是 — 引入并发模式及新 Root API | 2–4 小时 |

## 安全快速收益（仅补丁更新）
可低风险升级的软件包：
- `axios`: 1.6.0 → 1.7.2（仅修复 bug）
- `dotenv`: 16.3.1 → 16.4.5（无破坏性变更）

## 未使用依赖（建议移除）
- `moment` — 全项目未导入，已被 date-fns 替代
- `@types/express` — 项目中未发现 Express 相关代码

## 许可证警示
- `gpl-package@1.0`: 项目采用 MIT 协议，但引入了 GPL-3.0 协议包 —— 请审查兼容性

升级工作流

完成审计后执行：

1. 优先修复高危漏洞（npm audit fix、pip-audit --fix）
2. 移除未使用的依赖项
3. 将补丁级更新合并至单个 PR 中提交
4. 针对主版本升级，单独规划并创建专用 PR
5. 每次批量升级后均需运行全部测试用例

注意事项

• 每次升级后，务必运行项目自身的完整测试套件
• 对于 monorepo，应分别对每个 workspace 执行独立审计
• npm audit fix --force 可能引入破坏性变更 —— 建议优先采用定向修复
• 每次进行主版本升级前，请查阅对应项目的 CHANGELOG.md 或 GitHub Releases 页面