Supply Chain Guard (SCG)

An incident-response toolkit for npm/yarn and Python (pip/poetry/uv) supply chain attacks — free, local, dependency-free.

SCG — это не сканирующий движок, конкурирующий с коммерческими инструментами по охвату. Это навык Claude Code и автономный набор shell-инструментов, который хорошо делает три вещи: (1) обеспечивает быстрый, воспроизводимый первый ответ, когда происходит конкретный инцидент («затронута ли моя машина прямо сейчас?»), (2) объединяет существующие OSS-сканеры (npm audit, osv-scanner, pip-audit) в один структурированный проход и (3) документирует выстраданные уроки гигиены проектирования — особенно для сред разработки ИИ, — которые обычные сканеры не покрывают.

Он создавался и дорабатывался во время реальных инцидентов, включая:

• Инцидент с RAT в [email protected] (2026-03-31) — взлом учётной записи мейнтейнера npm (UNC1069/DPRK-APT), внедрившего фантомную зависимость RAT
• Starlette BadHost (CVE-2026-48710, 2026-05-22) — инъекция пути через заголовок Host в Python HTTP-фреймворке → SSRF/RCE, затрагивающая FastAPI, vLLM, LiteLLM и более широкую экосистему ИИ-агентов

Что нового в v4 (2026-05-27)

• Сканирование цепочки поставок Python — scripts/project-scan-py.sh с обнаружением версий через pip-audit / osv-scanner и по CVE-флагам
• Уровень версий с CVE-флагами (L3-CVE) — отслеживание известных уязвимых версий легитимных пакетов со строгой оценкой по semver-спецификации (BadHost CVE-2026-48710 включён из коробки)
• Руководство по гигиене проектирования — MCP-транспорт с приоритетом stdio, дисциплина закрепления версий, усиление роли редактора для GCP default compute SA (см. SKILL.md §D.7 DesignHygiene)
• Интеграция с Devil-линзой Guild-CLI — вызов SCG как Devil-линзы из рабочих процессов guild-cli (см. «Интеграция с Guild-CLI Devil» ниже)

Оглавление

• Зачем это существует
• Чем SCG отличается от существующих инструментов
• Что такое SCG (и чем не является)
• Архитектура
• Быстрый старт
• Режимы сканирования
• Аналитика угроз
• Фреймворк Devil Gate
• Автономные скрипты
• Интеграция с CI/CD
• Плейбук реагирования
• Справочник IOC
• Отказ от ответственности
• Ограничения
• Проверка целостности
• Лицензия

Зачем это существует

31 марта 2026 года широко используемый npm-пакет axios (v1.14.1 и v0.30.4) был скомпрометирован через взлом учётной записи мейнтейнера, приписываемый UNC1069/DPRK-APT (по данным Google Threat Intelligence Group). Атака внедрила фантомную зависимость ([email protected]), которая разворачивала кроссплатформенный RAT через postinstall-скрипты, маскируясь под легитимные системные процессы.

Supply Chain Guard (SCG) был создан во время инцидента для решения следующих задач:

1. Немедленное обнаружение — Затронута ли моя машина или проект прямо сейчас?
2. Структурированная оценка — Насколько это серьёзно? Каков радиус поражения?
3. Управляемое реагирование — Пошаговое устранение последствий с подтверждениями безопасности
4. Постоянная защита — Фреймворк верификации с 8 шлюзами для предотвращения повторения

Чем SCG отличается от существующих инструментов

SCG — не замена существующим инструментам безопасности. Он сочетает несколько уровней обнаружения со структурированным фреймворком верификации и управляемым устранением последствий — предназначен для использования во время активных инцидентов или в качестве периодической проверки наряду с вашими существующими инструментами.

Когда использовать 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 — объединить их в один проход, добавить проверки файловой системы/IOC, которые не делают инструменты реестра, и сделать вывод читабельным и применимым.

