dependency-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Dependency Audit — Framework, Package, and Toolchain Security

依赖项审计 — 框架、包与工具链安全

Audit project dependencies, frameworks, language runtimes, and dev tools for known vulnerabilities (CVEs), security anti-patterns, and supply chain risks.

审计项目依赖项、框架、语言运行时及开发工具中的已知漏洞（CVE）、安全反模式和供应链风险。

Methodology

方法论

Step 1: Inventory the Stack

步骤1：梳理技术栈清单

Identify everything in use — not just direct dependencies but the full chain:

Package manifests — read and catalog:

Node/JS:    package.json, package-lock.json, yarn.lock, pnpm-lock.yaml
Python:     requirements.txt, Pipfile.lock, pyproject.toml, poetry.lock
Ruby:       Gemfile, Gemfile.lock
Go:         go.mod, go.sum
Rust:       Cargo.toml, Cargo.lock
Java:       pom.xml, build.gradle
PHP:        composer.json, composer.lock
.NET:       *.csproj, packages.config

Framework and runtime versions:

Check framework version (Next.js, Django, Rails, Spring, Laravel, Express, etc.)
Check language/runtime version (Node.js, Python, Ruby, Go, Java, PHP, .NET)
Check infrastructure tools (Docker base images, Terraform providers, Kubernetes versions)

Dev tools and CI/CD:

Check CI/CD pipeline configs (.github/workflows, .gitlab-ci.yml, Jenkinsfile)
Check pre-commit hooks, linters, formatters
Check container base images and their update status
Check IaC tool versions (Terraform, Pulumi, CDK)

Edge cases in package manifests:

```
optionalDependencies
```
— installed but not audited by default
```
peerDependencies
```
— version range may not match what's installed
```
overrides
```
/ yarn
```
resolutions
```
/ pnpm
```
overrides
```
— check if used to silence advisories rather than fix them
Monorepos: read every
```
packages/*/package.json
```
and
```
apps/*/package.json
```
, not just the root
```
engines
```
field — older-than-LTS Node makes other audits moot

识别所有正在使用的组件 —— 不仅是直接依赖项，还包括完整依赖链：

包清单 —— 读取并分类：

Node/JS:    package.json, package-lock.json, yarn.lock, pnpm-lock.yaml
Python:     requirements.txt, Pipfile.lock, pyproject.toml, poetry.lock
Ruby:       Gemfile, Gemfile.lock
Go:         go.mod, go.sum
Rust:       Cargo.toml, Cargo.lock
Java:       pom.xml, build.gradle
PHP:        composer.json, composer.lock
.NET:       *.csproj, packages.config

框架与运行时版本：

检查框架版本（Next.js、Django、Rails、Spring、Laravel、Express等）
检查语言/运行时版本（Node.js、Python、Ruby、Go、Java、PHP、.NET）
检查基础设施工具（Docker基础镜像、Terraform提供者、Kubernetes版本）

开发工具与CI/CD：

检查CI/CD流水线配置文件（.github/workflows、.gitlab-ci.yml、Jenkinsfile）
检查预提交钩子、代码检查工具、格式化工具
检查容器基础镜像及其更新状态
检查IaC工具版本（Terraform、Pulumi、CDK）

包清单中的边缘情况：

```
optionalDependencies
```
—— 已安装但默认不被审计
```
peerDependencies
```
—— 版本范围可能与已安装版本不匹配
```
overrides
```
/ yarn
```
resolutions
```
/ pnpm
```
overrides
```
—— 检查是否用于“掩盖”安全公告而非修复问题
单仓多包项目：读取所有
```
packages/*/package.json
```
和
```
apps/*/package.json
```
，而非仅根目录文件
```
engines
```
字段 —— 使用早于LTS版本的Node.js会导致其他审计失去意义

Step 2: Run Automated Audit Tools

步骤2：运行自动化审计工具

Run the appropriate audit command for the project:

bash

undefined

针对项目运行合适的审计命令：

bash

undefined

Node.js

