analyze-dependencies

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Analyze Dependencies

分析依赖项

Overview

概述

Audit the project's dependency tree across five risk dimensions: freshness, vulnerabilities, bundle impact, license compliance, and maintenance status. Produce a risk-scored report with actionable recommendations for each dependency.

从五个风险维度审计项目的依赖树：新鲜度、漏洞、包体积影响、许可证合规性和维护状态。生成带有可操作建议的风险评分报告，针对每个依赖项给出具体指导。

Workflow

工作流程

Read project context — Check
```
.chalk/docs/engineering/
```
for:
- Architecture docs (to understand which dependencies are critical path)
- Previous dependency audits
- Any documented dependency policies or license requirements

Locate dependency manifests — Scan the project for:

package.json

package-lock.json

yarn.lock

pnpm-lock.yaml

(Node.js)

pyproject.toml

requirements.txt

Pipfile

poetry.lock

(Python)

```
pubspec.yaml
```
/
```
pubspec.lock
```
(Dart/Flutter)
```
Cargo.toml
```
/
```
Cargo.lock
```
(Rust)
```
go.mod
```
/
```
go.sum
```
(Go)
```
Gemfile
```
/
```
Gemfile.lock
```
(Ruby)
```
pom.xml
```
/
```
build.gradle
```
(Java/Kotlin)
If
```
$ARGUMENTS
```
specifies a file, focus on that manifest

Inventory dependencies — For each manifest, list:
- Direct dependencies (production)
- Direct dev dependencies
- Note the declared version constraints (exact, range, caret, tilde)
Assess freshness — For each dependency:
- Current installed version vs. latest available version
- Run the appropriate command:
```
npm outdated
```
  ,
```
pip list --outdated
```
  ,
```
pub outdated
```
  , etc.
- Classify the gap:
  - Current: on latest or within one minor version
  - Stale: one or more minor versions behind
  - Outdated: one or more major versions behind
  - Abandoned: no release in 2+ years
Check for vulnerabilities — Run the appropriate audit command:
- ```
npm audit
```
  /
```
yarn audit
```
  /
```
pnpm audit
```
- ```
pip audit
```
  or
```
safety check
```
- ```
cargo audit
```
- ```
bundle audit
```
- Record: CVE ID, severity (critical/high/medium/low), affected version range, fix available (yes/no)
- Check transitive dependencies, not just direct ones
Evaluate bundle impact — Where applicable:
- For Node.js: check package size, number of transitive dependencies, tree-shakeability
- For frontend projects: note if a large library is used for a small feature (e.g., lodash for one function)
- Flag dependencies that pull in disproportionately large sub-dependency trees
Check license compliance — For each dependency:
- Identify the license (MIT, Apache-2.0, GPL, LGPL, AGPL, BSD, ISC, etc.)
- Flag copyleft licenses (GPL, AGPL, LGPL) that may have viral implications
- Flag unlicensed or custom-licensed packages
- Flag license changes between the installed version and latest version
- Note: MIT, Apache-2.0, BSD, ISC are generally permissive and low risk
Assess maintenance status — For each dependency, check:
- Last publish date
- Open issues and PRs (especially security-related)
- Number of maintainers (bus factor)
- Whether the project is archived or deprecated
- Classify: Active (regular releases, responsive maintainers), Maintained (occasional releases, issues addressed), Minimal (rare updates, issues pile up), Unmaintained (no activity in 12+ months)
Score each dependency — Assign a risk score based on all dimensions:
- Low: Current, no vulnerabilities, permissive license, actively maintained
- Medium: Stale or one minor concern (e.g., slightly outdated, minimal maintenance)
- High: Outdated or multiple concerns (known vulnerability with fix available, copyleft license, large bundle impact)
- Critical: Known exploitable vulnerability, abandoned with no alternative, or license violation
Generate recommendations — For each dependency with medium or higher risk:
- Update: Newer version fixes the issue. Note any breaking changes.
- Replace: Better-maintained alternative exists. Name the alternative.
- Remove: Dependency is unused or its functionality can be inlined.
- Monitor: Risk is acceptable for now but should be tracked.
- Immediate Action: Critical vulnerability or license violation requiring urgent attention.
Determine the next file number — List files in
```
.chalk/docs/engineering/
```
matching
```
*_dependency_audit*
```
. Find the highest number and increment by 1.

Write the report — Save to

.chalk/docs/engineering/<n>_dependency_audit.md

Confirm — Summarize: total dependencies analyzed, risk distribution, critical items requiring immediate attention.

