dependency-audit

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

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

方法

步骤 1：盘点技术栈

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

软件包清单——阅读并记录：

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——检查它们是否被用于掩盖公告，而非修复问题
• Monorepo：读取每个 packages/*/package.json 和 apps/*/package.json，而不只是根目录下的文件
• engines 字段——Node 版本早于 LTS 会让其他审计失去意义

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

根据项目运行相应的审计命令：

# Node.js
npm audit --json                # full structured output
npm audit --omit=dev --json     # production-only: filters dev/build-time vulns
# 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

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

应用修复——使用 --force 前请先阅读：

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 可能会通过将软件包降级到较旧版本来解决公告，因为该版本不会触发审计特征码。这几乎总是错误的做法（例如，将 next@16 降级到 next@9，以“修复”传递依赖 postcss 的 CVE）。检查试运行输出中的 "Will install X@Y, which is a breaking change"——这表示工具正试图降级。

当 npm audit fix 无法解决公告时（上游软件包锁定了传递依赖）：

1. 确定可达性——你的用法是否实际调用了存在漏洞的代码路径？使用 npm ls <package> 并阅读父级软件包的源代码，可以判断该路径是否不可达。
2. 考虑在 package.json 中使用 overrides 固定到已修补的版本（彻底测试——overrides 可能会导致父级软件包出错）。
3. 考虑完全替换父级提供程序。
4. **如果以上方法都不适用：**明确记录问题、跟踪上游进展，并在审计报告中注明，而不是悄悄删除该项发现。

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

除了软件包中的 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 使用不受限制的域名）
• public 目录或客户端包中暴露的 .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 模式下绕过 CSRF 令牌

Express / Node.js：

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

无服务器 / 边缘运行时（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 Expression Language 中的 SpEL 注入
• 会改变状态的端点缺少 CSRF 保护
• Actuator 端点暴露且未经过身份验证

Laravel / PHP：

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

WordPress：

• 核心、主题或插件版本过时（最常见的攻击途径）
• wp-admin 中启用了文件编辑器（管理员账号遭入侵后可被用于注入代码）
• 启用了 XML-RPC（可放大暴力破解攻击、导致 SSRF）
• 使用默认管理员用户名、弱密码
• 插件漏洞未修补（查看 WPScan 数据库）

步骤 4：检查供应链风险

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

依赖混淆／替换：

• 可在公共注册表中被他人注册的私有包名称
• 缺少 .npmrc 或 pip.conf 对私有注册表的范围限定
• 未验证锁文件完整性

仿冒包：

• 与热门包名称相近、容易混淆的包
• 最近发布且下载量极少的包
• 所有权近期发生变更的包

恶意包：

• 会发起网络请求或执行代码的安装后脚本（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（不佳）与 npm ci（良好）；yarn install（不佳）与 yarn install --immutable（良好）；pip install -r（不佳）与 pip install --require-hashes -r（良好）
• 锁文件中是否包含 integrity 哈希？（现代版 npm/pnpm 默认包含）

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

GitHub Actions：

• 使用 pull_request_target 触发器并检出 PR 代码（存在代码注入风险）
• 分支 PR 工作流可访问机密信息
• Action 版本未固定（uses: actions/checkout@main 与 @v4.1.0 或固定 SHA 相比）
• 在 run: 代码块中通过 ${{ github.event.issue.title }} 注入脚本

Docker：

• 容器以 root 身份运行（缺少 USER 指令）
• 基础镜像存在已知 CVE（使用 trivy 或 docker scout 检查）
• 机密信息被写入镜像层（可通过 docker history 查看）
• 使用 latest 标签，而非固定版本

Terraform / IaC：

• .tf 文件中硬编码的机密信息
• Provider 版本未固定
• 状态文件未加密
• Provider 配置中的 IAM 权限过于宽泛

输出格式

# Dependency & Stack Security Audit
## Project: [name]
## Stack: [language, framework, key tools]
## Date: [date]

### Stack Inventory
| Component | Version | Latest | Status |
|-----------|---------|--------|--------|

### Known Vulnerabilities (CVEs)
| 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.

### 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
| Tool | Issue | Severity | Remediation |
|------|-------|----------|-------------|

### Prioritized Action Plan
1. [Critical — actively exploited CVEs, RCE vulnerabilities]
2. [High — known CVEs with public exploits, supply chain risks]
3. [Medium — framework misconfigurations, outdated dependencies]
4. [Low — maintenance risks, best practice improvements]

边界

• 仅审计用户提供的代码和配置
• 识别 CVE 时，确认其适用于实际安装的版本
• 对每项发现都提供具体的修复版本或补救步骤
• 指出利用漏洞所需的特定条件（以降低实际严重程度）
• 拒绝协助利用已发现的漏洞攻击未经授权的目标

参考资料

• OWASP Dependency-Check
• National Vulnerability Database（NVD）
• GitHub Advisory Database
• Snyk Vulnerability Database
• npm audit / pip-audit / bundler-audit 文档
• SLSA（软件制品供应链级别）框架