mcpField
D
dependency-audit

dependency-audit

github.com/mohitagw15856安全1.5k40 次安装5 天前更新
代码仓库

关于 dependency-audit

dependency-audit 是为软件团队生成依赖审计报告的 Skill，涵盖安全、许可证、版本和传递依赖风险，并整理成有优先级的修复步骤与时间表。

主要功能

  1. 01基于 CVE 的漏洞发现
  2. 02许可证策略合规审查
  3. 03按风险排序过时软件包
  4. 04传递依赖风险分析
  5. 05含时间表的修复计划

适用场景

  1. 01发布前审查项目依赖
  2. 02确定已发现 CVE 的修复优先级
  3. 03核对软件包是否符合许可证策略
  4. 04规划高风险或停止维护软件包的升级

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/mohitagw15856/pm-claude-skills --skill dependency-audit

安装后在 Claude Code 中输入/dependency-audit确认已加载。

详细介绍

依赖项审计技能

为项目生成完整的依赖项审计报告，涵盖安全漏洞（附 CVE 参考）、许可证合规性检查、按风险优先级排列的过时软件包、传递依赖风险分析，以及包含时间表的具体修复计划。优质的依赖项审计能为团队提供清晰、按优先级排列的行动清单，而不是一份无人采取行动的原始审计输出。

所需输入

如果尚未提供，请询问以下信息：

  • 项目语言和生态系统 — npm、pip/PyPI、Maven/Gradle、Go modules、Cargo、RubyGems、NuGet，或混合生态系统
  • 依赖项列表或软件包清单 — 粘贴 package.json、requirements.txt、go.mod、pom.xml 等文件的内容，或提供审计工具的输出
  • 许可证政策 — 哪些许可证允许使用，哪些受限制（例如“禁止使用 GPL”“仅限 MIT/Apache/BSD”，或“尚无政策 — 请提出建议”）
  • 当前安全工具 — Dependabot、Snyk、OWASP Dependency-Check、npm audit、pip-audit，或无

输出格式

依赖项审计报告：[项目名称]

生态系统： [npm / pip / Maven / Go / 等] 审计日期： [日期] 审计人员： [姓名] 直接依赖项总数： [N] 传递依赖项总数： [N] 使用的审计工具： [npm audit / pip-audit / Snyk / OWASP Dependency-Check / 等]

执行摘要

类别发现风险级别
严重漏洞[N] 个需要立即处理的 CVE[严重 / 高 / 低]
高危漏洞[N] 个 CVE — 需在 7 天内修复[高 / 中]
许可证违规[N] 个软件包使用了不合规许可证[高 / 低]
严重过时的软件包[N] 个软件包落后超过 2 个主版本[中]
无积极维护的软件包[N] 个软件包 — 12 个月以上无提交记录[中]
依赖项整体健康评分[评分]/100[红 / 黄 / 绿]

评分方法： 严重 CVE：每个扣 20 分。高危 CVE：每个扣 10 分。许可证违规：每项扣 15 分。已弃用的软件包：每个扣 5 分。最高扣分：100。评分 ≥80 为绿色，60–79 为黄色，<60 为红色。

需立即采取的行动：

  1. [最紧急的行动 — 例如“将 lodash 从 4.17.11 升级到 4.17.21，以修复 CVE-2021-23337（严重 — 原型污染）”]
  2. [第二项行动]
  3. [第三项行动]

1. 安全漏洞发现

严重和高危漏洞（24–72 小时内处理）
软件包已安装版本修复版本CVE严重程度CVSS 评分描述可利用性
[package-name][X.Y.Z][A.B.C][CVE-YYYY-NNNNN]严重[9.x][例如：通过 merge 函数造成原型污染 — 可能导致远程代码执行][已知利用方式 / 有 PoC 可用 / 无已知利用方式]
[package-name][X.Y.Z][A.B.C][CVE-YYYY-NNNNN]高[7.x][例如：文件服务工具中的路径遍历][有 PoC 可用]
[package-name][X.Y.Z][A.B.C][CVE-YYYY-NNNNN]高[7.x][例如：正则表达式拒绝服务（ReDoS）][无已知利用方式]
中危漏洞（30 天内修复）
软件包已安装版本修复版本CVE严重程度CVSS 评分描述
[package-name][X.Y.Z][A.B.C][CVE-YYYY-NNNNN]中[5.x][描述]
[package-name][X.Y.Z][A.B.C][CVE-YYYY-NNNNN]中[4.x][描述]
低危漏洞（90 天内修复或接受风险）
软件包已安装版本修复版本CVE严重程度描述
[package-name][X.Y.Z][A.B.C]低[描述]
暂无可用修复方案的漏洞
软件包CVE严重程度建议的缓解措施
[package-name][CVE-YYYY-NNNNN][高][例如：“移除此软件包 — 替代方案：[替代品]”]
[package-name][CVE-YYYY-NNNNN][中][例如：“供应商正在开发修复方案 — 跟踪问题 [URL]。通过 [X] 进行缓解”]

