reviewing-dependencies

依赖项漏洞工作流

步骤 1：收集警报

# List all open Dependabot alerts sorted by severity
gh api /repos/{owner}/{repo}/dependabot/alerts --jq '.[] | select(.state == "open") | {number, severity: .security_vulnerability.severity, package: .security_vulnerability.package.name, ecosystem: .security_vulnerability.package.ecosystem, summary: .security_advisory.summary}'

# Filter by severity
gh api "/repos/{owner}/{repo}/dependabot/alerts?severity=critical&state=open"

# Get full details for a specific alert
gh api /repos/{owner}/{repo}/dependabot/alerts/{alert_number}

步骤 2：评估影响

对于每条警报，请确定：

1. 漏洞代码路径是否可达？ — 应用是否实际使用了该依赖项中的漏洞函数或功能？
2. 这是直接依赖还是传递依赖？ — 传递依赖中的漏洞可能更难修复，但仍会带来实际风险。
3. CVSS 评分是多少？是否有可用的漏洞利用？（按照 triaging-security-findings 定义的 CVSS 约定对有效严重性评分。）CVSS 评分较高且存在公开漏洞利用时，需要立即处理。CVSS 评分中等且没有已知漏洞利用时，可以安排处理。
4. 哪些版本受影响？哪些版本已修复？ — 检查升级属于小版本更新还是会造成重大变更。

步骤 3：决定采取的措施

情况	措施
有可用修复，且只需更新小版本	立即更新
有可用修复，但需要更新大版本	评估重大变更，安排更新
暂无修复，且代码路径可达	实施变通方案或替换依赖项
暂无修复，且代码路径不可达	记录并监控，设定复审日期
漏洞存在于传递依赖中	使用 overrides/resolutions 固定到已修复版本

传递依赖风险

直接依赖可以在 package.json 或 .csproj 文件中查看，但传递依赖（依赖项的依赖项）占依赖树的大多数，且往往不可见。

传递依赖为何重要：

• 深层嵌套依赖中的漏洞，与直接依赖中的漏洞一样容易被利用
• 传递依赖较少受到主动监控
• 更新传递依赖可能需要更新引入它的直接依赖

调查方法：

# npm: Show full dependency tree
npm ls --all

# npm: Find which direct dependency pulls in a vulnerable transitive
npm ls <vulnerable-package>

# .NET: List all vulnerable packages including transitive
dotnet list package --vulnerable --include-transitive

# .NET: Show dependency graph
dotnet list package --include-transitive

依赖项健康状况评估

评估是否采用或继续使用某个依赖项时，请考量：

标准	良好信号	风险信号
维护情况	定期提交，积极响应问题	12 个月以上没有提交，问题无人响应
漏洞历史	CVE 较少，修复迅速	CVE 反复出现，响应缓慢
维护者人数	有多位活跃维护者	只有一位维护者，人员风险系数为 1
社区	下载量高，用户活跃	对于声称的适用范围，采用率极低
许可证	与项目兼容（MIT、Apache-2.0）	许可证限制严格或含糊不清
安全实践	发布版本已签名，有安全策略，启用 2FA	没有安全策略，发布版本未经签名

Aikido 集成

Aikido 是 Bitwarden 的容器和开源依赖项扫描器。它会持续扫描已连接的仓库，并在与 SAST、IaC 和机密扫描结果相同的信息流中展示开源（SCA）和容器问题。

使用 aikido:issues 技能（aikido_issues_list）查询问题，并限定相关仓库，将 issue_types 筛选为 open_source（依赖项 CVE）和 docker_container（容器映像漏洞）。cloud_instance 是 Aikido 中用于云 VM/实例问题的独立类型，不在依赖项和容器审查的范围内。

如果调用方提供了 Aikido 证据，请使用这些证据。否则，查询 aikido:issues；如果该技能不可用，请停止并告知用户，不要在缺少这些数据的情况下继续操作。

# Use the aikido:issues skill, e.g.:
# issue_types: ["open_source"], repo_name: "<repo>"       -> dependency CVEs
# issue_types: ["docker_container"], repo_name: "<repo>"  -> container image vulnerabilities

解读 Aikido 输出：

• 每条问题都包含：问题标题、类型、严重性（及严重性标签）、修复指导和 SLA 截止日期
• 使用 out_of_sla: true 聚焦于修复 SLA 已过期的问题
• 分类处理遵循与其他 Aikido 问题相同的基于 Jira 的流程，详见 triaging-security-findings 技能

平台专属指南

NuGet（.NET）

# Check for vulnerable packages
dotnet list package --vulnerable

# Include transitive dependencies
dotnet list package --vulnerable --include-transitive

# Check for outdated packages
dotnet list package --outdated

NuGet 特有注意事项：

• .NET Framework 包的漏洞情况可能与 .NET Core 不同
• 相比 packages.config，更推荐在 .csproj 中使用 PackageReference，以便更好地解析传递依赖
• 在多项目解决方案中使用 Directory.Packages.props 集中管理版本

npm（Node.js）

# Run security audit
npm audit

# Auto-fix where possible
npm audit fix

# Force fixes (may introduce breaking changes)
npm audit fix --force

# Check lockfile integrity
npm ci  # Installs exactly from lockfile, fails if lockfile is out of date

npm 特有注意事项：

• 必须提交 package-lock.json 并保持其同步
• 使用 package.json 中的 overrides 强制指定传递依赖的版本：

  {
    "overrides": {
      "vulnerable-package": ">=2.0.0"
    }
  }
  

• 注意依赖项中的 postinstall 脚本——它们会在 npm install 期间执行任意代码

SBOM 概念

软件物料清单（SBOM）是软件制品中所有组件的清单。理解 SBOM 有助于评估供应链风险：

• 包含内容： 包名、版本、许可证、依赖关系（直接依赖与传递依赖）
• 重要性： 新 CVE 发布时，可快速响应并立即确定受影响的项目
• 标准格式： SPDX、CycloneDX
• GitHub 集成： GitHub 会自动生成依赖关系图；Dependabot 使用该图发送警报

关键规则

• 切勿忽略严重/高危 Dependabot 警报，除非有记录在案的合理理由。即使看起来无法触及存在漏洞的代码路径，也要记录原因。
• 优先升级，而非固定版本。 固定有漏洞的版本并添加变通方案会累积技术债务。有可用修复版本时应进行升级。
• 评估完整的传递依赖树。 直接依赖可能安全，但其传递依赖未必安全。
• 采用新依赖项前先进行审查。 添加任何新包之前，先根据上述健康标准进行检查。依赖项越多，攻击面越大。
• 锁定依赖项。 始终提交锁文件（package-lock.json、packages.lock.json）。在 CI/CD 中使用 npm ci，而不是 npm install。