3. Документация реальных уроков гигиены проектирования (SKILL.md §D.7) — вещи, с которыми мы действительно сталкивались или которые исследовали: выбор MCP-транспорта, усиление защиты GCP default-SA, векторы выполнения во время установки и угрозы, нацеленные на ИИ-инструменты разработки (Shai-Hulud читает .claude/settings.json, SANDWORM_MODE отравляет MCP-конфиги). Эта ниша — гигиена цепочки поставок для разработки с помощью ИИ — то, где SCG действительно отличается.

Чем SCG намеренно не является

• Не конкурент по охвату. База угроз (SKILL.md D.2, статические списки L3) поддерживается вручную — в ней хранятся инциденты, о которых мы читали, а не десятки тысяч вредоносных пакетов, отслеживаемых живым коммерческим фидом. Ручной курируемый список не может угнаться за реальной скоростью появления новых угроз, и мы не делаем вид, что может.
• Не движок поведенческого анализа. SCG сопоставляет известные паттерны. Обфусцированные полезные нагрузки и настоящие zero-day без публичных уведомлений изначально выходят за рамки.
• Не непрерывный мониторинг. Это проверка на конкретный момент времени, которую вы запускаете во время инцидента или как периодическое сканирование, — а не сервис, следящий за графом зависимостей.

Куда движется SCG

Поскольку курируемая вручную база не может выиграть по охвату, мы намеренно инвестируем туда, где SCG трудно заменить, а не туда, где он всегда будет проигрывать:

• Более глубокие плейбуки реагирования на инциденты (#1) — лучшая эргономика первого ответа, больше шаблонов инцидентов.
• Гигиена сред разработки ИИ (#3) — обнаружение и рекомендации по угрозам, нацеленным на Claude Code / Cursor / MCP-серверы и аналогичные инструменты, которые коммерческие сканеры цепочек поставок в основном не рассматривают.

Статическая база угроз (#2) будет продолжать обновляться при появлении заметных инцидентов, но это явно не то направление, в котором мы пытаемся конкурировать.

Архитектура

SCG следует архитектуре Domain-Driven Design (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

Оба конвейера передают данные в одни и те же SeverityMatrix и Devil Gate Framework.

Быстрый старт

Как навык Claude Code

Скопируйте SKILL.md в каталог навыков Claude Code:```bash

Global (all projects)

cp SKILL.md ~/.claude/skills/supply-chain-guard.md

Or project-specific

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?"

Как автономные скрипты```bash

Environment-wide scan (IOC + all projects) [READ-ONLY]

./scripts/env-scan.sh

npm/yarn project scan (requires package.json in cwd) [READ-ONLY]

./scripts/project-scan.sh

Python project scan (requires pyproject.toml / requirements*.txt / poetry.lock / uv.lock in cwd) [READ-ONLY, added in v4]

./scripts/project-scan-py.sh

IOC-only scan (filesystem + network artifacts) [READ-ONLY]

./scripts/ioc-scan.sh

Remediation (interactive, every action requires confirmation)

./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)

> **Исправление для Python консервативно по замыслу.** Для npm `--high` применяет
> переопределение автоматически. Для Python оно *направляет*: оно определяет ваш менеджер
> (pip/poetry/uv), выводит точную команду фиксации и применяет только безопасный шаг —
> команды, изменяющие lockfile и пересобирающие venv, отображаются для самостоятельного запуска. Это позволяет избежать
> ложного срабатывания, вызывающего принудительную переустановку побочного кода в раздробленной экосистеме упаковки Python.

Для полинглот-репозитория (npm + Python) запускайте оба сканера проектов последовательно из соответствующих подкаталогов.

> **Принцип безопасности:** Все скан-скрипты строго предназначены только для чтения — они никогда ничего не изменяют, не удаляют и не устанавливают. Скрипт исправления (`respond.sh`) — единственный скрипт, выполняющий деструктивные операции, и **каждое отдельное действие требует явного подтверждения `[y/N]`** со значением по умолчанию NO.

---

## Режимы сканирования

### Сканирование окружения (`env_scan`)

Сканирует всю вашу машину разработки на наличие индикаторов компрометации.

| Проверка | Описание |
|-------|-------------|
| **IOC: Filesystem** | Бинарные файлы RAT, механизмы персистентности, staging-файлы |
| **IOC: Network** | Активные соединения с C2 (IP + домен) |
| **IOC: Process** | Выполняющиеся вредоносные процессы |
| **Cross-project** | Все файлы `package-lock.json` сканируются на скомпрометированные версии |
| **Malicious packages** | Известные вредоносные имена пакетов в любом lockfile |

**Триггеры:** «этот ПК», «проверка окружения», «в масштабе всей машины»

### Сканирование проекта — npm/yarn (`project_scan`)

Глубокое сканирование одного npm/yarn проекта. Выполняется из каталога, содержащего `package.json`.

| Уровень | Сканер | Описание |
|-------|---------|-------------|
| **L1** | `npm audit` | Известные уязвимости через реестр npm |
| **L2** | `osv-scanner` / OSV.dev API | База данных открытых уязвимостей Google |
| **L3** | Статический список | Проверка по жестко заданному списку известных вредоносных пакетов |
| **IOC** | Файловая система + сеть | Обнаружение артефактов RAT |
| **LF** | Целостность lockfile | `npm ci --dry-run` + количество хешей целостности |

**Триггеры:** «этот проект», «npm audit» или наличие `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 и объявлениям в стиле requirements (см. [PR #4](https://github.com/eris-ths/supply-chain-guard/pull/4)). Ошибка при совпадении |
| **L3-CVE** | Статический список версий с CVE (`_L3_CVE_LIST`) | Известные уязвимые версии легитимных пакетов (например, `starlette<1.0.1` для [BadHost CVE-2026-48710](https://cryptobriefing.com/starlette-badhost-vulnerability-ai-agents/)). Строгая оценка semver-спецификации через библиотеку `packaging` в Python. Ошибка при подтверждённом совпадении. Предупреждает, если пакет объявлен, но lockfile отсутствует (невозможно оценить версию) |
| **IOC** | Файловая система + процесс | Проверка артефактов в стиле Python (вредоносные скрипты, подозрительные процессы) |
| **LF** | Целостность lockfile | Проверяет, что `uv.lock` / `poetry.lock` / `requirements*.txt` корректно разбираются и содержат зафиксированные версии |

**Триггеры:** «этот проект» при наличии Python-файлов или любой из `pyproject.toml` / `requirements*.txt` / `poetry.lock` / `uv.lock` в текущем каталоге

> **Примечание о зависимостях:** L1 (`pip-audit`) и L2 (`osv-scanner`) корректно пропускаются с подсказкой, когда соответствующий CLI отсутствует. L3 — это постоянно активный слой, не требующий внешних инструментов, но точная оценка L3-CVE требует `pip install packaging`.

---

## Аналитика угроз

### База известных угроз

| ID | Дата | Пакет | Злоумышленник | Вектор |
|----|------|---------|-------------|--------|
| **T001** | 2026-03-31 | `[email protected]`, `[email protected]` | UNC1069/DPRK-APT | Компрометация мейнтейнера → фантомная зависимость → RAT |
| **T002** | 2018-11 | `[email protected]` | Неизвестен | Внедрение зависимости → кража криптовалюты |
| **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

Безопасные версии

Идентификаторы бюллетеней

• GHSA-fw8c-xr5c-95f9
• MAL-2026-2306

Фреймворк Devil Gate

SCG использует 8-шлюзовый фреймворк верификации, организованный в 4 категории и исполняемый как последовательная цепочка с циклом сходимости.

Шлюзы

Выполнение цепочки```

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** | Используется скомпрометированная версия | Зафиксировать безопасную версию → Переопределить → `npm ci` → Проверить |
| **MEDIUM** | Подозрительный postinstall-скрипт | Ручная проверка → Добавить в белый список или удалить |
| **LOW** | Расхождение lockfile | Ресинхронизация `npm ci` |
| **CLEAR** | Все проверки пройдены | Действия не требуются |

> **Безопасность:** ответы CRITICAL/HIGH связаны с разрушительными операциями. SCG всегда представляет результаты и запрашивает явное подтверждение пользователя перед выполнением исправлений.

---

## Автономные скрипты

### `scripts/env-scan.sh`

Полное сканирование окружения. Проверяет IOC-артефакты, сканирует все lockfile-файлы в `$HOME` (настраивается) и сообщает о скомпрометированных пакетах.```bash
./scripts/env-scan.sh [scan_root_dir]
# Default: $HOME

scripts/project-scan.sh

Сканирование на уровне проекта. Запускается из каталога, содержащего package.json.```bash cd my-project /path/to/scripts/project-scan.sh

### `scripts/ioc-scan.sh`

Сканирование только по IOC. Проверяет артефакты файловой системы, запущенные процессы и сетевые соединения на соответствие известным индикаторам C2. Кроссплатформенный (macOS/Linux/Windows через PowerShell).```bash
./scripts/ioc-scan.sh

scripts/respond.sh

Интерактивное устранение проблем. Каждое разрушительное действие требует подтверждения [y/N] (по умолчанию: NO).```bash

CRITICAL: Full RAT cleanup (kill → remove → reinstall)

./scripts/respond.sh --critical

HIGH: Pin compromised package to safe 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. Сетевая изоляция (блокировка C2-домена через `/etc/hosts`)
2. Завершение процессов RAT
3. Удаление персистентности (LaunchAgents / crontab / запланированные задачи)
4. Удаление `node_modules` и lockfile, очистка кэша npm
   - **4b (Python):** очистка кэша pip (безопасно, автоматически); пересборка venv показана как ручные шаги
5. Переустановка зависимостей
6. Запрос проверочного сканирования (`project-scan.sh` и/или `project-scan-py.sh`)

Каждый шаг проверяет, действительно ли действие необходимо (например, пропускает «kill», если процесс RAT не запущен), и показывает, что именно будет выполнено, прежде чем запрашивать подтверждение.

В режиме **HIGH** npm применяет override автоматически; Python управляется пошагово (обнаружить менеджер пакетов → вывести команду закрепления версии → применить только безопасный шаг). См. примечание по устранению проблемы Python в [Быстрый старт](#quick-start).

---

## Интеграция с CI/CD

### GitHub Actions```yaml
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

Рекомендации по укреплению безопасности```bash

Always use in CI:

npm ci --ignore-scripts # Block postinstall execution

npm ci already enforces lockfile integrity by design (errors on mismatch)

Yarn equivalent:

yarn install --frozen-lockfile --ignore-scripts

> **Закрепляйте actions по SHA, а не по тегу.** В примере выше используется `actions/checkout@v4` для читаемости, но теги могут быть перемещены. В production закрепляйте полный SHA коммита, чтобы предотвратить атаки на цепочку поставок actions:
> ```yaml
> - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
> - uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af  # v4.1.0
> ```

---

## Плейбук реагирования

### Если CRITICAL (обнаружен RAT)

> **Не паникуйте.** Выполняйте эти шаги по порядку. Каждый шаг требует вашего явного подтверждения.

1. **Сетевая изоляция** — заблокируйте домен C2 через `/etc/hosts`
2. **Завершение процессов** — завершите процессы RAT (`com.apple.act.mond`, `ld.py`, `wt.exe`)
3. **Удаление персистентности** — удалите LaunchAgents, crontabs и запланированные задачи
4. **Очистка npm** — удалите `node_modules` и `package-lock.json`, очистите кэш npm
5. **Переустановка** — выполните чистую установку: `npm install && npm ci`
6. **Повторное сканирование** — повторно запустите полный пайплайн, ожидайте CLEAR

### Если HIGH (установлена скомпрометированная версия)

1. **Зафиксируйте безопасную версию** с помощью respond.sh:   ```bash
   ./scripts/respond.sh --high axios 1.14.0

Это добавляет overrides (npm) или resolutions (yarn) в package.json, переустанавливает зависимости и запрашивает подтверждение.

2. Или вручную в package.json: ```json { "overrides": { "axios": "1.14.0" } }
   root@kitploit:~

Yarn: { "resolutions": { "axios": "1.14.0" } }

3. Переустановите: npm ci
4. Проверка: Повторно запустите сканирование

Справочник IOC

Артефакты файловой системы

Механизмы персистентности

Сетевые индикаторы

Техники маскировки

Формат вывода```

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 ───────────────────────────────────────

---

## References

| Источник | Описание |
|--------|-------------|
| [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/) | Руководство для CISO с хронологией IOC |
| [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) | **Основной** — совет безопасности GitHub для `Kludex/starlette` (опубликовано 2026-05-21): «Отсутствие проверки заголовка Host отравляет request.url.path, обходя проверки безопасности на основе пути» |
| [Starlette v1.0.1 release notes](https://github.com/Kludex/starlette/releases/tag/1.0.1) | **Основной** — исправляющий релиз (опубликовано 2026-05-21). Закрепите `starlette>=1.0.1` (и `fastapi>=0.119` для транзитивного разрешения) |
| [Starlette BadHost coverage (KuCoin)](https://kucoin.com/news/flash/starlette-vulnerability-exposes-millions-of-ai-agents-to-hackers) | Вторичный — влияние на экосистему Python, акцент на AI-агентах |
| [BadHost AI agent analysis (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 может вызываться как одна из security-линз во время прохода ревью.

### Рекомендуемая схема вызова```bash
# Inside a guild-cli review session, in the project root:
~/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

# Capture the scan output as evidence for a judgment:
SCG_OUTPUT=$(~/path/to/supply-chain-guard/scripts/project-scan.sh 2>&1 || true)

# (a) Record it as a new judgment (fast-track — no prior review needed):
gate fast-track --from "$USER" \
  --action "SCG supply-chain scan (Devil lense)" \
  --reason "$SCG_OUTPUT"

# (b) Or attach it as the Devil lense on an existing review request <id>:
gate review <id> --lense devil --verdict concern --note "$SCG_OUTPUT"

Примечания по флагам (сверено с guild-cli): gate review требует существующий <id>, --lense (в guild-cli пишется как "lense") и --verdict (ok / concern / reject). У него нет флага --area. Чтобы зарегистрировать новую находку без предшествующего объекта ревью, используйте gate fast-track, как в (a).

Зачем сочетать SCG с Devil

Devil's Advocate («壊しにいく») и SCG придерживаются одной и той же позиции: предполагай худшее, сканируй систематически, затем своди результаты. SCG добавляет к проходу Devil измерение цепочки поставок — то, что зависимости проекта могут делать за вашей спиной, — наряду с другими линзами (безопасность / корректность / архитектура / пользователь / эксплуатация).

Ограничения сочетания с Devil

• SCG работает в режиме только для чтения; линза Devil не будет вносить исправления. Используйте respond.sh отдельно, когда требуется устранение проблем (с явным подтверждением пользователя)
• Вывод SCG может превысить бюджет контекста Devil в больших репозиториях; при необходимости пропустите через tail -50
• Для полиглотных репозиториев запускайте оба скрипта project-scan.sh и project-scan-py.sh и объединяйте находки

Отказ от ответственности

SCG — это инструмент обнаружения, а не гарантия безопасности. Честно говорить о том, что он может и не может делать, — часть дизайна.

Данное программное обеспечение предоставляется «как есть» без каких-либо гарантий. Используя Supply Chain Guard, вы подтверждаете и соглашаетесь со следующим:

• Не заменяет профессиональную безопасность. SCG — это дополнительный инструмент обнаружения, а не комплексное решение по безопасности. Он не заменяет профессиональное реагирование на инциденты, программное обеспечение для обнаружения и реагирования на конечных точках (EDR) или аудиты безопасности.
• Нет гарантии обнаружения. Вердикт CLEAR означает, что совпадений с известными шаблонами угроз инструмента не найдено. Это не означает, что ваша система или проект свободны от компрометации. Новые, неизвестные или модифицированные атаки могут быть не обнаружены.
• Нет гарантии устранения. Предоставленные шаги по устранению (respond.sh) нацелены на известные индикаторы конкретных угроз. Они могут не полностью удалить все следы сложной компрометации. Если вы подозреваете активную компрометацию, привлеките профессиональную команду реагирования на инциденты.
• Использование на свой страх и риск. Авторы не несут ответственности за любой ущерб, потерю данных или инциденты безопасности, возникшие в результате использования или невозможности использования этого инструмента. Это включает, помимо прочего: ложные отрицательные результаты (пропущенные обнаружения), ложные срабатывания (ошибочные обнаружения) или непредвиденные последствия запуска скриптов устранения.
• Не является юридической консультацией или консультацией по комплаенсу. Этот инструмент не удовлетворяет регуляторным, комплаенс- или юридическим требованиям к сканированию безопасности. Для потребностей комплаенса обращайтесь к соответствующим специалистам.

Ограничения

Понимать, что SCG не может делать, так же важно, как знать, что он может.

Границы обнаружения

Актуальность базы угроз

База данных Known Threats (D.2 в SKILL.md) поддерживается вручную. Она не подключена к живой ленте угроз. Существует неизбежная задержка между обнаружением нового инцидента в цепочке поставок и обновлением этой базы.

• Последнее обновление: 2026-05-27 (v4: поддержка Python, добавлен BadHost CVE-2026-48710)
• Покрытие: 3 семейства угроз npm (T001-T003) + 4 записи о взломанных/тайпсквот-пакетах Python + 1 запись версии Python, отмеченной CVE (BadHost)
• Область покрытия Python (v4): в первую очередь сканирование на основе lockfile-файлов (uv.lock / poetry.lock / requirements.txt). Слой версий, отмеченных CVE, работает по принципу best-effort — он помечает только те пакеты, которые соответствуют записям _L3_CVE_LIST со строгой оценкой semver-спецификаций, и зависит от установленного пакета packaging для точного сопоставления версий

Всегда сверяйтесь с живыми источниками, такими как npm advisories, OSV.dev и блоги по безопасности вендоров, перечисленные в разделе Ссылки.

Риск ложных срабатываний

Следующие пути IOC в редких случаях могут конфликтовать с легитимным программным обеспечением:

Всегда проверяйте находки IOC перед запуском устранения. Скрипт ioc-scan.sh сообщает находки для проверки человеком — он не предпринимает никаких действий. Скрипт respond.sh требует явного подтверждения каждого разрушительного действия (по умолчанию: NO) именно из-за этого риска.

Ограничения сканирования сети

• Сетевые проверки на основе lsof обнаруживают только активные в данный момент соединения. C2-маяк, подключающийся с перерывами, может быть неактивен на момент сканирования.
• Проверки кэша DNS выполняются по принципу best-effort и зависят от ОС. Очищенные кэши не покажут исторических соединений.
• Зашифрованный или туннелированный трафик 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

<!-- CHECKSUMS-END -->

Для проверки:```bash
shasum -a 256 scripts/*.sh scripts/*.ps1 SKILL.md

Примечание: Эти контрольные суммы соответствуют последнему релизу. Если вы локально изменили какие-либо файлы, контрольные суммы будут отличаться. Когда SCG обновляется, этот раздел обновляется вместе с изменениями кода.

Лицензия

MIT

Создано Eris — потому что ваши зависимости не должны быть чьей-то чужой поверхностью атаки.