Back to Details

dependency-audit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Dependency Audit

依赖审计

Comprehensive dependency risk assessment: license compatibility analysis, maintenance health scoring, CVE detection, bloat identification, and transitive dependency risk mapping. Produces an actionable report with prioritized remediation steps organized by urgency (security → license → maintenance → bloat).
全面的依赖风险评估：许可证兼容性分析、维护健康度评分、CVE检测、臃肿识别以及传递依赖风险映射。会生成可落地的报告，按紧急度排序修复步骤（安全 → 许可证 → 维护 → 臃肿）。

Reference Files

参考文件

FileContentsLoad When
references/license-compatibility.md
License compatibility matrix, copyleft detection, commercial-safe licensesAlways
references/health-metrics.md
Maintenance health indicators, scoring criteria, abandonment detectionAlways
references/bloat-detection.md
Identifying unused deps, duplicate functionality, heavy transitive treesBloat analysis requested
references/cve-sources.md
CVE databases, advisory sources, vulnerability severity interpretationSecurity audit requested
文件内容加载时机
references/license-compatibility.md
许可证兼容性矩阵、copyleft检测、商业友好许可证列表始终加载
references/health-metrics.md
维护健康度指标、评分标准、废弃检测规则始终加载
references/bloat-detection.md
未使用依赖识别、重复功能识别、冗余传递依赖树识别请求臃肿分析时加载
references/cve-sources.md
CVE数据库、安全公告来源、漏洞严重等级解释请求安全审计时加载

Prerequisites

前置要求

  • Access to the project's dependency files (
    pyproject.toml
    , 
    requirements.txt
    , 
    package.json
    , 
    Cargo.toml
    , 
    go.mod
    )
  • Lock file (for exact versions and transitive dependencies)
  • Project license (to determine compatibility requirements)
  • 可访问项目的依赖文件（
    pyproject.toml
    、
    requirements.txt
    、
    package.json
    、
    Cargo.toml
    、
    go.mod
    ）
  • 锁文件（用于获取精确版本和传递依赖信息）
  • 项目许可证（用于确定兼容性要求）

Workflow

工作流

Phase 1: Parse Dependency Tree

阶段1：解析依赖树

  1. Direct dependencies — Packages explicitly declared in the project.
  2. Transitive dependencies — Dependencies of dependencies. Often 10-50x the direct count.
  3. Version constraints — Pinned (
    ==1.2.3
    ), ranged (
    >=1.0,<2.0
    ), or floating (
    *
    ).
  4. Development vs production — Separate dev/test dependencies from production.
Tools:
  • Python: 
    uv pip list
    , 
    pip-audit
    , 
    pipdeptree
  • Node.js: 
    npm list --all
    , 
    npm audit
  • Rust: 
    cargo tree
    , 
    cargo audit
  1. 直接依赖 — 项目中显式声明的包。
  2. 传递依赖 — 依赖的依赖，数量通常是直接依赖的10-50倍。
  3. 版本约束 — 固定版本（
    ==1.2.3
    ）、范围版本（
    >=1.0,<2.0
    ）或浮动版本（
    *
    ）。
  4. 开发依赖 vs 生产依赖 — 区分开发/测试依赖和生产依赖。
工具：
  • Python: 
    uv pip list
    , 
    pip-audit
    , 
    pipdeptree
  • Node.js: 
    npm list --all
    , 
    npm audit
  • Rust: 
    cargo tree
    , 
    cargo audit

Phase 2: Audit Licenses

阶段2：审计许可证

For each dependency:
  1. Identify the license — Check package metadata, LICENSE file, pyproject.toml.
  2. Classify compatibility — Against the project's own license:
    LicenseCommercial OKCopyleftRisk Level
    MIT, BSD, ISC, Apache 2.0YesNoLow
    LGPLWith careWeakMedium
    GPL-2.0, GPL-3.0No (unless GPL project)StrongHigh
    AGPLNo (unless AGPL project)Strong + networkCritical
    UnknownCannot determineUnknownCritical
  3. Flag issues — Copyleft licenses in proprietary projects, unknown licenses, license changes between versions.