npm audit --json # full structured output npm audit --omit=dev --json # production-only: filters dev/build-time vulns

npm audit --json # 完整结构化输出 npm audit --omit=dev --json # 仅生产环境：过滤开发/构建阶段漏洞

Compare the two — vulns only in dev/build tooling do not ship to users

对比两者结果 —— 仅存在于开发/构建工具中的漏洞不会随产品发布，

and should be triaged as lower priority. Don't bury this in the report.

应列为低优先级处理。不要在报告中忽略这一点。

Python

pip audit # If pip-audit installed safety check # If safety installed

pip audit # 需安装pip-audit safety check # 需安装safety

Ruby

bundle audit

Go

govulncheck ./...

Rust

cargo audit

PHP

composer audit

.NET

dotnet list package --vulnerable

Docker

docker scout cves <image> trivy image <image>

General (if Trivy is available)

通用（若Trivy可用）

trivy fs .


**Applying fixes — read before you `--force`:**

```bash
npm audit fix                   # safe: upgrades within stated ranges
npm audit fix --dry-run --force # ALWAYS dry-run first
npm audit fix --force           # only after reviewing the dry-run

npm audit fix --force

can resolve an advisory by DOWNGRADING a package to an older version that doesn't trigger the audit signature. This is almost always wrong (e.g. downgrading

next@16

next@9

to "fix" a transitive postcss CVE). Inspect dry-run output for "Will install X@Y, which is a breaking change" — that's the tool trying to downgrade.

When
npm audit fix
cannot resolve an advisory (transitive dep pinned by an upstream package):

Determine reachability — is the vulnerable code path actually invoked in your usage?
```
npm ls <package>
```
+ reading the parent's source can rule it out as unreachable.
Consider a
package.json

overrides
pin to a patched version (test thoroughly — overrides can break the parent).
Consider swapping the parent provider entirely.
If none apply: document explicitly, track upstream, and note in the audit report rather than silently dropping the finding.

trivy fs .


**应用修复 —— 执行`--force`前请仔细阅读：**

```bash
npm audit fix                   # 安全操作：在声明的版本范围内升级
npm audit fix --dry-run --force # 务必先执行试运行
npm audit fix --force           # 仅在审查试运行结果后执行

npm audit fix --force

可能通过降级包版本来解决安全公告问题，而该旧版本不会触发审计标识。这几乎总是错误的（例如，将

next@16

降级为

next@9

以“修复”传递依赖postcss的CVE）。请检查试运行输出中的“Will install X@Y, which is a breaking change” —— 这表示工具正尝试降级。

当
npm audit fix
无法解决安全公告问题时（上游包固定了传递依赖版本）：

判断可达性 —— 易受攻击的代码路径在你的实际使用中是否真的被调用？通过
```
npm ls <package>
```
+ 查看父包源码可排除不可达情况。
考虑在
package.json
中使用
overrides
固定到已修复版本（需充分测试 —— overrides可能导致父包崩溃）。
考虑完全替换父包提供者。
若以上均不适用： 明确记录问题，跟踪上游进展，并在审计报告中注明，而非默默忽略该发现。

Step 3: Research Framework-Specific Known Issues

步骤3：研究框架特定的已知问题

Beyond CVEs in packages, check for known vulnerability patterns specific to the framework in use. Search for recent advisories and common misconfiguration issues.

For every direct dependency, cross-reference the installed version against:

https://github.com/advisories?ecosystem=npm&query=<package>

https://github.com/<org>/<repo>/security/advisories

The framework-specific patterns below cover evergreen anti-patterns (mass assignment, debug-in-prod, etc.). Recent CVEs need a fresh check because hardcoded advisory lists rot fast and LLM training data is often 6+ months behind the latest.

Next.js / React:

Server Actions exposing internal endpoints (pre-14.1.1 middleware bypass CVE-2025-29927)
```
dangerouslySetInnerHTML
```
without sanitization
SSRF through image optimization (
```
next/image
```
with unrestricted domains)
Exposed
```
.env
```
files in public directory or client bundle (
```
NEXT_PUBLIC_
```
prefix leaking secrets)
Middleware auth bypass patterns — check middleware.ts matches all protected routes
Server Component / Client Component boundary leaking server-only data:
- Any module reading
```
process.env.SECRET
```
  or instantiating a DB client should start with
