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. 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

第二阶段：审计许可证

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

第三阶段：评估维护健康状况

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人以上2人1人
CI状态通过不稳定失败或未配置

Phase 4: Check Security

第四阶段：安全检查

  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 Advisory Database
    • 通用：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

第五阶段：检测冗余

  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

第六阶段：生成报告

Produce a prioritized report with action items.
生成包含行动项的优先级报告。

Output Format

输出格式

text
undefined
text
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. 已废弃不代表无法使用。一年未更新的成熟稳定库可能完全可用。评估库是“已完成开发”还是“被忽视”。
  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）
  • 项目无外部依赖（仅使用标准库） — 无可审计内容

Rationalizations

常见误区纠正

RationalizationReality
"It's a trusted package"Trust is not a security model — trusted packages get compromised (event-stream, ua-parser-js, colors.js)
"Only a minor version bump"Minor versions can introduce vulnerabilities, change behavior, or add transitive dependencies — semver is a promise, not a guarantee
"We don't use the vulnerable function"Transitive dependencies might — and attack surface includes any code loaded into the process
"The CVE is low severity"Low severity in isolation can be critical in your context — a "low" SSRF in an internal service with cloud metadata access is critical
"We'll update when there's a known exploit"Known exploits mean you're already behind — patch within SLA, not after breach
"Too many dependencies to audit"That's the problem, not an excuse — high dependency count IS a risk finding
错误观点实际情况
"这是可信的包"信任不是安全模型 — 可信包也会被入侵（如event-stream、ua-parser-js、colors.js）
"只是小版本更新"小版本可能引入漏洞、改变行为或添加间接依赖 — semver是承诺而非保证
"我们不使用有漏洞的功能"间接依赖可能会使用 — 攻击面包括加载到进程中的任何代码
"这个CVE严重程度低"孤立的低严重程度在你的场景中可能很严重 — 内部服务中“低风险”的SSRF如果能访问云元数据就是严重问题
"有已知漏洞利用时再更新"已知漏洞利用意味着你已经落后 — 应在服务级别协议内修补，而非在入侵后
"依赖太多无法审计"这本身就是问题，而非借口 — 高依赖数量本身就是风险发现

Red Flags

危险信号

  • Auditing only direct dependencies while ignoring transitive dependency tree
  • Dismissing CVEs without checking if the vulnerable code path is reachable
  • No license compatibility check — GPL in a proprietary codebase is a legal finding
  • Accepting "no known vulnerabilities" from a single scanner without cross-referencing
  • Ignoring dependency age — unmaintained packages with no updates in 2+ years are a risk
  • Skipping lockfile analysis (pinned vs. floating versions)
  • 仅审计直接依赖而忽略间接依赖树
  • 不检查漏洞代码路径是否可达就驳回CVE警告
  • 不进行许可证兼容性检查 — 专有代码库中使用GPL是法律问题
  • 仅依赖单个扫描器的“无已知漏洞”结果而不交叉验证
  • 忽略依赖年限 — 2年以上未更新的无人维护包是风险
  • 跳过锁定文件分析（固定版本 vs 浮动版本）

Verification

验证清单

  • Both direct and transitive dependencies scanned
  • Vulnerability scanner output captured: 
    npm audit
    / 
    pip-audit
    / 
    cargo audit
  • Each CVE finding includes: severity, affected version range, upgrade path, reachability assessment
  • License compatibility verified against project license
  • Dependency age and maintenance status checked for top-level deps
  • Lockfile present and version pinning verified — no floating ranges in production
  • 已扫描直接和间接依赖
  • 已捕获漏洞扫描器输出：
    npm audit
    / 
    pip-audit
    / 
    cargo audit
  • 每个CVE发现包含：严重程度、受影响版本范围、升级路径、可达性评估
  • 已针对项目许可证验证许可证兼容性
  • 已检查顶级依赖的年限和维护状态
  • 存在锁定文件并验证版本固定 — 生产环境无浮动版本范围