dependency-risk-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Dependency Risk Audit

依赖项风险审计

Run a repeatable dependency-risk audit for Python projects and return a prioritized remediation plan.

为Python项目执行可重复的依赖项风险审计，并返回优先级排序的修复计划。

Workflow

工作流程

Step 1: Identify dependency source of truth

步骤1：确定依赖项的可信来源

Detect package manager and files in this order:

```
poetry.lock
```
+
```
pyproject.toml
```
```
uv.lock
```
+
```
pyproject.toml
```
```
Pipfile.lock
```
+
```
Pipfile
```
```
requirements*.txt
```
and optional
```
constraints*.txt
```

Prefer lockfiles for resolved versions.
Record Python runtime constraint from:
- ```
pyproject.toml
```
  (
```
requires-python
```
  )
- ```
.python-version
```
- CI config (if present)

按以下顺序检测包管理器和文件：

```
poetry.lock
```
+
```
pyproject.toml
```
```
uv.lock
```
+
```
pyproject.toml
```
```
Pipfile.lock
```
+
```
Pipfile
```
```
requirements*.txt
```
及可选的
```
constraints*.txt
```

优先使用锁定文件中的已解析版本。
从以下位置记录Python运行时约束：
- ```
pyproject.toml
```
  （
```
requires-python
```
  字段）
- ```
.python-version
```
  文件
- CI配置（如果存在）

Step 2: Build dependency inventory

步骤2：构建依赖项清单

Create an inventory with:

package name
installed/resolved version
dependency type (
```
direct
```
or
```
transitive
```
)
pin style (
```
exact
```
,
```
range
```
,
```
unbounded
```
)
marker constraints (Python version, platform markers)

If direct/transitive split is unavailable from project files, state that limitation explicitly.

创建包含以下信息的清单：

包名称
已安装/已解析版本
依赖类型（
```
direct
```
（直接依赖）或
```
transitive
```
（间接依赖））
锁定方式（
```
exact
```
（精确锁定）、
```
range
```
（范围锁定）、
```
unbounded
```
（无限制））
标记约束（Python版本、平台标记）

如果无法从项目文件中区分直接/间接依赖，请明确说明这一限制。

Step 3: Run security advisory checks

步骤3：执行安全漏洞检查

Prefer

pip-audit

. If unavailable, fall back to lockfile/static analysis and mark advisories as partially evaluated.

Common commands:

bash

undefined

优先使用

pip-audit

工具。如果该工具不可用，则回退到锁定文件/静态分析，并将漏洞标记为部分评估。

常用命令：

bash

undefined

requirements.txt projects

requirements.txt 项目

pip-audit -r requirements.txt -f json

active environment

活跃环境

pip-audit -f json


For non-requirements workflows, export to requirements format first when possible, then audit that export.

For each finding, capture:

- advisory ID (for example `PYSEC-*`, `CVE-*`, `GHSA-*`)
- package + affected version
- fixed version range
- severity (if available)
- exploit or impact notes (if available)

pip-audit -f json


对于非requirements工作流，尽可能先导出为requirements格式，再对导出文件进行审计。

针对每个检测结果，记录：

- 漏洞ID（例如`PYSEC-*`、`CVE-*`、`GHSA-*`）
- 包名称 + 受影响版本
- 修复版本范围
- 严重程度（如果可用）
- 利用方式或影响说明（如果可用）

Step 4: Detect stale pins

步骤4：检测过期版本锁定

Classify each direct dependency:

```
current
```
: no newer release in same major
```
minor/patch stale
```
: behind within same major
```
major stale
```
: newer major available
```
unknown
```
: latest data unavailable

Flag stale pins as higher risk when:

package is internet-facing, auth-related, crypto-related, or framework/core runtime
current version is multiple majors behind
package has a recent advisory history

对每个直接依赖进行分类：

```
current
```
：同大版本下无更新版本
```
minor/patch stale
```
：同大版本下存在未更新的小版本/补丁版本
```
major stale
```
：存在更新的大版本
```
unknown
```
：无法获取最新版本数据

当出现以下情况时，将过期版本锁定标记为高风险：

包面向互联网、与认证相关、加密相关，或为框架/核心运行时
当前版本落后多个大版本
包有近期漏洞历史