```
import "server-only";
```
  — fails the build if imported from a Client Component
- Grep for: files in
```
lib/
```
  that touch
```
process.env.[A-Z_]+
```
  but do NOT import
```
server-only
```
- Inverse check: any file with
```
"use client"
```
  importing from such a module is a leak
Outdated
```
next.config.js
```
security headers

Django:

DEBUG=True in production
ALLOWED_HOSTS misconfigured (wildcard
```
*
```
)
Missing CSRF middleware or
```
@csrf_exempt
```
on state-changing views
Raw SQL via
```
extra()
```
,
```
raw()
```
, or
```
RawSQL
```
without parameterization
Pickle deserialization in sessions (use JSON serializer)
Secret key committed to source control

Rails:

Mass assignment without strong parameters
SQL injection via
```
where("column = '#{input}'")
```
Unpatched Action Pack, Action View, or Active Record CVEs
Insecure deserialization in cookies (verify secret_key_base rotation)
CSRF token bypass in API-only mode

Express / Node.js:

Prototype pollution through
```
Object.assign
```
,
```
lodash.merge
```
,
```
deep-extend
```
ReDoS (Regular Expression Denial of Service) in validation patterns
Path traversal through
```
req.params
```
in file serving routes
Missing rate limiting on auth endpoints
```
eval()
```
or
```
Function()
```
with user input
Event loop blocking with synchronous operations

Serverless / edge runtimes (Vercel, Lambda, Cloud Run, Workers):

In-memory state ≠ rate limit. A module-scoped
```
Map
```
or
```
Set
```
for rate limiting, sessions, or caches is per-instance. Cold starts reset state; load spreads across instances; attackers bypass trivially.
- Grep for:
```
const rateLimitMap = new Map
```
  ,
```
const cache = new Map
```
  in server-action / API-route files
- Fix: shared store — Vercel KV, Upstash Ratelimit, Redis, DynamoDB
Unbounded in-memory collections leak memory under traffic. Cap size and evict (LRU or FIFO).
x-forwarded-for
trust: only trustworthy when the edge overwrites it. Behind misconfigured proxy chains it's attacker-spoofable. A fallback to a single
```
"unknown"
```
bucket throttles all anonymous traffic together; random-fallback silently disables the limit.

Spring / Java:

Spring4Shell and related RCE vulnerabilities
Deserialization attacks (Java native serialization, Jackson polymorphic types)
SpEL injection in Spring Expression Language
Missing CSRF protection on state-changing endpoints
Actuator endpoints exposed without authentication

Laravel / PHP:

APP_DEBUG=true in production (leaks env vars in error pages)
SQL injection via raw DB queries without bindings
Mass assignment without
```
$fillable
```
/
```
$guarded
```
File upload without type validation (PHP execution via uploaded .php)
Insecure deserialization in queued jobs

WordPress:

Outdated core, theme, or plugin versions (most common attack vector)
File editor enabled in wp-admin (allows code injection if admin is compromised)
XML-RPC enabled (brute force amplification, SSRF)
Default admin username, weak passwords
Unpatched plugin vulnerabilities (check WPScan database)

除了包中的CVE，还需检查所用框架特有的已知漏洞模式。搜索近期安全公告和常见配置错误。

对于每个直接依赖项，将已安装版本与以下来源交叉验证：

https://github.com/advisories?ecosystem=npm&query=<package>

https://github.com/<org>/<repo>/security/advisories

以下框架特定模式涵盖“常青”反模式（批量赋值、生产环境启用调试等）。近期CVE需要重新检查，因为硬编码的公告列表会快速失效，且大语言模型训练数据通常滞后最新情况6个月以上。

Next.js / React：

