eris-ths/supply-chain-guard
GitHub: eris-ths/supply-chain-guard
一款面向 npm 和 Python 生态的供应链安全事件第一响应工具，编排多种开源扫描器并提供结构化的检测、评估与修复流程。
Stars: 3 | Forks: 0
# 供应链卫士 (SCG)
SCG **不是**一款在覆盖率上与商业工具竞争的扫描引擎。它是一个 Claude Code skill 和独立的 shell 工具集，擅长做三件事：**(1)** 当特定安全事件爆发时，为您提供快速、可重复的*第一响应*（“我的机器现在受影响了吗？”），**(2)** 将现有的 OSS 扫描器（`npm audit`、`osv-scanner`、`pip-audit`）编排成一次结构化的扫描，以及 **(3)** 记录来之不易的*设计规范*经验——特别是针对 AI 开发环境的经验——这些是普通扫描器无法覆盖的。
它是在真实的安全事件中构建和强化的，包括：
- **[axios@1.14.1 RAT 事件 (2026-03-31)](https://elastic.co/security-labs/axios-one-rat-to-rule-them-all)** — npm 维护者账户被接管（UNC1069/DPRK-APT），注入了携带 RAT 的幽灵依赖
- **[Starlette BadHost (CVE-2026-48710, 2026-05-22)](https://cryptobriefing.com/starlette-badhost-vulnerability-ai-agents/)** — Python HTTP 框架 Host 头路径注入 → SSRF/RCE，影响 FastAPI、vLLM、LiteLLM 以及更广泛的 AI agent 生态系统
## v4 新特性 (2026-05-27)
- **Python 供应链扫描** — 包含 pip-audit / osv-scanner / CVE 标记版本检测的 `scripts/project-scan-py.sh`
- **CVE 标记版本层 (L3-CVE)** — 使用严格的 semver-spec 评估来追踪合法包的已知漏洞版本（开箱即用包含 BadHost CVE-2026-48710）
- **设计规范指南** — stdio 优先的 MCP 传输、版本固定纪律、GCP 默认计算 SA 编辑器强化（参见 SKILL.md §D.7 DesignHygiene）
- **Guild-CLI Devil lense 集成** — 从 guild-cli 工作流中将 SCG 作为 Devil lense 调用（参见下文的“Guild-CLI Devil 集成”）
## 目录
- [存在的原因](#why-this-exists)
- [SCG 与现有工具的区别](#how-scg-differs-from-existing-tools)
- [SCG 是什么（以及不是什么）](#what-scg-is-and-isnt)
- [架构](#architecture)
- [快速入门](#quick-start)
- [扫描模式](#scan-modes)
- [威胁情报](#threat-intelligence)
- [Devil 关卡框架](#devil-gate-framework)
- [独立脚本](#standalone-scripts)
- [CI/CD 集成](#cicd-integration)
- [响应手册](#response-playbook)
- [IOC 参考](#ioc-reference)
- [免责声明](#disclaimer)
- [局限性](#limitations)
- [完整性校验](#integrity-verification)
- [许可证](#license)
## 存在的原因
2026 年 3 月 31 日，广泛使用的 `axios` npm 包（v1.14.1 和 v0.30.4）因维护者账户被接管而遭到破坏，根据 **Google 威胁情报小组** 的说法，此事归咎于 **UNC1069/DPRK-APT**。该攻击注入了一个幽灵依赖项（`plain-crypto-js@4.2.1`），通过 `postinstall` 脚本部署了跨平台 RAT，并伪装成合法的系统进程。
**供应链卫士 (SCG)** 是在事件期间构建的，旨在提供：
1. **立即检测** — 我的机器或项目现在受影响了吗？
2. **结构化评估** — 严重程度如何？影响范围有多大？
3. **引导式响应** — 包含安全确认的逐步修复指南
4. **持续防御** — 防止事件重演的 8 关卡验证框架
## SCG 与现有工具的区别
SCG 并不能替代现有的安全工具。它将多层检测与结构化的验证框架及引导式修复结合在一起——专为在**活跃事件期间**使用，或作为现有工具的定期检查而设计。
| 工具 | 功能 | SCG 的关系 |
|------|-------------|-----------------|
| **`npm audit`** | 检查 registry 中的已知漏洞 | SCG 将 npm audit 作为其 L1 层，然后在此基础上添加了 IOC 文件系统/网络扫描、恶意包检测以及结构化的响应工作流 |
| **`osv-scanner`** | 对照 Google 的 OSV 数据库扫描 lockfile | SCG 将 OSV 作为其 L2 层。osv-scanner 不会检查您文件系统上的 RAT 工件或活跃的 C2 连接 |
| **Snyk / Socket.dev** | 具有实时监控、PR 检查、许可证扫描的商业 SaaS | SCG 是免费的、本地优先的、无需账户、不向第三方发送数据。专为立即响应事件而设计，而非用于持续监控 |
| **手动 IR** | 使用自定义脚本进行临时调查 | SCG 提供了一个可重复的框架（8 个验证关卡、收敛循环、严重性矩阵），而不是因事件而异的一次性检查清单 |
**何时使用 SCG：**
- 刚刚爆发了供应链事件，您需要**立即**检查您的机器和项目
- 您需要一个结构化、可重复的流程，以验证漏洞是否已被彻底解决
- 您需要在本地运行的轻量级检查，且不依赖 SaaS
**何时使用其他工具：**
- 您需要连续的实时监控 → Snyk, Socket.dev
- 您需要许可证合规性扫描 → Snyk, FOSSA
- 您需要涵盖 npm/yarn 之外的范围 → osv-scanner（支持 pip, cargo, go 等）
## SCG 是什么（以及不是什么）
我们宁愿坦诚说明边界，也不愿夸大其词。SCG 做三件事：
1. **作为代码的事件响应手册。** 当命名事件爆发时（axios RAT、Shai-Hulud、新的 CVE），SCG 将“我受影响了吗？如果是，我该怎么办？”转化为可执行的检查清单——8 个验证关卡、一个严重性矩阵，以及一个要求*每个*破坏性操作都必须进行明确 `[y/N]` 确认的修复脚本。这是它的核心价值：商业监控工具无法提供的快速、结构化的*第一响应*。
2. **现有 OSS 扫描器的编排器。** L1/L2 层封装了 `npm audit` / `pip-audit` / `osv-scanner`。大部分原始检测能力是借用的；SCG 的贡献在于将它们捆绑在一次扫描中，添加 registry 工具不具备的文件系统/IOC 检查，并使输出具有可读性和可操作性。
3. **真实设计规范经验的文档** (SKILL.md §D.7) —— 我们实际遇到或调查过的事情：MCP 传输选择、GCP 默认 SA 强化、安装时执行向量，以及针对 AI 开发工具的威胁（Shai-Hulud 读取 `.claude/settings.json`，SANDWORM_MODE 毒害 MCP 配置）。这个细分领域——面向 AI 辅助开发的供应链规范——是 SCG 真正具有差异化优势的地方。
### SCG 特意不做的事
- **不追求覆盖率竞争。** 威胁数据库（`SKILL.md` D.2，L3 静态列表）是**手动维护的**——它包含我们阅读过的安全事件，而不是商业实时 feed 追踪的数以万计的恶意包。人工策划的列表*无法*跟上新威胁的真实产生速度，我们也不会假装它能。
- **不是行为分析引擎。** SCG 匹配已知模式。构造上，混淆的 payload 和没有公开安全公告的真正 zero-day 不在范围内。
- **不是持续监控。** 它是您在事件发生时或定期巡查时运行的时间点检查——而不是监视您依赖图的服务。
### SCG 的发展方向
由于人工维护的数据库无法在覆盖率上取胜，我们有意将投资集中在 SCG *难以替代*的地方，而不是它始终会落后的地方：
- **更深度的安全事件响应手册** (#1) —— 更好的第一响应体验，更多事件模板。
- **AI 开发环境规范** (#3) —— 针对瞄准 Claude Code / Cursor / MCP server 及类似工具的威胁提供检测和指导，这是商业供应链扫描器在很大程度上没有解决的。
静态威胁库 (#2) 将在重大事件发生时继续更新，但这明确**不是**我们试图竞争的方向。
## 架构
SCG 遵循 **领域驱动设计 (DDD)** 架构，分为三层：
```
+-----------------------------------------------------+
| Domain Layer |
| Threat models, known threats DB, severity matrix, |
| Devil Gate definitions |
+-----------------------------------------------------+
| Application Layer |
| Use cases, scan pipeline, response protocols, |
| Devil execution loop |
+-----------------------------------------------------+
| Infrastructure Layer |
| Scanner scripts (npm audit, OSV, static list, |
| IOC filesystem, network, lockfile integrity) |
+-----------------------------------------------------+
```
### 扫描流水线
相同的 5 层流水线适用于两个生态系统，并在每一层使用特定于生态系统的扫描器：
```
L1 ──→ L2 ──→ L3 ──→ IOC ──→ LF ──→ assess(SeverityMatrix) ──→ VERDICT
```
| 层 | npm/yarn (`project-scan.sh`) | Python (`project-scan-py.sh`) |
|-------|------------------------------|-------------------------------|
| **L1** | `npm audit` | `pip-audit` |
| **L2** | `osv-scanner` / OSV.dev API | `osv-scanner` |
| **L3** | 静态列表 (恶意 + 抢注) | 静态列表 (恶意 / 抢注 + CVE 标记版本) |
| **IOC** | 文件系统 + 网络 artifact | 文件系统 + 进程 artifact (Python 特色) |
| **LF** | `npm ci --dry-run` + 完整性计数 | Lockfile 完整性 (uv.lock / poetry.lock / requirements*.txt) |
两条流水线都汇聚到相同的严重性矩阵和 Devil 关卡框架中。
## 快速入门
### 作为 Claude Code Skill
将 `SKILL.md` 复制到您的 Claude Code skills 目录：
```
# 全局（所有项目）
cp SKILL.md ~/.claude/skills/supply-chain-guard.md
# 或针对特定项目
mkdir -p .claude/skills
cp SKILL.md .claude/skills/supply-chain-guard.md
```
然后在 Claude Code 中调用：
```
> /supply-chain-guard
> "Check this project for supply chain issues"
> "Is my machine affected by the axios compromise?"
```
### 作为独立脚本
```
# 环境范围扫描（IOC + 所有项目） [只读]
./scripts/env-scan.sh
# npm/yarn 项目扫描（要求 cwd 中存在 package.json） [只读]
./scripts/project-scan.sh
# Python 项目扫描（要求 cwd 中存在 pyproject.toml / requirements*.txt / poetry.lock / uv.lock） [只读，v4 中新增]
./scripts/project-scan-py.sh
# 仅 IOC 扫描（文件系统 + 网络制品） [只读]
./scripts/ioc-scan.sh
# 修复（交互式，每个操作都需要确认）
./scripts/respond.sh --critical # Full RAT cleanup (npm + Python)
./scripts/respond.sh --high axios 1.14.0 # Pin npm package to safe version
./scripts/respond.sh --high urllib3 2.7.0 # Pin Python package (auto-detects pip/poetry/uv)
```
对于多语言仓库（npm + Python），请从相关的子目录中依次运行这两个项目扫描器。
## 扫描模式
### 环境扫描 (`env_scan`)
扫描您的整个开发机器以查找威胁指标。
| 检查项 | 描述 |
|-------|-------------|
| **IOC: 文件系统** | RAT 二进制文件、持久化机制、暂存文件 |
| **IOC: 网络** | 活跃的 C2 连接 (IP + 域名) |
| **IOC: 进程** | 正在运行的恶意进程 |
| **跨项目** | 扫描所有 `package-lock.json` 文件以查找受感染版本 |
| **恶意包** | 任何 lockfile 中的已知恶意包名 |
**触发词：** “这台 PC”、“环境检查”、“全机扫描”
### 项目扫描 — npm/yarn (`project_scan`)
深入扫描单个 npm/yarn 项目。在包含 `package.json` 的目录中运行。
| 层 | 扫描器 | 描述 |
|-------|---------|-------------|
| **L1** | `npm audit` | 通过 npm registry 发现已知漏洞 |
| **L2** | `osv-scanner` / OSV.dev API | Google 的开源漏洞数据库 |
| **L3** | 静态列表 | 硬编码的已知恶意包检查 |
| **IOC** | 文件系统 + 网络 | RAT 工件检测 |
| **LF** | Lockfile 完整性 | `npm ci --dry-run` + 完整性哈希计数 |
**触发词：** “这个项目”、“npm audit”，或当前工作目录 (cwd) 中存在 `package.json`
### 项目扫描 — Python (`project_scan_py`, 在 v4 中加入)
深入扫描单个 Python 项目。在包含 `pyproject.toml`、`requirements*.txt`、`poetry.lock` 或 `uv.lock` 的目录中运行。
| 层 | 扫描器 | 描述 |
|-------|---------|-------------|
| **L1** | `pip-audit` | 通过 PyPI Advisory DB 发现已知漏洞（可选——如未安装则跳过；推荐使用 `pip install pip-audit`） |
| **L2** | `osv-scanner` | Google 的开源漏洞数据库，针对 `uv.lock` / `poetry.lock` / `requirements*.txt` 进行扫描（可选——如未安装则跳过） |
| **L3-MAL** | 静态恶意列表 (`_L3_LIST`) | 已知被劫持 / 域名抢注包名。匹配 PEP 621 列表、Poetry inline 以及 requirements 风格的声明（参见 [PR #4](https://github.com/eris-ths/supply-chain-guard/pull/4)）。命中即失败 |
| **L3-CVE** | 静态 CVE 标记版本列表 (`_L3_CVE_LIST`) | 合法包的已知漏洞版本（例如，针对 [BadHost CVE-2026-48710](https://cryptobriefing.com/starlette-badhost-vulnerability-ai-agents/) 的 `starlette<1.0.1`）。通过 Python 的 `packaging` 库进行严格的 semver-spec 评估。确认匹配即失败。如果声明了包但不存在 lockfile（无法评估版本），则会发出警告 |
| **IOC** | 文件系统 + 进程 | Python 特色工件（流氓脚本、可疑进程） |
| **LF** | Lockfile 完整性 | 验证 `uv.lock` / `poetry.lock` / `requirements*.txt` 能否被干净地解析并且包含固定的版本号 |
**触发词：** 存在 Python 文件的“这个项目”，或当前工作目录 (cwd) 中包含 `pyproject.toml` / `requirements*.txt` / `poetry.lock` / `uv.lock` 中的任意一个
## 威胁情报
### 已知威胁数据库
| ID | 日期 | 包 | 威胁行为者 | 向量 |
|----|------|---------|-------------|--------|
| **T001** | 2026-03-31 | `axios@1.14.1`, `axios@0.30.4` | UNC1069/DPRK-APT | 维护者被接管 → 幽灵依赖 → RAT |
| **T002** | 2018-11 | `event-stream@3.3.6` | 未知 | 依赖注入 → 窃取加密货币 |
| **T003** | 持续中 | `crossenv`, `loadsh`, `crypto-js-esm` | 各种 | 域名抢注 → postinstall 窃取 |
### T001 攻击链 (axios RAT)
```
Credential theft → npm publish (bypass CI) → Inject phantom dep (plain-crypto-js)
→ postinstall exec → RAT drop → C2 beacon (sfrclak.com:8000) → Persist
```
### 安全版本
| 包 | 安全 | 已被入侵 |
|---------|------|-------------|
| axios (最新) | `1.14.0` (确切) 或 `>=1.14.2` | `1.14.1` |
| axios (旧版) | `0.30.3` (确切) | `0.30.4` |
### 公告 ID
- [GHSA-fw8c-xr5c-95f9](https://github.com/advisories/GHSA-fw8c-xr5c-95f9)
- [MAL-2026-2306](https://osv.dev/vulnerability/MAL-2026-2306)
## Devil 关卡框架
SCG 使用 **8 关卡验证框架**，分为 4 个类别，作为带有收敛循环的串行链执行。
### 关卡
| # | 关卡 | 类别 | 问题 |
|---|------|----------|----------|
| G1 | 直接依赖 | 依赖投毒 | 是否有任何直接依赖处于受感染的版本？ |
| G2 | 间接依赖 | 依赖投毒 | 是否有任何间接（传递）依赖受到了牵连？ |
| G3 | RAT 工件 | 运行时入侵 | 文件系统上是否有 RAT 痕迹？ |
| G4 | Postinstall 脚本 | 运行时入侵 | 是否有可疑的 `postinstall` 脚本？ |
| G5 | Lockfile 完整性 | 完整性 | Lockfile 是否被篡改过？ |
| G6 | 来源 | 完整性 | 包是否来自合法的来源/维护者？ |
| G7 | 网络 | 环境 | 是否有可疑的出站连接？ |
| G8 | CI/CD 强化 | 环境 | CI/CD 是否绕过了 postinstall / 强制使用了冻结的 lockfile？ |
### 链式执行
```
S1: Dependency (G1+G2)
→ S2: Runtime (G3+G4)
→ S3: Integrity (G5+G6)
→ S4: Environment (G7+G8)
→ Any fail? → Fix → Re-run entire chain
→ All pass? → "No concerns" → Done
→ 3 rounds without convergence? → Escalate to user
```
### 严重性矩阵
| 级别 | 条件 | 操作 |
|-------|-----------|--------|
| **CRITICAL** | 发现 RAT 工件 或 安装了恶意包 | 网络隔离 → 杀死进程 → 移除持久化 → 重新安装 |
| **HIGH** | 正在使用受影响的版本 | 固定安全版本 → Override → `npm ci` → 验证 |
| **MEDIUM** | 可疑的 postinstall 脚本 | 人工审查 → 加入白名单或移除 |
| **LOW** | Lockfile 偏移 | `npm ci` 重新同步 |
| **CLEAR** | 所有检查均通过 | 无需操作 |
## 独立脚本
### `scripts/env-scan.sh`
完整的环境扫描。检查 IOC 工件，扫描 `$HOME` 下的所有 lockfile（可配置），并报告受感染的包。
```
./scripts/env-scan.sh [scan_root_dir]
# 默认值：$HOME
```
### `scripts/project-scan.sh`
项目级扫描。在包含 `package.json` 的目录中运行。
```
cd my-project
/path/to/scripts/project-scan.sh
```
### `scripts/ioc-scan.sh`
仅 IOC 扫描。针对已知的 C2 指标检查文件系统工件、正在运行的进程和网络连接。跨平台（macOS/Linux/Windows 通过 PowerShell）。
```
./scripts/ioc-scan.sh
```
### `scripts/respond.sh`
交互式修复。**每个破坏性操作都需要 `[y/N]` 确认（默认：NO）。**
```
# 严重：完整 RAT 清理（终止 → 移除 → 重新安装）
./scripts/respond.sh --critical
# 高：将受入侵的 package 锁定至安全 version
./scripts/respond.sh --high axios 1.14.0 # npm
./scripts/respond.sh --high event-stream 3.3.5 # npm
./scripts/respond.sh --high urllib3 2.7.0 # python (pip/poetry/uv auto-detected)
```
`--critical` 模式下的步骤：
1. 网络隔离（通过 `/etc/hosts` 屏蔽 C2 域名）
2. 杀死 RAT 进程
3. 移除持久化（LaunchAgents / crontab / 计划任务）
4. 删除 `node_modules` 和 lockfile，清除 npm 缓存
- **4b (Python):** 清理 pip 缓存（安全、自动）；venv 重建作为手动步骤展示
5. 重新安装依赖项
6. 提示进行验证扫描（`project-scan.sh` 和/或 `project-scan-py.sh`）
每一步都会检查是否确实需要执行该操作（例如，如果没有运行 RAT 进程，则跳过“杀死”步骤），并在请求确认之前准确显示将要执行的内容。
对于 **HIGH** 模式，npm 会自动应用 override；对于 Python 则是引导式的（检测管理器 → 打印固定版本命令 → 仅应用安全的步骤）。请参阅[快速入门](#quick-start)中的 Python 修复说明。
## CI/CD 集成
### GitHub Actions
```
name: Supply Chain Guard
on:
pull_request:
paths:
- 'package.json'
- 'package-lock.json'
- 'yarn.lock'
jobs:
scg-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies (hardened)
run: npm ci --ignore-scripts
- name: Run SCG project scan
run: |
chmod +x ./scripts/project-scan.sh
./scripts/project-scan.sh
- name: Run IOC scan
run: |
chmod +x ./scripts/ioc-scan.sh
./scripts/ioc-scan.sh
```
### 强化建议
```
# 在 CI 中始终使用：
npm ci --ignore-scripts # Block postinstall execution
# npm ci 本身就在设计上强制执行 lockfile 完整性（不匹配时报错）
# Yarn 等效命令：
yarn install --frozen-lockfile --ignore-scripts
```
## 响应手册
### 如果是 CRITICAL（检测到 RAT）
1. **网络隔离** — 通过 `/etc/hosts` 屏蔽 C2 域名
2. **杀死进程** — 终止 RAT 进程（`com.apple.act.mond`, `ld.py`, `wt.exe`）
3. **移除持久化** — 删除 LaunchAgents、crontab、计划任务
4. **清理 npm** — 删除 `node_modules` 和 `package-lock.json`，清除 npm 缓存
5. **重新安装** — 执行全新的 `npm install && npm ci`
6. **重新扫描** — 重新运行完整流水线，期望得到 CLEAR
### 如果是 HIGH（安装了受影响的版本）
1. 使用 respond.sh **固定安全版本**：
./scripts/respond.sh --high axios 1.14.0
这会将 `overrides` (npm) 或 `resolutions` (yarn) 添加到 package.json 中，重新安装，并提示进行验证。
2. **或者**在 `package.json` 中**手动**操作：
{ "overrides": { "axios": "1.14.0" } }
Yarn: `{ "resolutions": { "axios": "1.14.0" } }`
3. **重新安装**：`npm ci`
4. **验证**：重新运行扫描
## IOC 参考
### 文件系统工件
| 平台 | 路径 | 类型 |
|----------|------|------|
| macOS | `/Library/Caches/com.apple.act.mond` | RAT 二进制文件 |
| macOS | `~/Library/LaunchAgents/com.apple.act.mond.plist` | 持久化 |
| Windows | `%PROGRAMDATA%\wt.exe` | RAT 二进制文件 (伪装成 Windows 终端) |
| Windows | `%TEMP%\6202033.vbs` | 释放器 |
| Windows | `%TEMP%\6202033.ps1` | 释放器 |
| Linux | `/tmp/ld.py` | RAT 脚本 |
| Linux | `/tmp/.npm-cache/` | 暂存目录 |
### 持久化机制
| 平台 | 机制 | 标识符 |
|----------|-----------|------------|
| macOS | LaunchAgent | `com.apple.act.mond` |
| Windows | 计划任务 | `WindowsTerminalUpdate` |
| Linux | Crontab 条目 | 引用 `ld.py` 或 `.npm-cache` |
### 网络指标
| 类型 | 值 |
|------|-------|
| C2 域名 | `sfrclak.com` |
| C2 IP | `142.11.206.73` |
| C2 端口 | `8000` |
### 伪装技术
| 平台 | 伪装为 |
|----------|-------------|
| macOS | Apple 系统进程 (`com.apple.act.mond`) |
| Windows | Windows 终端 (`wt.exe` 在 ProgramData 中) |
## 输出格式
```
SCG ──────────────────────────────────
[L1:audit] CLEAR|!!sev
[L2:osv] CLEAR|!!vuln-ids
[L3:static] CLEAR|!!pkg
[IOC:fs] CLEAR|!!C:artifact
[IOC:net] CLEAR|!!C:c2
[LF:integ] CLEAR|!!drift
─── Devil Gate(8) ────────────────────
G1:direct_dep G2:transitive G3:rat_fs
G4:postinstall G5:lockfile G6:provenance
G7:network G8:cicd
─── Devil Chain(R.N) ─────────────────
S1:dependency → S2:runtime → S3:integrity → S4:environment
─── Loop ─────────────────────────────
R.N → converge|continue
[VERDICT] CLEAR|HIGH|CRITICAL
───────────────────────────────────────
```
## 参考
| 来源 | 描述 |
|--------|-------------|
| [Zenn (JP)](https://zenn.dev/gunta/articles/0152eadf05d173) | 日本早期报告 |
| [Elastic Security Labs](https://elastic.co/security-labs/axios-one-rat-to-rule-them-all) | 技术分析（RAT 反汇编、C2 协议、时间线） |
| [SANS](https://sans.org/blog/axios-npm-supply-chain-compromise-malicious-packages-remote-access-trojan) | 企业 IR 程序 |
| [Huntress](https://huntress.com/blog/supply-chain-compromise-axios-npm-package) | YARA 特征码 |
| [Elastic Detections](https://elastic.co/security-labs/axios-supply-chain-compromise-detections) | SIEM 检测规则 (YARA/osquery/KQL) |
| [Semgrep](https://semgrep.dev/blog/2026/axios-supply-chain-incident-indicators-of-compromise-and-how-to-contain-the-threat/) | 静态分析规则、遏制指南 |
| [SOCRadar](https://socradar.io/blog/axios-npm-supply-chain-attack-2026-ciso-guide/) | 包含 IOC 时间线的 CISO 指南 |
| [Wiz](https://wiz.io/blog/axios-npm-compromised-in-supply-chain-attack) | 云影响分析、容器扫描 |
| [NVD CVE-2026-48710](https://nvd.nist.gov/vuln/detail/CVE-2026-48710) | **主要** — NVD 权威条目（发布于 2026-05-26，CVSS 3.1 基础分 6.5 MEDIUM，AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N） |
| [GHSA-86qp-5c8j-p5mr](https://github.com/Kludex/starlette/security/advisories/GHSA-86qp-5c8j-p5mr) | **主要** — 关于 `Kludex/starlette` 的 GitHub 安全公告（发布于 2026-05-21）：“缺失的 Host 头验证会污染 request.url.path，绕过基于路径的安全检查” |
| [Starlette v1.0.1 发布说明](https://github.com/Kludex/starlette/releases/tag/1.0.1) | **主要** — 修复版本（发布于 2026-05-21）。固定 `starlette>=1.0.1`（以及用于传递性解析的 `fastapi>=0.119`） |
| [Starlette BadHost 覆盖 (KuCoin)](https://kucoin.com/news/flash/starlette-vulnerability-exposes-millions-of-ai-agents-to-hackers) | 次要 — Python 生态系统影响，AI agent 定位 |
| [BadHost AI agent 分析 (CryptoBriefing)](https://cryptobriefing.com/starlette-badhost-vulnerability-ai-agents/) | 次要 — FastAPI / vLLM / LiteLLM 下游影响分析 |
## Guild-CLI Devil 集成
如果您使用 [guild-cli](https://github.com/eris-ths/guild-cli)（或任何公开 Devil lense 工作流的项目），在审查期间可以将 SCG 作为安全 lense 之一调用。
### 推荐的调用模式
```
# 在 guild-cli review 会话中，于项目根目录下：
~/path/to/supply-chain-guard/scripts/project-scan.sh # for npm/yarn projects
~/path/to/supply-chain-guard/scripts/project-scan-py.sh # for Python projects
# 捕获扫描输出作为判断的证据：
SCG_OUTPUT=$(~/path/to/supply-chain-guard/scripts/project-scan.sh 2>&1 || true)
# (a) 将其记录为新的判断（快速通道 — 无需事先 review）：
gate fast-track --from "$USER" \
--action "SCG supply-chain scan (Devil lense)" \
--reason "$SCG_OUTPUT"
# (b) 或将其作为 Devil lense 附加到现有的 review 请求 上：
gate review --lense devil --verdict concern --note "$SCG_OUTPUT"
```
### 为什么将 SCG 与 Devil 配对
Devil's Advocate（“壊しにいく”）和 SCG 共享相同的姿态：**假设最坏的情况，系统地进行扫描，然后收敛**。SCG 在 Devil 扫描中提供了供应链维度的检查——即项目的依赖项可能会在背后做什么——与其他 lense（安全 / 正确性 / 架构 / 用户 / 运维）一起发挥作用。
### Devil 配对的局限性
- SCG 以只读模式运行；Devil lense 不会推送修复。当需要进行修复时，请单独使用 `respond.sh`（需要明确的用户确认）
- 在大型仓库中，SCG 输出可能会超出 Devil 的上下文预算；如果需要，可通过 `tail -50` 进行管道过滤
- 对于多语言仓库，请同时运行 `project-scan.sh` 和 `project-scan-py.sh` 并合并发现结果
## 免责声明
SCG 是一款检测工具，而非安全保证。预先说明它能做什么和不能做什么正是设计的一部分。
**本软件按“原样”提供，不提供任何形式的保证。** 使用供应链卫士，即表示您确认并同意以下内容：
- **不能替代专业安全服务。** SCG 是一种补充检测工具，不是全面的安全解决方案。它不能替代专业的事件响应、端点检测与响应 (EDR) 软件或安全审计。
- **不保证能检测到。** `CLEAR` 的结论意味着没有发现与该工具的已知威胁模式匹配的内容。**这并不意味着您的系统或项目没有遭到破坏。** 新型、未知或经过修改的攻击可能无法被检测到。
- **不保证修复效果。** 提供的修复步骤（`respond.sh`）针对特定威胁的已知指标。它们可能无法完全消除复杂入侵的所有痕迹。如果您怀疑系统正在遭到破坏，请联系专业的事件响应团队。
- **使用风险自负。** 对于因使用或无法使用本工具而造成的任何损害、数据丢失或安全事件，作者不承担任何责任。这包括但不：漏报（错失的检测）、误报（错误的检测），或运行修复脚本产生的意外后果。
- **不是法律或合规建议。** 此工具不满足安全扫描的监管、合规或法律要求。请咨询合适的专业人员以满足合规需求。
## 局限性
了解 SCG **不能**做什么与了解它能做什么同样重要。
### 检测边界
| SCG 检查什么 | SCG 不检查什么 |
|-----------------|------------------------|
| 已知受感染的包版本（硬编码 DB） | 没有公开安全公告的 zero-day 供应链攻击 |
| 已知恶意包名 | 尚未进入静态列表的域名抢注包 |
| 已知威胁的特定 IOC 文件路径 | 被释放到非标准路径的任意恶意软件 |
| 特定的 C2 IP 地址和域名 | 已经轮换或更改的 C2 基础设施 |
| 直接依赖中的 `postinstall` 脚本 | 看似合法的脚本中隐藏的混淆恶意代码 |
### 威胁数据库新鲜度
已知威胁数据库（SKILL.md 中的 `D.2`）是**手动维护**的。它没有连接到任何实时威胁 feed。从发现新的供应链事件到更新此数据库之间，存在固有的延迟。
- **最后更新：** 2026-05-27 (v4：Python 支持，加入 BadHost CVE-2026-48710)
- **覆盖范围：** 3 个 npm 威胁家族 (T001-T003) + 4 个 Python 劫持/抢注条目 + 1 个 Python CVE 标记版本条目
- **Python 覆盖范围 (v4)：** 主要是基于 lockfile 的扫描 (uv.lock / poetry.lock / requirements.txt)。CVE 标记版本层是**尽力而为**的——它只标记符合 `_L3_CVE_LIST` 条目并通过严格 semver-spec 评估的包，并且依赖于安装的 `packaging` 以进行准确的版本匹配
务必与实时来源交叉参考，例如 [npm advisories](https://github.com/advisories)、[OSV.dev](https://osv.dev/) 以及 [参考资料](#references) 部分列出的供应商安全博客。
### 误报风险
在极少数情况下，以下 IOC 路径可能会与合法软件发生冲突：
| IOC 路径 | 潜在误报 |
|----------|------------------------|
| `/tmp/.npm-cache/` | 非标准配置下的合法 npm 缓存 |
| `/tmp/ld.py` | 具有相同文件名的无关 Python 脚本 |
| 进程名 `wt.exe` | 如果位于 ProgramData 中，则为合法的 Windows 终端 |
**在运行修复之前，务必验证 IOC 发现。** `ioc-scan.sh` 脚本报告发现结果供人工审查——它不会执行任何操作。`respond.sh` 脚本要求对每个破坏性操作进行明确确认（默认：NO），正是因为存在这种风险。
### 网络扫描局限性
- 基于 `lsof` 的网络检查只能检测**当前活跃**的连接。间歇性连接的 C2 beacon 在扫描时可能不处于活跃状态。
- DNS 缓存检查是尽力而为的，并且取决于操作系统。被清除的缓存不会显示历史连接。
- 加密或通过隧道传输的 C2 流量无法仅通过端口/IP 匹配来检测。
### 范围
- **npm/yarn 和 Python (pip/poetry/uv)。** 不涵盖 cargo、go modules 或其他包生态系统。
- **仅限已知威胁。** 这是一个模式匹配工具，而不是行为分析引擎。
- **时间点扫描。** 结果反映了执行那一刻的状态。持续监控需要重复执行或与 CI/CD 集成。
## 完整性校验
验证您的 SCG 副本是否被篡改。将这些 SHA-256 校验和与您的本地文件进行比较：
```
67ac6216cbe18fdf7050fd267bce4157c016e5c60cd4f84f63b8cf71e80ae3b9 scripts/env-scan.sh
da01f8362563b55b1553f923a748f07d24f24522366e0545e6ba0c09801f8e54 scripts/project-scan.sh
77e7ebba6d44ea020e511a49bc2cbc974d01495de40d35e8dfb7fcc93008954b scripts/project-scan-py.sh
82aaa4ed898ce354addc064ccf84cca9a498ef4e90fe58613e1110146577609f scripts/ioc-scan.sh
72ed333838b5584c3b1faf889edc81b0e3195c27396c3b36c62aaebf5f952117 scripts/ioc-scan.ps1
0e6b30e57c959180e22e0ba16f860e9fdc7304045947995084703fb14381d12e scripts/respond.sh
a44be79d909058c9d216e7cbc5cca736cf8816a492c8d35a6b90c74c042abf5b SKILL.md
```
验证：
```
shasum -a 256 scripts/*.sh scripts/*.ps1 SKILL.md
```
## 许可证
[MIT](LICENSE)
**由 [Eris](https://github.com/eris-ths) 构建** — 因为您的依赖项不应成为他人的攻击面。
标签：Cutter, GNU通用公共许可证, Node.js, Python, 依赖审计, 库, 应急响应, 文档安全, 无后门, 网络信息收集, 软件开发工具包