dep-audit

依赖项审计

跨仓库依赖项审计。扫描软件包清单（package.json、pyproject.toml、Cargo.toml、go.mod），检查过时的软件包、安全公告、仓库之间的版本冲突以及许可证兼容性问题，并生成优先级排序的更新计划。

安装

git clone https://github.com/thatrebeccarae/claude-marketing.git && cp -r claude-marketing/skills/dep-audit ~/.claude/skills/

适用场景

• 每月维护：定期运行，在依赖项漂移逐渐加剧前及时发现
• 发布前：确认没有已知漏洞随产品一同发布到生产环境
• 安全事件：出现 CVE 时，快速评估所有仓库的受影响情况
• 接入新仓库：为继承或采用的仓库建立依赖项健康状况基线

用法

• /dep-audit [repo-path] — 审计单个仓库
• /dep-audit [repo-path1] [repo-path2] ... — 跨仓库审计（启用版本冲突检测）

流程

1. 检测软件包管理器

扫描目标仓库中的清单文件：

管理器	清单	锁定文件
npm	package.json	package-lock.json
yarn	package.json	yarn.lock
pnpm	package.json	pnpm-lock.yaml
pip	requirements.txt、setup.py、setup.cfg	requirements.txt（固定版本）
poetry	pyproject.toml（包含 [tool.poetry]）	poetry.lock
uv	pyproject.toml（包含 [tool.uv]）	uv.lock
cargo	Cargo.toml	Cargo.lock
go mod	go.mod	go.sum

# Detect which manifests exist
ls package.json pyproject.toml Cargo.toml go.mod requirements.txt 2>/dev/null
# Detect lock files
ls package-lock.json yarn.lock pnpm-lock.yaml poetry.lock uv.lock Cargo.lock go.sum 2>/dev/null

如果存在多个生态系统（例如，包含 Node.js 前端和 Go 后端的单体仓库），请分别审计并合并结果。

2. 解析清单和锁定文件

读取清单以识别已声明的依赖项（直接依赖），并读取锁定文件以获取已解析的版本（传递依赖）。区分以下类型：

• 生产依赖项（dependencies、[dependencies]、主依赖）
• 开发依赖项（devDependencies、[dev-dependencies]、额外依赖）

3. 检查过时的软件包

查询软件包注册表以获取最新版本，并对版本差异分类：

# Node.js
npm outdated --json

# Python (pip)
pip list --outdated --format=json

# Python (poetry)
poetry show --outdated

# Rust
cargo outdated --format json  # requires cargo-outdated

# Go
go list -m -u all

为每个过时的软件包分类：

• 补丁更新（例如，2.3.1 -> 2.3.4）：风险较低，通常是错误修复
• 次要版本更新（例如，2.3.1 -> 2.5.0）：包含新功能，通常应向后兼容
• 主要版本更新（例如，2.3.1 -> 3.0.0）：可能存在破坏性变更，需要审查迁移方案

4. 检查安全公告

运行对应生态系统的原生审计工具：

# Node.js
npm audit --json

# Python
pip-audit --format=json  # or: safety check

# Rust
cargo audit --json  # requires cargo-audit

# Go
govulncheck ./...

根据结果判断严重程度：

• 严重：远程代码执行、身份验证绕过、数据外泄
• 高：权限提升、重大数据泄露
• 中：存在 DoS 风险、有限的数据泄露
• 低：信息泄露、轻微问题

5. 跨仓库分析（多个仓库）

审计两个或更多仓库时，请比较依赖项版本：

• 版本冲突：同一软件包在不同仓库中使用不同版本（例如，仓库 A 中的 [email protected]，仓库 B 中的 [email protected]）
• 共享依赖项：多个仓库使用、可统一到同一版本的软件包
• 主要版本不一致：将其标记为最高优先级——这表明各仓库正在逐渐分化

提供冲突表，列出软件包、各仓库中的版本以及建议的目标版本。

6. 许可证扫描

根据兼容性规则检查依赖项许可证：

# Node.js
npx license-checker --json

# Python
pip-licenses --format=json

# Rust
cargo license --json  # requires cargo-license

# Go
go-licenses report ./...  # requires go-licenses

标记以下问题：

• 宽松许可证项目中的著佐权许可证：MIT/Apache 许可证项目中包含 GPL/AGPL 依赖项
• 未知或缺失的许可证：没有许可证元数据的依赖项
• 未经 OSI 批准的许可证：自定义或具有限制性的许可证
• 许可证冲突：不兼容的许可证组合（例如，仅 GPLv2 与 Apache-2.0）

7. 生成更新计划

将所有发现按优先级整理成一个有序列表：

1. 严重安全公告 — 立即修复
2. 高危安全公告 — 本迭代修复
3. 许可证违规 — 评估并处理
4. 存在已知问题的重大版本过旧 — 规划迁移
5. 跨仓库版本冲突 — 统一版本
6. 次要版本过旧 — 批量更新
7. 补丁版本过旧 — 批量更新

将相关更新归组：

• 所有 @types/* 包放在一个 PR 中
• 同一组织的所有包（例如 @babel/*）
• 必须一起升级的对等依赖链

注明任何重大版本更新的破坏性变更风险。有迁移指南时附上链接。

8. 报告

生成按严重程度编码的摘要表：

优先级	包	当前版本	最新版本	类型	严重程度	受影响的仓库	操作
1	lodash	4.17.19	4.17.21	patch	CRITICAL (CVE-2021-23337)	repo-a, repo-b	立即更新
2	express	4.17.1	4.21.2	minor	HIGH (CVE-2024-29041)	repo-a	本迭代更新
3	webpack	4.46.0	5.94.0	major	MEDIUM（版本过旧）	repo-a	规划迁移
...

随后列出：

• 每个仓库的依赖总数（直接 / 间接）
• 安全摘要：X 个严重，Y 个高危，Z 个中危，W 个低危
• 版本过旧摘要：X 个重大，Y 个次要，Z 个补丁
• 许可证摘要：X 个被标记，Y 个正常
• 跨仓库冲突：X 个存在版本差异的包

核心原则

1. 绝不自动更新。 此技能用于审计并提供建议，由人工决定何时更新哪些内容。自动更新可能引入破坏性变更，尤其是重大版本更新。
2. 安全优先。 无论其他依赖有多旧，严重和高危漏洞始终排在优先级列表的最前面。
3. 将相关更新归组。 更新 react 而不更新 react-dom 会造成版本不匹配。务必识别对等依赖链。
4. 考虑具体情况。 仅用于开发的依赖（例如 eslint）进行重大版本升级，其风险低于生产运行时依赖存在 CVE 时仅进行补丁更新。
5. 以锁文件为准。 始终读取锁文件以确认实际解析的版本，而不只是清单中的版本范围说明符。
6. 不要为了追新而追新。 如果某个依赖运行正常、稳定且没有安全公告，那么“版本过旧”并不等于“已损坏”。

如何使用此技能

可以这样询问：

• “审计 ~/Repos/my-app 中的依赖”
• “比较这三个仓库中的依赖版本”
• “这个项目有没有安全漏洞？”
• “在将这个仓库开源之前检查许可证问题”
• “为所有落后的依赖制定更新计划”

命令参考、许可证兼容性详情和误报处理方式请参阅 REFERENCE.md。 示例请参阅 EXAMPLES.md。