读取项目上下文 — 检查
```
.chalk/docs/engineering/
```
目录下的内容：
- 架构文档（用于了解哪些依赖项属于关键路径）
- 过往的依赖审计报告
- 任何已记录的依赖项政策或许可证要求
定位依赖清单文件 — 扫描项目中的以下文件：
- ```
package.json
```
  /
```
package-lock.json
```
  /
```
yarn.lock
```
  /
```
pnpm-lock.yaml
```
  （Node.js）
- ```
pyproject.toml
```
  /
```
requirements.txt
```
  /
```
Pipfile
```
  /
```
poetry.lock
```
  （Python）
- ```
pubspec.yaml
```
  /
```
pubspec.lock
```
  （Dart/Flutter）
- ```
Cargo.toml
```
  /
```
Cargo.lock
```
  （Rust）
- ```
go.mod
```
  /
```
go.sum
```
  （Go）
- ```
Gemfile
```
  /
```
Gemfile.lock
```
  （Ruby）
- ```
pom.xml
```
  /
```
build.gradle
```
  （Java/Kotlin）
- 如果
```
$ARGUMENTS
```
  指定了文件，则重点关注该清单
统计依赖项清单 — 针对每个清单文件，列出：
- 直接生产依赖项
- 直接开发依赖项
- 记录声明的版本约束（精确版本、版本范围、脱字符^、波浪号~）
评估新鲜度 — 针对每个依赖项：
- 对比当前安装版本与最新可用版本
- 运行对应的命令：
```
npm outdated
```
  、
```
pip list --outdated
```
  、
```
pub outdated
```
  等
- 分类版本差距：
  - 当前版本：处于最新版本或落后不超过一个小版本
  - 陈旧版本：落后一个或多个小版本
  - 过时版本：落后一个或多个大版本
  - 已废弃：超过2年未发布新版本
检查漏洞 — 运行对应的审计命令：
- ```
npm audit
```
  /
```
yarn audit
```
  /
```
pnpm audit
```
- ```
pip audit
```
  或
```
safety check
```
- ```
cargo audit
```
- ```
bundle audit
```
- 记录：CVE编号、严重程度（critical/high/medium/low）、受影响版本范围、是否有可用修复（是/否）
- 检查传递依赖项，而不仅仅是直接依赖项
评估包体积影响 — 适用于以下场景：
- 对于Node.js：检查包大小、传递依赖项数量、是否支持Tree Shaking
- 对于前端项目：注意是否为了一个小功能引入了大型库（例如，用lodash实现单一函数）
- 标记那些引入不成比例的庞大子依赖树的依赖项
检查许可证合规性 — 针对每个依赖项：
- 识别许可证类型（MIT、Apache-2.0、GPL、LGPL、AGPL、BSD、ISC等）
- 标记可能具有“病毒式”影响的左版许可证（GPL、AGPL、LGPL）
- 标记无许可证或自定义许可证的包
- 标记安装版本与最新版本之间的许可证变更
- 注意：MIT、Apache-2.0、BSD、ISC通常属于宽松许可证，风险较低
评估维护状态 — 针对每个依赖项，检查：
- 最后发布日期
- 未解决的问题和PR（尤其是安全相关的）
- 维护者数量（人员风险）
- 项目是否已归档或弃用
- 分类：活跃（定期发布，维护者响应及时）、维护中（偶尔发布，问题得到处理）、最低维护（更新稀少，问题堆积）、无人维护（12个月以上无活动）
为每个依赖项评分 — 根据所有维度分配风险评分：
- 低风险：版本当前无漏洞，使用宽松许可证，维护活跃
- 中风险：版本陈旧或存在一个次要问题（例如，轻微过时、最低维护状态）
- 高风险：版本过时或存在多个问题（已知漏洞且有可用修复、左版许可证、包体积影响大）
- 关键风险：存在已知可利用的漏洞、已废弃且无替代方案、或违反许可证要求
生成建议 — 针对每个中风险及以上的依赖项：
- 更新：新版本可解决问题，注意是否存在破坏性变更
- 替换：存在维护更好的替代方案，列出替代包名称
- 移除：依赖项未被使用，或其功能可内联实现
- 监控：当前风险可接受，但需持续跟踪
- 立即处理：存在关键漏洞或许可证违规问题，需紧急处理
确定下一个文件编号 — 列出
```
.chalk/docs/engineering/
```
目录下匹配
```
*_dependency_audit*
```
的文件，找到编号最大的文件并将编号加1