针对每个依赖：
  1. 识别许可证 — 检查包元数据、LICENSE文件、pyproject.toml。
  2. 兼容性分类 — 与项目自身的许可证对比：
    许可证商业使用许可Copyleft类型风险等级
    MIT, BSD, ISC, Apache 2.0是否低
    LGPL谨慎使用弱中
    GPL-2.0, GPL-3.0否（除非项目本身是GPL协议）强高
    AGPL否（除非项目本身是AGPL协议）强+网络传播极高
    未知无法确定未知极高
  3. 标记问题 — 专有项目中的copyleft许可证、未知许可证、版本间许可证变更。

Phase 3: Assess Maintenance Health

阶段3：评估维护健康度

For each dependency, evaluate maintenance signals:
IndicatorHealthyWarningAbandoned
Last release< 6 months6-18 months> 18 months
Commits (90 days)10+1-90
Open issues response< 2 weeks2-8 weeks> 8 weeks or no response
Bus factor3+ maintainers21
CI statusPassingFlakyFailing or absent
针对每个依赖，评估维护信号：
指标健康警告已废弃
最近发版< 6个月6-18个月> 18个月
提交数（90天）10+1-90
公开问题响应速度< 2周2-8周> 8周或无响应
总线因子3+维护者21
CI状态通过不稳定失败或无CI

Phase 4: Check Security

阶段4：安全检查

  1. Known CVEs — Check against advisory databases:
    • Python: 
      pip-audit
      , PyPI advisory database
    • Node.js: 
      npm audit
      , GitHub Advisory Database
    • General: NVD (National Vulnerability Database)
  2. Severity classification — CVSS score interpretation:
    CVSS ScoreSeverityAction
    9.0-10.0CriticalUpgrade immediately
    7.0-8.9HighUpgrade within days
    4.0-6.9MediumUpgrade within weeks
    0.1-3.9LowUpgrade at convenience
  3. Fix availability — Is there a patched version? If not, what's the workaround?
  1. 已知CVE — 对照安全公告数据库检查：
    • Python: 
      pip-audit
      , PyPI安全公告数据库
    • Node.js: 
      npm audit
      , GitHub安全公告数据库
    • 通用: NVD（国家漏洞数据库）
  2. 严重等级分类 — CVSS评分解释：
    CVSS评分严重等级处理要求
    9.0-10.0极高立即升级
    7.0-8.9高数天内升级
    4.0-6.9中数周内升级
    0.1-3.9低方便时升级
  3. 修复可用性 — 是否有补丁版本？如果没有，有什么替代方案？

Phase 5: Detect Bloat

阶段5：检测臃肿

  1. Unused dependencies — Dependencies imported nowhere in the codebase.
  2. Duplicate functionality — Multiple packages doing the same thing (2 HTTP clients, 2 JSON parsers).
  3. Heavy transitive trees — Packages that pull in dozens of sub-dependencies for a simple feature.
  4. Size analysis — Large packages used for small functionality.
  1. 未使用依赖 — 代码库中没有任何地方导入的依赖。
  2. 重复功能 — 多个包实现相同功能（2个HTTP客户端、2个JSON解析器）。
  3. 冗余传递依赖树 — 为实现简单功能引入了数十个子依赖的包。
  4. 体积分析 — 仅用于小功能的大型包。

Phase 6: Report

阶段6：生成报告

Produce a prioritized report with action items.
输出带优先级行动项的报告。

Output Format

输出格式

undefined
undefined

Dependency Audit: {Project Name}

Dependency Audit: {Project Name}

Summary

Summary

MetricCount
Direct dependencies{N}
Transitive dependencies{N}
License issues{N}
Maintenance concerns{N}
Security vulnerabilities{N}
Bloat candidates{N}
MetricCount
Direct dependencies{N}
Transitive dependencies{N}
License issues{N}
Maintenance concerns{N}
Security vulnerabilities{N}
Bloat candidates{N}

License Compliance

License Compliance

PackageVersionLicenseCompatibleIssue
{pkg}{ver}MITYesNone
{pkg}{ver}GPL-3.0NoCopyleft in proprietary project
{pkg}{ver}UnknownUnknownLicense not identifiable
PackageVersionLicenseCompatibleIssue
{pkg}{ver}MITYesNone
{pkg}{ver}GPL-3.0NoCopyleft in proprietary project
{pkg}{ver}UnknownUnknownLicense not identifiable

Maintenance Health

Maintenance Health

PackageLast ReleaseCommits (90d)MaintainersStatus
{pkg}{date}{N}{N}{Healthy/Warning/Abandoned}
PackageLast ReleaseCommits (90d)MaintainersStatus
{pkg}{date}{N}{N}{Healthy/Warning/Abandoned}