2. 许可证合规矩阵

许可证政策参考
许可证类别政策备注
MIT宽松型允许在分发的产品中必须注明出处
Apache 2.0宽松型允许必须注明出处并包含 NOTICE 文件
BSD 2-Clause / 3-Clause宽松型允许必须注明出处
ISC宽松型允许
MPL 2.0弱著佐权经审查后允许仅修改过的 MPL 文件需要公开源代码
LGPL v2 / v3弱著佐权经审查后允许允许动态链接；静态链接可能需要公开源代码
GPL v2 / v3强著佐权受限可能要求将整个代码库开源——必须经过法律审查
AGPL v3强著佐权受限网络使用会触发著佐权要求——对 SaaS 尤其有风险
SSPL源码可用禁止未经 OSI 批准——应视为专有许可证
专有 / 商业商业需要合同确认许可证涵盖当前用例和规模
未知 / 无许可证—禁止无许可证 = 保留所有权利——无法合法使用
发现：存在合规问题的包
包许可证问题建议未解决时的风险
[package-name]GPL v3著佐权——可能要求将本项目开源替换为 [alternative] 或取得法律批准法律 / 知识产权风险
[package-name]AGPL v3网络著佐权——用于 SaaS 会触发披露要求替换为 [alternative]法律 / 知识产权风险
[package-name]专有许可证可能不涵盖当前使用层级与供应商确认许可证范围违反合同
[package-name]未知包元数据中未声明许可证联系维护者或替换无法合法使用
正在使用的所有许可证（完整清单）
许可证包数量合规状态
MIT[N]合规
Apache 2.0[N]合规
BSD-3-Clause[N]合规
ISC[N]合规
MPL 2.0[N]需要审查
GPL v3[N]不合规
未知[N]不合规

3. 过时包分析

严重过时（落后 2 个或更多主版本——升级工作量大）
包已安装版本最新稳定版落后版本数上次更新时间破坏性变更摘要
[package-name][1.x.x][3.x.x]2 个主版本[Date][例如：“v2 中重新设计了 API；v3 中新增异步支持”]
[package-name][0.x.x][2.x.x]2 个主版本[Date][Summary]
中度过时（落后 1 个主版本）
包已安装版本最新稳定版落后版本数较新版本中是否包含安全修复？
[package-name][2.x.x][3.x.x]1 个主版本[是 — CVE-YYYY-NNNNN / 否]
[package-name][4.x.x][5.x.x]1 个主版本[否]
有小版本 / 补丁更新可用（更新风险低）
包已安装版本最新版本是否包含安全修复？
[package-name][2.3.1][2.3.9][是 / 否]
[package-name][1.0.0][1.2.1][否]

4. 依赖关系图风险分析

传递依赖风险

传递（间接）依赖存在风险，因为它们并未得到明确管理。以下是本项目中风险最高的传递依赖：

存在漏洞的传递依赖引入该依赖的包已安装版本是否有可用修复操作
[transitive-package][direct-parent][X.Y.Z][有 — 将 [parent] 升级到 [version]]升级直接依赖 [parent]
[transitive-package][direct-parent][X.Y.Z][无]移除 [parent] 或使用 [alternative]
依赖集中风险

这些软件包被项目中的许多其他软件包依赖——一旦出现漏洞或弃用，就会产生连锁影响：

软件包被依赖次数（N 个软件包）是否在积极维护？风险等级
[package-name][N][是 / 否 — 最近一次提交：date][高 / 中]
[package-name][N][是][中]
已放弃 / 无人维护的软件包
软件包最近发布最近一次提交每周下载量推荐替代方案
[package-name][Date][Date][N][alternative-package]
[package-name][Date][Date][N][维护中的分支：URL]

5. 修复计划

30 天计划

第 1 周 — 严重漏洞（第 1–7 天）

操作负责人软件包所需时间备注
将 [package] [old] 升级至 [new][Name][package-name][30 min][无 API 变更 / 查看重大变更指南：URL]
将 [package] 替换为 [alternative][Name][package-name][2 hours][没有可用的修复方案 — 必须替换]
为 [transitive-dep] 添加补丁覆盖[Name][transitive-dep][15 min][在清单中添加 resolutions/overrides 条目]
# Commands for Week 1 upgrades:

# npm
npm install [package]@[target-version]
npm audit fix --force  # use with caution — may introduce breaking changes

# pip
pip install --upgrade [package]==[target-version]
pip-audit --fix  # if using pip-audit

# Go
go get [module]@[version]
go mod tidy