撰写报告 — 保存至

.chalk/docs/engineering/<n>_dependency_audit.md

确认总结 — 汇总：分析的依赖项总数、风险分布、需要立即处理的关键项

Filename Convention

文件名规范

<number>_dependency_audit.md

Examples:

```
5_dependency_audit.md
```
```
9_dependency_audit.md
```

<number>_dependency_audit.md

示例：

```
5_dependency_audit.md
```
```
9_dependency_audit.md
```

Dependency Audit Format

依赖审计报告格式

markdown

undefined

markdown

undefined

Dependency Audit

依赖审计报告

Last updated: <YYYY-MM-DD> Package manager: <npm / pip / pub / cargo / etc.> Manifest: <path to manifest file>

最后更新时间：<YYYY-MM-DD> 包管理器：<npm / pip / pub / cargo / etc.> 清单文件：<清单文件路径>

Summary

摘要

Risk Level	Count	Action Required
Critical	<n>	Immediate action
High	<n>	Plan remediation this sprint
Medium	<n>	Schedule for next maintenance window
Low	<n>	No action needed
Total	<n>

风险等级	数量	所需操作
关键	<n>	立即处理
高	<n>	本迭代计划修复
中	<n>	安排至下一个维护窗口处理
低	<n>	无需操作
总计	<n>

Vulnerability Summary

漏洞摘要

CVE	Severity	Package	Installed	Fixed In	Transitive?
CVE-XXXX-XXXXX	Critical	<name>	<version>	<version>	No

CVE编号	严重程度	包名称	安装版本	修复版本	是否为传递依赖
CVE-XXXX-XXXXX	关键	<名称>	<版本>	<版本>	否

Critical & High Risk Dependencies

关键与高风险依赖项

<package-name> — CRITICAL

<包名称> — 关键风险

Dimension	Status	Detail
Freshness	Outdated	Installed: 2.1.0, Latest: 4.0.0
Vulnerabilities	CVE-XXXX-XXXXX (High)	RCE via crafted input
Bundle Impact	450KB	Pulls in 23 transitive deps
License	MIT	No issues
Maintenance	Unmaintained	Last release: 2022-01-15

Risk: <Why this is critical> Recommendation: Replace with

<alternative>

. Migration guide: <link or steps>.

维度	状态	详情
新鲜度	过时	安装版本：2.1.0，最新版本：4.0.0
漏洞	CVE-XXXX-XXXXX（高风险）	通过特制输入实现远程代码执行
包体积影响	450KB	引入23个传递依赖项
许可证	MIT	无问题
维护状态	无人维护	最后发布时间：2022-01-15

风险说明：<为何此依赖项属于关键风险> 建议：替换为

<替代包>

。迁移指南：<链接或步骤>。

<package-name> — HIGH

<包名称> — 高风险

Dimension	Status	Detail
...	...	...

Risk: <explanation> Recommendation: <action>

维度	状态	详情
...	...	...

风险说明：<说明> 建议：<操作>

Medium Risk Dependencies

中风险依赖项

Package	Version	Risk Factors	Recommendation
<name>	<ver>	Stale (3 minor behind), minimal maintenance	Update to <ver>

包名称	版本	风险因素	建议
<名称>	<版本>	陈旧（落后3个小版本）、最低维护状态	更新至<版本>

Low Risk Dependencies

低风险依赖项

Package	Version	License	Last Updated
<name>	<ver>	MIT	2024-11-01

包名称	版本	许可证	最后更新时间
<名称>	<版本>	MIT	2024-11-01

License Compliance

许可证合规性

License	Count	Packages	Risk
MIT	<n>	<list>	None
Apache-2.0	<n>	<list>	None
GPL-3.0	<n>	<list>	Copyleft — review required
Unlicensed	<n>	<list>	Unknown — investigate

许可证	数量	包列表	风险
MIT	<n>	<列表>	无
Apache-2.0	<n>	<列表>	无
GPL-3.0	<n>	<列表>	左版许可证 — 需要审核
无许可证	<n>	<列表>	未知 — 需要调查

Recommendations Summary

建议摘要

Immediate Action

立即处理

<package>: <action and reason>

<包名称>：<操作及原因>

This Sprint

本迭代处理

<package>: <action and reason>

<包名称>：<操作及原因>

Next Maintenance Window

下一个维护窗口处理

<package>: <action and reason>

<包名称>：<操作及原因>

Monitor

监控

<package>: <what to watch for>

undefined

<包名称>：<需要关注的内容>

undefined