Security Vulnerabilities

Security Vulnerabilities

PackageVersionCVESeverityFix AvailableFixed In
{pkg}{ver}{CVE-ID}{severity}{Yes/No}{version}
PackageVersionCVESeverityFix AvailableFixed In
{pkg}{ver}{CVE-ID}{severity}{Yes/No}{version}

Bloat Analysis

Bloat Analysis

PackageInstall SizeUsed ByRecommendation
{pkg}{size}{usage description}{Remove/Replace/Keep}
PackageInstall SizeUsed ByRecommendation
{pkg}{size}{usage description}{Remove/Replace/Keep}

Action Items

Action Items

Immediate (Security)

Immediate (Security)

  1. Upgrade {pkg} to {version} — fixes {CVE-ID} ({severity})
  1. Upgrade {pkg} to {version} — fixes {CVE-ID} ({severity})

Short-term (License)

Short-term (License)

  1. Review {pkg} GPL usage — may require license change or removal
  1. Review {pkg} GPL usage — may require license change or removal

Medium-term (Maintenance)

Medium-term (Maintenance)

  1. Find alternative to {pkg} — abandoned since {date}
  1. Find alternative to {pkg} — abandoned since {date}

Long-term (Bloat)

Long-term (Bloat)

  1. Remove {pkg} — unused in codebase
  2. Replace {pkg} with lighter alternative
  1. Remove {pkg} — unused in codebase
  2. Replace {pkg} with lighter alternative

Transitive Risk

Transitive Risk

  • {direct-dep} depends on {transitive-dep} which has {issue}
undefined
  • {direct-dep} depends on {transitive-dep} which has {issue}
undefined

Calibration Rules

校准规则

  1. Production dependencies first. Dev/test dependencies have lower risk since they don't ship to users. Audit production dependencies with higher scrutiny.
  2. Transitive risk is real. A direct dependency with MIT license may pull in a GPL transitive dependency. Always check the full tree.
  3. Abandoned is not broken. A mature, stable library that hasn't been updated in a year may be perfectly fine. Evaluate based on whether the library is "done" vs "neglected."
  4. Security is non-negotiable. Critical and High CVEs must be addressed immediately. Medium CVEs should be tracked. Low CVEs can wait for the next dependency update cycle.
  1. 生产依赖优先。 开发/测试依赖风险更低，因为不会发布给用户，需以更高标准审计生产依赖。
  2. 传递依赖风险真实存在。 使用MIT许可证的直接依赖可能引入GPL许可证的传递依赖，始终检查完整依赖树。
  3. 已废弃不等于不可用。 一个成熟稳定、一年未更新的库可能完全可用，需判断库是“已完成开发”还是“被 neglect”。
  4. 安全问题不可妥协。 极高和高等级CVE必须立即处理，中等级CVE需要跟踪，低等级CVE可以等到下一个依赖更新周期处理。

Error Handling

错误处理

ProblemResolution
No lock file availableAudit based on declared dependencies. Note that transitive analysis is incomplete without a lock file.
License metadata missingCheck the package's repository for LICENSE file. Note packages where license cannot be determined.
Package registry unavailableWork from cached metadata and local lockfile data.
Too many dependencies to audit manuallyPrioritize: production deps first, then direct deps, then transitive deps with known issues.
问题解决方案
无可用锁文件基于声明的依赖审计，注明无锁文件时传递依赖分析不完整。
缺少许可证元数据检查包的代码仓库中的LICENSE文件，标记无法确定许可证的包。
包注册表不可访问基于缓存的元数据和本地锁文件数据处理。
依赖数量过多无法手动审计按优先级处理：优先生产依赖，其次直接依赖，最后有已知问题的传递依赖。

When NOT to Audit

不需要审计的场景

Push back if:
  • The project is a prototype that won't ship — defer audit until production decision
  • The user wants dependency updates, not audit — different task (dependabot, renovate)
  • The project has no dependencies (pure standard library) — nothing to audit
遇到以下情况可以拒绝审计需求：
  • 项目是不会上线的原型 — 推迟到决定投产时再审计
  • 用户想要更新依赖，而不是审计 — 属于不同任务（dependabot、renovate）
  • 项目没有任何依赖（纯标准库实现） — 无内容可审计