# Maven
# Update pom.xml version property, then:
mvn versions:use-latest-releases -DallowMajorUpdates=false
mvn dependency:resolve

第 2 周 — 高危漏洞和许可证违规（第 8–14 天）

操作负责人软件包所需时间备注
升级 [package][Name][package-name][1 hour]
替换采用 GPL 许可证的 [package][Name][package-name][4 hours][替代方案：[package]]
对 [package] 的许可证进行法律审查法务团队[package-name][法务团队 SLA][通过 [process] 提交]

第 3 周 — 中危漏洞和已放弃的软件包（第 15–21 天）

操作负责人软件包所需时间备注
升级 [package][Name][package-name][30 min]
替换已放弃的 [package][Name][package-name][2 hours][维护中的分支或替代方案：[URL]]

第 4 周 — 流程改进（第 22–30 天）

操作负责人所需时间备注
启用 Dependabot / Renovate，以自动创建 PR[Name][2 hours][配置见第 6 节]
在 CI 中添加 npm audit / pip-audit — 发现严重/高危问题时使构建失败[Name][1 hour][配置见第 6 节]
在 CONTRIBUTING.md 中记录许可证政策[Name][1 hour][依据第 2 节中的政策]
安排下一次季度审计[Name][15 min][添加到团队日历]

6. 政策建议

在 CI 中自动扫描漏洞

在 CI 流水线中添加以下内容，以便在合并前发现漏洞：

# GitHub Actions — adapt for your CI platform
dependency-audit:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v3

    # npm
    - name: npm audit
      run: npm audit --audit-level=high
      # Fails build on High or Critical vulnerabilities

    # pip
    - name: pip-audit
      run: |
        pip install pip-audit
        pip-audit --requirement requirements.txt --severity high

    # Go
    - name: govulncheck
      run: |
        go install golang.org/x/vuln/cmd/govulncheck@latest
        govulncheck ./...
Dependabot / Renovate 配置
# .github/dependabot.yml — automated dependency update PRs
version: 2
updates:
  - package-ecosystem: "[npm / pip / gomod / maven]"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
    open-pull-requests-limit: 10
    labels:
      - "dependencies"
      - "automated"
    ignore:
      # Ignore major version bumps — review these manually
      - dependency-name: "*"
        update-types: ["version-update:semver-major"]
许可证扫描
# npm — license checker
npx license-checker --onlyAllow 'MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC' \
  --failOn 'GPL;AGPL;LGPL'

# Python — pip-licenses
pip install pip-licenses
pip-licenses --allow-only="MIT;Apache Software License;BSD License;ISC License" \
  --fail-on="GNU General Public License"

# Go — go-licenses
go install github.com/google/go-licenses@latest
go-licenses check ./... --allowed_licenses=MIT,Apache-2.0,BSD-2-Clause,BSD-3-Clause

7. 依赖健康度评分详情

类别最高分得分备注
无严重漏洞30[N]/30每个严重 CVE 扣 20 分
无高危漏洞20[N]/20每个高危 CVE 扣 10 分
许可证合规20[N]/20每项违规扣 15 分
无已放弃的软件包15[N]/15每个已放弃的软件包扣 5 分
使用最新的主版本10[N]/10每落后一个主版本扣 2 分
已启用自动扫描5[N]/5满分制
总计100[Score]/100[红色 / 琥珀色 / 绿色]

质量检查

  • 每个严重和高危 CVE 都有具名负责人，并已在 30 天计划中注明解决日期
  • 许可证审查结果已由法务人员或有权接受风险的具名工程师审核
  • 已纳入传递依赖漏洞，而非仅检查直接依赖
  • 对已放弃的软件包给出了明确的替换建议，而非仅仅写“考虑替换”
  • 已纳入 CI 流水线变更 — 这次审计发现的问题应是最后一次通过人工检查发现的问题
  • 依赖健康度评分依据实际发现的问题计算，而非估算
  • 修复计划中的操作是具体命令或步骤，而非没有指定目标版本的“升级软件包 X”

反模式

  • 不要只报告直接依赖项——传递依赖项中的漏洞往往更危险，也最容易被遗漏
  • 不要不加解读地呈现原始审计工具输出——列出 200 个 CVE 却不做优先级排序，还不如完全不审计
  • 不要不检查使用场景中是否存在可利用路径，就将所有严重级别为 Critical 的 CVE 标为“立即修复”
  • 不要在未征求法律意见的情况下决定许可证合规问题——只标记 GPL 依赖项而不提供建议，属于工作未完成
  • 审计结束时必须包含 CI/CD 流水线步骤——一次性审计若为新漏洞敞开大门，就不算完成修复

示例触发短语

  • “审计依赖项。”
  • “审查软件包安全性。”
  • “检查许可证合规性。”
  • “评估依赖项健康状况。”
  • “生成漏洞报告。”

评论

支持 Markdown