Server Actions暴露内部端点（14.1.1版本前的中间件绕过漏洞CVE-2025-29927）
使用
```
dangerouslySetInnerHTML
```
但未进行内容清理
通过图片优化功能导致SSRF（
```
next/image
```
使用无限制域名）
```
.env
```
文件暴露在公共目录或客户端包中（
```
NEXT_PUBLIC_
```
前缀泄露密钥）
中间件认证绕过模式 —— 检查middleware.ts是否匹配所有受保护路由
Server Component / Client Component边界泄露仅服务器端数据：
- 任何读取
```
process.env.SECRET
```
  或实例化数据库客户端的模块应开头添加
```
import "server-only";
```
  —— 若从Client Component导入会导致构建失败
- 搜索：
```
lib/
```
  目录中访问
```
process.env.[A-Z_]+
```
  但未导入
```
server-only
```
  的文件
- 反向检查：任何带有
```
"use client"
```
  的文件导入此类模块均属于数据泄露
过时的
```
next.config.js
```
安全头

Django：

生产环境中DEBUG=True
ALLOWED_HOSTS配置错误（使用通配符
```
*
```
）
缺少CSRF中间件或在状态变更视图上使用
```
@csrf_exempt
```
通过
```
extra()
```
、
```
raw()
```
或
```
RawSQL
```
执行未参数化的原生SQL
会话中使用Pickle反序列化（应使用JSON序列化器）
密钥提交到版本控制系统

Rails：

未使用强参数的批量赋值
通过
```
where("column = '#{input}'")
```
导致SQL注入
Action Pack、Action View或Active Record存在未修复的CVE
Cookie中存在不安全的反序列化（验证secret_key_base是否定期轮换）
API-only模式下CSRF令牌绕过

Express / Node.js：

通过
```
Object.assign
```
、
```
lodash.merge
```
、
```
deep-extend
```
导致原型污染
验证正则表达式存在ReDoS（正则表达式拒绝服务）
通过
```
req.params
```
在文件服务路由中导致路径遍历
认证端点缺少速率限制
使用
```
eval()
```
或
```
Function()
```
处理用户输入
同步操作阻塞事件循环

Serverless / 边缘运行时（Vercel、Lambda、Cloud Run、Workers）：

内存内状态≠速率限制。模块级的
```
Map
```
或
```
Set
```
用于速率限制、会话或缓存时，仅对单个实例有效。冷启动会重置状态；负载会分散到多个实例；攻击者可轻易绕过。
- 搜索：server-action / API路由文件中的
```
const rateLimitMap = new Map
```
  、
```
const cache = new Map
```
- 修复方案：使用共享存储 —— Vercel KV、Upstash Ratelimit、Redis、DynamoDB
无界内存集合在流量下会泄露内存。需限制大小并进行驱逐（LRU或FIFO）。
x-forwarded-for
信任：仅当边缘服务覆盖该字段时才可信。在配置错误的代理链后，该字段可被攻击者伪造。回退到单个
```
"unknown"
```
桶会限制所有匿名流量；随机回退会静默禁用限制功能。

Spring / Java：

Spring4Shell及相关RCE漏洞
反序列化攻击（Java原生序列化、Jackson多态类型）
Spring表达式语言（SpEL）注入
状态变更端点缺少CSRF保护
Actuator端点未认证即暴露

Laravel / PHP：

生产环境中APP_DEBUG=true（错误页面泄露环境变量）
通过未绑定参数的原生数据库查询导致SQL注入
未使用
```
$fillable
```
/
```
$guarded
```
的批量赋值
文件上传未进行类型验证（通过上传.php文件执行PHP代码）
队列任务中存在不安全的反序列化

WordPress：

核心、主题或插件版本过时（最常见的攻击向量）
wp-admin中启用文件编辑器（若管理员账户被攻破，允许代码注入）
XML-RPC启用（暴力破解放大、SSRF）
默认管理员用户名、弱密码
插件存在未修复的漏洞（检查WPScan数据库）

Step 4: Check for Supply Chain Risks

步骤4：检查供应链风险

Beyond known CVEs, look for supply chain attack indicators:

Dependency confusion / substitution:

Private package names that could be claimed on public registries
Missing
```
.npmrc
```
or
```
pip.conf
```
scoping to private registry
No lockfile integrity verification

Typosquatting:

Package names that are close misspellings of popular packages
Recently published packages with very few downloads
Packages that changed ownership recently

Malicious packages:

Postinstall scripts that make network requests or execute code (
```
scripts.postinstall
```
in package.json)
Packages with obfuscated code
Excessive permission requests relative to functionality

Maintenance risk:

Unmaintained packages (no commits in 2+ years, archived repos)
Single-maintainer packages for critical functionality
Packages with known but unpatched vulnerabilities (maintainer unresponsive)

Lockfile integrity:

Lockfile committed?

git ls-files | grep -E 'package-lock\.json|yarn\.lock|pnpm-lock\.yaml|Gemfile\.lock|poetry\.lock|composer\.lock|Cargo\.lock|go\.sum'

CI installs from lockfile?

Check

.github/workflows/*.yml

.gitlab-ci.yml

Jenkinsfile

vercel.json

netlify.toml

Dockerfile

npm install

(bad) vs

npm ci

(good);

yarn install

(bad) vs

yarn install --immutable

(good);

pip install -r

(bad) vs

pip install --require-hashes -r

(good)

```
integrity
```
hashes present in the lockfile? (modern npm/pnpm yes by default)

除了已知CVE，还需查找供应链攻击的迹象：

依赖混淆/替换：

私有包名称可能被公共仓库抢占
缺少
```
.npmrc
```
或
```
pip.conf
```
将私有包范围限定到私有仓库
未验证锁文件完整性

仿冒包（Typosquatting）：

包名称与热门包名称拼写相近
近期发布的包下载量极少
包所有权近期变更

恶意包：

Postinstall脚本发起网络请求或执行代码（package.json中的
```
scripts.postinstall
```
）
包含混淆代码的包
相对于功能请求过多权限

维护风险：

无人维护的包（2年以上无提交、仓库已归档）
关键功能依赖单一维护者的包
存在已知但未修复漏洞的包（维护者无响应）

锁文件完整性：

是否提交了锁文件？执行

git ls-files | grep -E 'package-lock\.json|yarn\.lock|pnpm-lock\.yaml|Gemfile\.lock|poetry\.lock|composer\.lock|Cargo\.lock|go\.sum'

CI是否从锁文件安装？

检查

.github/workflows/*.yml

、

.gitlab-ci.yml

、

Jenkinsfile

、

vercel.json

、

netlify.toml

、

Dockerfile

npm install

（不推荐） vs

npm ci

（推荐）；

yarn install

（不推荐） vs

yarn install --immutable

（推荐）；

pip install -r

（不推荐） vs

pip install --require-hashes -r

（推荐）

锁文件中是否存在
```
integrity
```
哈希？（现代npm/pnpm默认包含）

Step 5: Check Dev Tool and CI/CD Security

步骤5：检查开发工具与CI/CD安全

GitHub Actions:

```
pull_request_target
```
trigger with checkout of PR code (code injection risk)
Secrets accessible in forked PR workflows
Unpinned action versions (
```
uses: actions/checkout@main
```
vs
```
@v4.1.0
```
or SHA pin)
Script injection via
```
${{ github.event.issue.title }}
```
in
```
run:
```
blocks

Docker:

Running as root in container (missing
```
USER
```
directive)
Base image with known CVEs (check with
```
trivy
```
or
```
docker scout
```
)
Secrets baked into image layers (visible via
```
docker history
```
)
```
latest
```
tag instead of pinned version

Terraform / IaC:

Hardcoded secrets in
```
.tf
```
files
Unpinned provider versions
Missing state file encryption
Over-permissive IAM in provider configuration

GitHub Actions：

使用
```
pull_request_target
```
触发器并拉取PR代码（存在代码注入风险）
Fork PR工作流可访问密钥
未固定Action版本（
```
uses: actions/checkout@main
```
vs
```
@v4.1.0
```
或SHA固定）
```
run:
```
块中通过
```
${{ github.event.issue.title }}
```
注入脚本

Docker：

容器中以root用户运行（缺少
```
USER
```
指令）
基础镜像存在已知CVE（使用
```
trivy
```
或
```
docker scout
```
检查）
密钥被打包到镜像层中（可通过
```
docker history
```
查看）
使用
```
latest
```
标签而非固定版本

Terraform / IaC：

```
.tf
```
文件中硬编码密钥
未固定提供者版本
缺少状态文件加密
提供者配置中IAM权限过度宽松

Output Format

输出格式

markdown

undefined

markdown

undefined

Dependency & Stack Security Audit

依赖项与技术栈安全审计

Project: [name]

项目：[名称]

Stack: [language, framework, key tools]

技术栈：[语言、框架、关键工具]

Date: [date]

日期：[日期]

Stack Inventory

技术栈清单

Component	Version	Latest	Status

组件	版本	最新版本	状态

Known Vulnerabilities (CVEs)

已知漏洞（CVE）

Package	Installed	Vuln	Severity	Where reachable	CVE	Fix Version

Where reachable values:

runtime

build-only

dev-only

. Confirm with

npm ls --omit=dev <package>

or inspect the deployment artifact (Vercel function bundle, Docker layer). Build- and dev-only vulnerabilities should not block a release on their own; runtime-reachable ones should.

包	已安装版本	漏洞描述	严重程度	可达性	CVE编号	修复版本

可达性取值：

runtime

build-only

dev-only

。通过

npm ls --omit=dev <package>

或检查部署产物（Vercel函数包、Docker层）确认。仅构建和开发阶段的漏洞不应单独阻止发布；运行时可达的漏洞则需要处理。

Framework-Specific Issues

框架特定问题

[SEVERITY] [Title]

[严重程度] [标题]

Component: [framework/tool name and version] Issue: [description] Evidence: [code or config snippet] Remediation: [specific fix]

组件： [框架/工具名称及版本] 问题： [描述] 证据： [代码或配置片段] 修复方案： [具体修复步骤]

Supply Chain Risks

供应链风险

Risk	Package/Component	Details	Remediation

风险类型	包/组件	详情	修复方案

Dev Tool / CI Security

开发工具/CI安全

Tool	Issue	Severity	Remediation

工具	问题	严重程度	修复方案

Prioritized Action Plan

优先级行动计划

[Critical — actively exploited CVEs, RCE vulnerabilities]
[High — known CVEs with public exploits, supply chain risks]
[Medium — framework misconfigurations, outdated dependencies]
[Low — maintenance risks, best practice improvements]

undefined

[关键 —— 被主动利用的CVE、RCE漏洞]
[高 —— 存在公开利用方式的已知CVE、供应链风险]
[中 —— 框架配置错误、过时依赖项]
[低 —— 维护风险、最佳实践改进]

undefined

Boundaries

边界

Only audit code and configurations the user provides
When identifying CVEs, verify they apply to the actual installed version
Provide specific fix versions or remediation steps for every finding
Note when a vulnerability requires specific conditions to exploit (reducing effective severity)
Refuse to help exploit found vulnerabilities against unauthorized targets

仅审计用户提供的代码和配置
识别CVE时，验证其是否适用于实际安装的版本
为每个发现提供具体的修复版本或修复步骤
注明漏洞是否需要特定条件才能被利用（降低实际严重程度）
拒绝帮助针对未授权目标利用已发现的漏洞

References

参考资料

OWASP Dependency-Check
National Vulnerability Database (NVD)
GitHub Advisory Database
Snyk Vulnerability Database
npm audit / pip-audit / bundler-audit documentation
SLSA (Supply-chain Levels for Software Artifacts) framework

OWASP Dependency-Check
国家漏洞数据库（NVD）
GitHub Advisory Database
Snyk漏洞数据库
npm audit / pip-audit / bundler-audit文档
SLSA（软件工件供应链级别）框架