Step 5: Evaluate upgrade-path safety

步骤5：评估升级路径的安全性

For each dependency requiring change, assess upgrade risk:

```
low
```
: patch/minor upgrade, no known breaking changes
```
medium
```
: minor upgrade with behavior/config changes
```
high
```
: major upgrade, Python-version jump, or resolver conflicts likely

Check these risk signals:

major-version jump required to reach fixed secure version
declared Python requirement of target version conflicts with project runtime
conflicting upper bounds across dependencies
framework-coupled libraries that typically require code migrations

When possible, propose a stepwise path:

patch/minor upgrades first
isolated major upgrades next
framework/runtime upgrades last

对每个需要变更的依赖项，评估升级风险：

```
low
```
（低风险）：补丁/小版本升级，无已知破坏性变更
```
medium
```
（中风险）：小版本升级，存在行为/配置变更
```
high
```
（高风险）：大版本升级、Python版本跳跃，或可能出现解析器冲突

检查以下风险信号：

需要升级到新的大版本才能修复安全漏洞
目标版本声明的Python要求与项目运行时冲突
依赖项之间存在冲突的版本上限
与框架耦合的库通常需要代码迁移

尽可能提出分步升级路径：

优先进行补丁/小版本升级
接下来进行独立的大版本升级
最后进行框架/运行时升级

Step 6: Produce the report

步骤6：生成报告

Return a markdown report using this structure:

markdown

undefined

使用以下结构返回Markdown报告：

markdown

undefined

Dependency Risk Audit

依赖项风险审计

Audit root:

<path>

Dependency source:

<lockfile or manifest>

Python runtime target:

<version/constraint>

审计根目录:

<路径>

依赖来源:

<锁定文件或清单文件>

Python运行时目标:

<版本/约束>

Executive Summary

执行摘要

Overall risk: [LOW|MEDIUM|HIGH|CRITICAL]
Known advisories: X (Critical Y, High Z, ...)
Stale direct dependencies: X (Major-stale Y)
Unsafe upgrade paths: X

整体风险: [LOW|MEDIUM|HIGH|CRITICAL]
已知漏洞: X个（严重Y个，高危Z个...）
过期直接依赖: X个（大版本过期Y个）
不安全升级路径: X个

Security Advisories

安全漏洞

Package	Version	Advisory	Severity	Fixed In	Notes

包名称	当前版本	漏洞ID	严重程度	修复版本	说明

Stale Pins

过期版本锁定

Package	Current	Latest	Drift Type	Risk Notes

包名称	当前版本	最新版本	版本差异类型	风险说明

Upgrade Path Risks

升级路径风险

Package	Current -> Target	Risk	Why Risky	Recommended Path

包名称	当前版本 -> 目标版本	风险等级	风险原因	推荐升级路径

Prioritized Remediation Plan

优先级排序的修复计划

Not Evaluated

未评估项

Item + reason

undefined

项名称 + 原因

undefined

Scoring Guidance (optional)

评分指南（可选）

If the user asks for a numeric score, start at

and deduct:

Critical advisory:
```
-15
```
High advisory:
```
-10
```
Medium advisory:
```
-6
```
Low advisory:
```
-3
```
Major-stale direct dependency:
```
-4
```
High-risk upgrade path:
```
-5
```

Floor at

. Cap repeated deductions for the same package/advisory pair.

如果用户要求数值评分，以

分为起始分，按以下规则扣分：

严重漏洞:
```
-15
```
分
高危漏洞:
```
-10
```
分
中危漏洞:
```
-6
```
分
低危漏洞:
```
-3
```
分
大版本过期的直接依赖:
```
-4
```
分
高风险升级路径:
```
-5
```
分

最低分为

。同一包/漏洞组合的重复扣分不叠加。

Remediation Loop

修复循环

If the user asks for fixes:

Address critical/high advisories first, prioritizing low-risk upgrades.
Re-run audit steps 2-6.
Report risk delta, unresolved blockers, and required code changes/tests.

如果用户要求修复建议：

优先处理严重/高危漏洞，优先选择低风险升级路径。
重新执行审计步骤2-6。
报告风险变化、未解决的阻塞问题以及所需的代码变更/测试。