Risk Scoring Matrix

风险评分矩阵

Dimension	Low	Medium	High	Critical
Freshness	Current or 1 minor behind	2+ minor behind	1+ major behind	Abandoned (2+ years)
Vulnerabilities	None known	Low severity	High severity, fix available	Critical severity or no fix
Bundle Impact	< 50KB, few transitive	50-200KB	200KB-1MB	> 1MB or 50+ transitive deps
License	MIT, BSD, ISC, Apache-2.0	LGPL	GPL	AGPL or unlicensed
Maintenance	Active (monthly releases)	Maintained (quarterly)	Minimal (yearly)	Unmaintained or archived

The overall risk score for a dependency is the highest score across all dimensions.

Note: These risk levels assume distributed, proprietary software. Adjust based on your project's distribution model — for internal-only tools, even copyleft licenses may be low risk. For dynamically linked libraries, LGPL is often low risk.

维度	低风险	中风险	高风险	关键风险
新鲜度	当前版本或落后1个小版本	落后2个及以上小版本	落后1个及以上大版本	已废弃（2年以上）
漏洞	无已知漏洞	低严重程度	高严重程度，有可用修复	关键严重程度或无修复方案
包体积影响	<50KB，传递依赖少	50-200KB	200KB-1MB	>1MB或50个以上传递依赖项
许可证	MIT、BSD、ISC、Apache-2.0	LGPL	GPL	AGPL或无许可证
维护状态	活跃（每月发布）	维护中（每季度发布）	最低维护（每年发布）	无人维护或已归档

依赖项的整体风险评分为所有维度中的最高评分。

注意：这些风险等级假设针对分布式、专有软件。请根据项目的分发模式进行调整 — 对于仅内部使用的工具，即使是左版许可证风险也可能较低。对于动态链接库，LGPL通常风险较低。

Anti-patterns

反模式

Only checking for vulnerabilities, ignoring staleness — A dependency with no CVEs but abandoned for 3 years is a ticking time bomb. When a vulnerability is discovered, there will be no one to patch it. Staleness is a leading indicator of future risk.
Not checking transitive dependencies — Your project may have 20 direct dependencies but 200 transitive ones. A critical vulnerability in a transitive dependency is just as exploitable. Always audit the full tree.
Ignoring license issues — Using a GPL library in a proprietary product can create legal exposure. License compliance is not optional, and "we will deal with it later" becomes expensive when a customer or investor asks.
Only auditing production dependencies — Dev dependencies run in your CI/CD pipeline and developer machines. A compromised dev dependency can inject malicious code into your build artifacts. Audit everything.
Treating the audit as a one-time activity — Dependencies change constantly. New vulnerabilities are disclosed daily. Schedule regular audits (at least monthly) and integrate
```
npm audit
```
/
```
pip audit
```
into CI.
Recommending updates without checking breaking changes — "Just update to latest" is not actionable advice. Check the changelog for breaking changes, especially across major versions, and note migration effort in the recommendation.
Ignoring bundle impact in frontend projects — A 2MB dependency for a single utility function destroys load time. Always consider whether the functionality can be achieved with a smaller package or inlined code.

仅检查漏洞，忽略版本陈旧问题 — 一个没有CVE记录但已废弃3年的依赖项是定时炸弹。当漏洞被发现时，将无人提供补丁。陈旧性是未来风险的主要预警信号。
不检查传递依赖项 — 你的项目可能只有20个直接依赖项，但有200个传递依赖项。传递依赖项中的关键漏洞同样具有可利用性。始终审计完整的依赖树。
忽略许可证问题 — 在专有产品中使用GPL库可能会带来法律风险。许可证合规不是可选项，“以后再处理”在客户或投资者询问时会变得代价高昂。
仅审计生产依赖项 — 开发依赖项会在CI/CD流水线和开发人员机器上运行。被攻陷的开发依赖项可能会向构建产物中注入恶意代码。审计所有依赖项。
将审计视为一次性活动 — 依赖项会不断变化，新漏洞每天都在披露。定期安排审计（至少每月一次），并将
```
npm audit
```
/
```
pip audit
```
集成到CI流程中。
不检查破坏性变更就建议更新 — “直接更新到最新版本”不是可执行的建议。查看变更日志中的破坏性变更，尤其是跨大版本的变更，并在建议中注明迁移工作量。
忽略前端项目的包体积影响 — 一个2MB的依赖项仅用于实现单一工具函数会严重影响加载时间。始终考虑是否可以用更小的包或内联代码实现相同功能。