Supply Chain Guard (SCG)

Un kit de herramientas de respuesta a incidentes para ataques a la cadena de suministro de npm/yarn y Python (pip/poetry/uv) — gratuito, local, sin dependencias.

SCG no es un motor de escaneo que compite con herramientas comerciales en cobertura. Es una habilidad de Claude Code y un kit de herramientas de shell independiente que hace tres cosas bien: (1) te proporciona una primera respuesta rápida y repetible cuando ocurre un incidente específico ("¿mi máquina está afectada ahora mismo?"), (2) orquesta escáneres OSS existentes (npm audit, osv-scanner, pip-audit) en un único pase estructurado, y (3) documenta lecciones de higiene de diseño ganadas con esfuerzo — especialmente para entornos de desarrollo con IA — que los escáneres genéricos no cubren.

Fue construido y endurecido durante incidentes reales, incluyendo:

• Incidente RAT de [email protected] (2026-03-31) — toma de control de cuenta de mantenedor de npm (UNC1069/DPRK-APT) inyectando una dependencia fantasma RAT
• Starlette BadHost (CVE-2026-48710, 2026-05-22) — inyección de ruta en la cabecera Host del framework HTTP de Python → SSRF/RCE, afectando a FastAPI, vLLM, LiteLLM y al ecosistema más amplio de agentes de IA.

Novedades en v4 (2026-05-27)

• Escaneo de cadena de suministro de Python — scripts/project-scan-py.sh con pip-audit / osv-scanner / detección de versiones marcadas con CVE
• Capa de versiones marcadas con CVE (L3-CVE) — rastreo de versiones vulnerables conocidas de paquetes legítimos con evaluación estricta de especificación semver (BadHost CVE-2026-48710 incluido de serie)
• Guía de higiene de diseño — transporte MCP con stdio como prioridad, disciplina de fijación de versiones, endurecimiento del editor SA de computación predeterminado de GCP (ver SKILL.md §D.7 DesignHygiene)
• Integración con lente Devil de Guild-CLI — invocar SCG como lente Devil desde flujos de trabajo de guild-cli (ver "Integración con Devil de Guild-CLI" más abajo)

Tabla de contenidos

• Por qué existe esto
• Cómo SCG se diferencia de las herramientas existentes
• Qué es SCG (y qué no es)
• Arquitectura
• Inicio rápido
• Modos de escaneo
• Inteligencia de amenazas
• Marco Devil Gate
• Scripts independientes
• Integración CI/CD
• Manual de respuesta
• Referencia de IOC
• Aviso legal
• Limitaciones
• Verificación de integridad
• Licencia

Por qué existe esto

El 31 de marzo de 2026, el paquete npm de uso extendido axios (v1.14.1 y v0.30.4) fue comprometido mediante una toma de control de la cuenta de mantenedor atribuida a UNC1069/DPRK-APT (según Google Threat Intelligence Group). El ataque inyectó una dependencia fantasma ([email protected]) que desplegó un RAT multiplataforma a través de scripts postinstall, disfrazado de procesos legítimos del sistema.

Supply Chain Guard (SCG) fue construido durante el incidente para proporcionar:

1. Detección inmediata — ¿Mi máquina o proyecto está afectado ahora mismo?
2. Evaluación estructurada — ¿Qué tan grave es? ¿Cuál es el radio de explosión?
3. Respuesta guiada — Remedio paso a paso con confirmaciones de seguridad
4. Defensa continua — Un marco de verificación de 8 puertas para prevenir recurrencias

Cómo SCG se diferencia de las herramientas existentes

SCG no reemplaza a las herramientas de seguridad existentes. Combina múltiples capas de detección con un marco de verificación estructurado y remedio guiado — diseñado para su uso durante incidentes activos o como una verificación periódica junto con sus herramientas existentes.

Cuándo usar SCG:

• Acaba de ocurrir un incidente en la cadena de suministro y necesita verificar sus máquinas y proyectos ahora mismo
• Desea un proceso estructurado y repetible para verificar que un compromiso ha sido completamente abordado
• Necesita una verificación ligera que se ejecute localmente sin dependencias SaaS

Cuándo usar otra cosa:

• Necesita monitoreo continuo en tiempo real → Snyk, Socket.dev
• Necesita escaneo de cumplimiento de licencias → Snyk, FOSSA
• Necesita cobertura más allá de npm/yarn → osv-scanner (soporta pip, cargo, go, etc.)

Qué es SCG (y qué no es)

Preferimos ser honestos sobre los límites que sobrevender. SCG es tres cosas:

1. Un manual de respuesta a incidentes, como código. Cuando ocurre un incidente con nombre (axios RAT, Shai-Hulud, un CVE nuevo), SCG convierte "¿estoy afectado y, si es así, qué hago?" en una lista de verificación ejecutable — 8 puertas de verificación, una matriz de gravedad y un script de remedio donde cada acción destructiva necesita confirmación explícita [y/N]. Este es su valor principal: la primera respuesta rápida y estructurada para la que las herramientas de monitoreo comerciales no están diseñadas.

2. Un orquestador de escáneres OSS existentes. Las capas L1/L2 envuelven npm audit / pip-audit / osv-scanner. La mayor parte del poder de detección en bruto es prestado; la contribución de SCG es agruparlos en un solo pase, añadiendo verificaciones de sistema de archivos/IOC que las herramientas de registro no hacen, y haciendo la salida legible y procesable.

3. Documentación de lecciones reales de higiene de diseño (SKILL.md §D.7) — cosas que realmente encontramos o investigamos: elección de transporte MCP, endurecimiento de SA predeterminado de GCP, vectores de ejecución en tiempo de instalación y amenazas que apuntan a herramientas de desarrollo de IA (Shai-Hulud leyendo .claude/settings.json, SANDWORM_MODE envenenando configuraciones MCP). Este nicho — higiene de la cadena de suministro para el desarrollo asistido por IA — es donde SCG está genuinamente diferenciado.

Lo que SCG deliberadamente NO es

• No es un competidor de cobertura. La base de datos de amenazas (SKILL.md D.2, las listas estáticas L3) se mantiene manualmente — contiene los incidentes de los que hemos leído, no las decenas de miles de paquetes maliciosos que rastrea un feed comercial en vivo. Una lista curada manualmente no puede mantenerse al ritmo real de nuevas amenazas, y no pretendemos que lo haga.
• No es un motor de análisis de comportamiento. SCG coincide con patrones conocidos. Las cargas útiles ofuscadas y los verdaderos días cero sin aviso público están fuera del alcance por construcción.
• No es monitoreo continuo. Es una verificación puntual que se ejecuta durante un incidente o como un barrido periódico — no un servicio que observa su gráfico de dependencias.

Hacia dónde se dirige SCG

Debido a que una base de datos curada manualmente no puede ganar en cobertura, estamos invirtiendo intencionalmente donde SCG es difícil de reemplazar en lugar de donde siempre perderá:

• Manuales de respuesta a incidentes más profundos (#1) — mejor ergonomía de primera respuesta, más plantillas de incidentes.
• Higiene del entorno de desarrollo de IA (#3) — detección y orientación para amenazas dirigidas a servidores Claude Code / Cursor / MCP y herramientas similares, que los escáneres comerciales de cadena de suministro en gran medida no abordan.

La base de datos de amenazas estática (#2) seguirá actualizándose cuando ocurran incidentes notables, pero explícitamente no es la dirección en la que intentamos competir.

Arquitectura

SCG sigue una arquitectura Domain-Driven Design (DDD) con tres capas:``` +-----------------------------------------------------+ | 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) | +-----------------------------------------------------+

### Pipeline de Escaneo

El mismo pipeline de 5 capas se aplica a ambos ecosistemas con escáneres específicos del ecosistema en cada capa:```
L1 ──→ L2 ──→ L3 ──→ IOC ──→ LF ──→ assess(SeverityMatrix) ──→ VERDICT

Ambos pipelines alimentan la misma SeverityMatrix y Devil Gate Framework.

Inicio rápido

Como una habilidad de Claude Code

Copia SKILL.md en tu directorio de habilidades de 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

Luego invocar en Claude Code:```
> /supply-chain-guard
> "Check this project for supply chain issues"
> "Is my machine affected by the axios compromise?"

Como scripts independientes```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)

> **La corrección en Python es conservadora por diseño.** Para npm, `--high` aplica la anulación automáticamente. Para Python, *guía*: detecta tu gestor (pip/poetry/uv), imprime el comando exacto de fijación de versión, y aplica solo el paso seguro — los comandos de modificación del archivo de bloqueo y reconstrucción del entorno virtual se muestran para que los ejecutes. Esto evita que un falso positivo desencadene una reinstalación forzada colateral en el fragmentado ecosistema de empaquetado de Python.

Para un repositorio políglota (npm + Python), ejecuta ambos escáneres de proyecto secuencialmente desde los subdirectorios correspondientes.

> **Diseño de seguridad:** Todos los scripts de escaneo son estrictamente de solo lectura — nunca modifican, eliminan ni instalan nada. El script de corrección (`respond.sh`) es el único que realiza operaciones destructivas, y **cada acción individual requiere confirmación explícita `[y/N]`** con un valor predeterminado de NO.

---

## Modos de Escaneo

### Escaneo de Entorno (`env_scan`)

Escanea toda tu máquina de desarrollo en busca de indicadores de compromiso.

| Verificación | Descripción |
|-------------|-------------|
| **IOC: Sistema de archivos** | Binarios RAT, mecanismos de persistencia, archivos de preparación |
| **IOC: Red** | Conexiones C2 activas (IP + dominio) |
| **IOC: Proceso** | Procesos maliciosos en ejecución |
| **Entre proyectos** | Todos los archivos `package-lock.json` escaneados en busca de versiones comprometidas |
| **Paquetes maliciosos** | Nombres de paquetes maliciosos conocidos en cualquier archivo de bloqueo |

**Activadores:** "este PC", "verificación de entorno", "en toda la máquina"

### Escaneo de Proyecto — npm/yarn (`project_scan`)

Escaneo profundo de un único proyecto npm/yarn. Ejecutar desde un directorio que contenga `package.json`.

| Capa | Escáner | Descripción |
|------|---------|-------------|
| **L1** | `npm audit` | Vulnerabilidades conocidas a través del registro npm |
| **L2** | `osv-scanner` / API de OSV.dev | Base de datos de vulnerabilidades de código abierto de Google |
| **L3** | Lista estática | Verificación de paquetes maliciosos conocidos codificados |
| **IOC** | Sistema de archivos + Red | Detección de artefactos RAT |
| **LF** | Integridad del archivo de bloqueo | `npm ci --dry-run` + recuento de hash de integridad |

**Activadores:** "este proyecto", "npm audit", o `package.json` presente en el directorio actual

### Escaneo de Proyecto — Python (`project_scan_py`, añadido en v4)

Escaneo profundo de un único proyecto Python. Ejecutar desde un directorio que contenga `pyproject.toml`, `requirements*.txt`, `poetry.lock`, o `uv.lock`.

| Capa | Escáner | Descripción |
|------|---------|-------------|
| **L1** | `pip-audit` | Vulnerabilidades conocidas a través de la Base de Datos de Asesoramiento de PyPI (opcional — SE OMITE si no está instalado; se recomienda `pip install pip-audit`) |
| **L2** | `osv-scanner` | Base de datos de vulnerabilidades de código abierto de Google contra `uv.lock` / `poetry.lock` / `requirements*.txt` (opcional — SE OMITE si no está instalado) |
| **L3-MAL** | Lista estática maliciosa (`_L3_LIST`) | Nombres de paquetes conocidos como secuestrados o typosquat. Coincide con listas PEP 621, Poetry inline y declaraciones estilo requirements (ver [PR #4](https://github.com/eris-ths/supply-chain-guard/pull/4)). FALLA al encontrar coincidencia |
| **L3-CVE** | Lista estática de versiones marcadas con CVE (`_L3_CVE_LIST`) | Versiones conocidas vulnerables de paquetes legítimos (ej., `starlette<1.0.1` para [BadHost CVE-2026-48710](https://cryptobriefing.com/starlette-badhost-vulnerability-ai-agents/)). Evaluación estricta de especificación semver mediante la librería `packaging` de Python. FALLA en coincidencia confirmada. Advierte si un paquete está declarado pero no hay archivo de bloqueo presente (no se puede evaluar la versión) |
| **IOC** | Sistema de archivos + Proceso | Verificación de artefactos específicos de Python (scripts maliciosos, procesos sospechosos) |
| **LF** | Integridad del archivo de bloqueo | Verifica que `uv.lock` / `poetry.lock` / `requirements*.txt` se analice correctamente y contenga versiones fijadas |

**Activadores:** "este proyecto" con archivos Python presentes, o cualquiera de `pyproject.toml` / `requirements*.txt` / `poetry.lock` / `uv.lock` en el directorio actual

> **Nota sobre dependencias:** L1 (`pip-audit`) y L2 (`osv-scanner`) se OMITEN elegantemente con una pista cuando su CLI respectiva está ausente. L3 es la capa siempre activa y no requiere ninguna herramienta externa, pero la evaluación precisa de L3-CVE necesita `pip install packaging`.

---

## Inteligencia de Amenazas

### Base de Datos de Amenazas Conocidas

| ID | Fecha | Paquete | Actor de Amenaza | Vector |
|----|------|---------|-----------------|--------|
| **T001** | 2026-03-31 | `[email protected]`, `[email protected]` | UNC1069/DPRK-APT | Compromiso del mantenedor → dependencia fantasma → RAT |
| **T002** | 2018-11 | `[email protected]` | Desconocido | Inyección de dependencia → robo de criptomonedas |
| **T003** | En curso | `crossenv`, `loadsh`, `crypto-js-esm` | Varios | Typosquatting → exfiltración en postinstall |

### Cadena de Eliminación T001 (RAT axios)```
Credential theft → npm publish (bypass CI) → Inject phantom dep (plain-crypto-js)
    → postinstall exec → RAT drop → C2 beacon (sfrclak.com:8000) → Persist

Versiones Seguras

IDs de Aviso

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

Devil Gate Framework

SCG utiliza un marco de verificación de 8 compuertas organizado en 4 categorías, ejecutado como una cadena serial con bucle de convergencia.

Compuertas

Ejecución en Cadena```

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

### Matriz de Gravedad

| Nivel | Condición | Acción |
|-------|-----------|--------|
| **CRÍTICO** | Artefacto RAT encontrado O paquete malicioso instalado | Aislar red → Matar proceso → Eliminar persistencia → Reinstalar |
| **ALTO** | Versión comprometida en uso | Fijar versión segura → Anular → `npm ci` → Verificar |
| **MEDIO** | Script postinstall sospechoso | Revisión manual → Incluir en lista blanca o eliminar |
| **BAJO** | Desviación del lockfile | Resincronización con `npm ci` |
| **LIMPIO** | Todas las comprobaciones superadas | No se requiere acción |

> **Seguridad:** Las respuestas CRÍTICAS/ALTAS implican operaciones destructivas. SCG siempre presenta los hallazgos y solicita confirmación explícita del usuario antes de ejecutar la remediación.

---

## Scripts Independientes

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

Escaneo completo del entorno. Comprueba artefactos IOC, escanea todos los lockfiles bajo `$HOME` (configurable) e informa paquetes comprometidos.```bash
./scripts/env-scan.sh [scan_root_dir]
# Default: $HOME

scripts/project-scan.sh

Escaneo a nivel de proyecto. Ejecutar desde un directorio que contenga package.json.```bash cd my-project /path/to/scripts/project-scan.sh

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

Escaneo de solo IOC. Comprueba artefactos del sistema de archivos, procesos en ejecución y conexiones de red contra indicadores C2 conocidos. Multiplataforma (macOS/Linux/Windows mediante PowerShell).```bash
./scripts/ioc-scan.sh

scripts/respond.sh

Remediación interactiva. Cada acción destructiva requiere confirmación [y/N] (predeterminado: 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)

Pasos en el modo `--critical`:
1. Aislar la red (bloquear dominio C2 mediante `/etc/hosts`)
2. Matar procesos RAT
3. Eliminar persistencia (LaunchAgents / crontab / tareas programadas)
4. Eliminar `node_modules` y el archivo de bloqueo, limpiar caché de npm
   - **4b (Python):** purgar caché de pip (seguro, automático); reconstrucción de venv mostrada como pasos manuales
5. Reinstalar dependencias
6. Solicitar escaneo de verificación (`project-scan.sh` y/o `project-scan-py.sh`)

Cada paso verifica si la acción es realmente necesaria (por ejemplo, omite "matar" si no hay ningún proceso RAT ejecutándose) y muestra exactamente lo que se ejecutará antes de pedir confirmación.

Para el modo **HIGH**, npm aplica la anulación automáticamente; Python es guiado (detectar gestor → imprimir comando de pin → aplicar solo el paso seguro). Consulte la nota de corrección de Python en [Inicio rápido](#quick-start).

---

## Integración 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

Recomendaciones de hardening```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

> **Fijar acciones por SHA, no por etiqueta.** El ejemplo anterior usa `actions/checkout@v4` para facilitar la lectura, pero las etiquetas pueden ser movidas. En producción, fije a un SHA de commit completo para prevenir ataques a la cadena de suministro de actions:
> ```yaml
> - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
> - uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af  # v4.1.0
> ```

---

## Manual de Respuesta

### Si es CRÍTICO (RAT detectado)

> **No entre en pánico.** Siga estos pasos en orden. Cada paso requiere su confirmación explícita.

1. **Aislamiento de Red** — Bloquee el dominio C2 mediante `/etc/hosts`
2. **Matar Procesos** — Termine los procesos RAT (`com.apple.act.mond`, `ld.py`, `wt.exe`)
3. **Eliminar Persistencia** — Elimine LaunchAgents, crontabs, tareas programadas
4. **Limpiar npm** — Elimine `node_modules` y `package-lock.json`, borre la caché de npm
5. **Reinstalar** — `npm install && npm ci` desde cero
6. **Reescanear** — Vuelva a ejecutar el pipeline completo, espere CLEAR

### Si es ALTO (versión comprometida instalada)

1. **Fije la versión segura** usando respond.sh:   ```bash
   ./scripts/respond.sh --high axios 1.14.0

Esto añade overrides (npm) o resolutions (yarn) a package.json, reinstala y solicita verificación.

2. O manualmente en package.json: ```json { "overrides": { "axios": "1.14.0" } }
   root@kitploit:~

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

3. Reinstalar: npm ci
4. Verificar: Vuelva a ejecutar el escaneo

Referencia de IOC

Artefactos del Sistema de Archivos

Mecanismos de Persistencia

Indicadores de Red

Técnicas de Disfraz

Formato de Salida```

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

---

## Referencias

| Fuente | Descripción |
|--------|-------------|
| [Zenn (JP)](https://zenn.dev/gunta/articles/0152eadf05d173) | Informe temprano en japonés |
| [Elastic Security Labs](https://elastic.co/security-labs/axios-one-rat-to-rule-them-all) | Análisis técnico (desensamblado del RAT, protocolo C2, cronología) |
| [SANS](https://sans.org/blog/axios-npm-supply-chain-compromise-malicious-packages-remote-access-trojan) | Procedimientos IR empresariales |
| [Huntress](https://huntress.com/blog/supply-chain-compromise-axios-npm-package) | Firmas YARA |
| [Elastic Detections](https://elastic.co/security-labs/axios-supply-chain-compromise-detections) | Reglas de detección SIEM (YARA/osquery/KQL) |
| [Semgrep](https://semgrep.dev/blog/2026/axios-supply-chain-incident-indicators-of-compromise-and-how-to-contain-the-threat/) | Reglas de análisis estático, guía de contención |
| [SOCRadar](https://socradar.io/blog/axios-npm-supply-chain-attack-2026-ciso-guide/) | Guía para CISO con cronología de IOC |
| [Wiz](https://wiz.io/blog/axios-npm-compromised-in-supply-chain-attack) | Análisis de impacto en la nube, escaneo de contenedores |
| [NVD CVE-2026-48710](https://nvd.nist.gov/vuln/detail/CVE-2026-48710) | **Primario** — Entrada canónica de NVD (publicada 2026-05-26, CVSS 3.1 base 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) | **Primario** — Aviso de seguridad de GitHub en `Kludex/starlette` (publicado 2026-05-21): "La validación faltante del encabezado Host envenena request.url.path, omitiendo controles de seguridad basados en rutas" |
| [Starlette v1.0.1 release notes](https://github.com/Kludex/starlette/releases/tag/1.0.1) | **Primario** — versión de corrección (publicada 2026-05-21). Fijar `starlette>=1.0.1` (y `fastapi>=0.119` para resolución transitiva) |
| [Starlette BadHost coverage (KuCoin)](https://kucoin.com/news/flash/starlette-vulnerability-exposes-millions-of-ai-agents-to-hackers) | Secundaria — impacto en el ecosistema Python, marco de agentes de IA |
| [BadHost AI agent analysis (CryptoBriefing)](https://cryptobriefing.com/starlette-badhost-vulnerability-ai-agents/) | Secundaria — marco de impacto descendente de FastAPI / vLLM / LiteLLM |

---

## Integración con Guild-CLI Devil

Si usas [guild-cli](https://github.com/eris-ths/guild-cli) (o cualquier proyecto que exponga un flujo de trabajo de lente Devil), SCG puede ser invocado como una de las lentes de seguridad durante una revisión.

### Patrón de invocación recomendado```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"

Flag notes (verified against guild-cli): gate review requires an existing <id>, --lense (guild-cli spells it "lense"), and --verdict (ok / concern / reject). It has no --area flag. To log a fresh finding with no prior review object, use gate fast-track as in (a).

Why pair SCG with Devil

Devil's Advocate ("壊しにいく") and SCG share the same posture: assume the worst, scan systematically, then converge. SCG provides the supply-chain dimension of a Devil pass — what the project's dependencies might be doing behind your back — alongside other lenses (security / correctness / architecture / user / operations).

Limitations of the Devil pairing

• SCG runs read-only; the Devil lense won't push fixes. Use respond.sh separately when remediation is required (with explicit user confirmation)
• SCG output may exceed Devil context budgets in large repos; pipe through tail -50 if needed
• For polyglot repos, run both project-scan.sh and project-scan-py.sh and merge findings

Disclaimer

SCG is a detection tool, not a security guarantee. Being upfront about what it can and cannot do is part of the design.

This software is provided "as-is" without warranty of any kind. By using Supply Chain Guard, you acknowledge and agree to the following:

• Not a substitute for professional security. SCG is a supplementary detection tool, not a comprehensive security solution. It does not replace professional incident response, endpoint detection and response (EDR) software, or security audits.
• No guarantee of detection. A CLEAR verdict means no matches were found against the tool's known threat patterns. It does not mean your system or project is free from compromise. Novel, unknown, or modified attacks may not be detected.
• No guarantee of remediation. The remediation steps provided (respond.sh) address known indicators of specific threats. They may not fully remove all traces of a sophisticated compromise. If you suspect active compromise, engage a professional incident response team.
• Use at your own risk. The authors are not liable for any damages, data loss, or security incidents arising from the use or inability to use this tool. This includes but is not limited to: false negatives (missed detections), false positives (incorrect detections), or unintended consequences of running remediation scripts.
• Not legal or compliance advice. This tool does not satisfy regulatory, compliance, or legal requirements for security scanning. Consult appropriate professionals for compliance needs.

Limitations

Understanding what SCG cannot do is as important as knowing what it can.

Detection Boundaries

Threat Database Freshness

The Known Threats database (D.2 in SKILL.md) is manually maintained. It is not connected to any live threat feed. There is inherent latency between a new supply chain incident being discovered and this database being updated.

• Last updated: 2026-05-27 (v4: Python support, BadHost CVE-2026-48710 added)
• Coverage: 3 npm threat families (T001-T003) + 4 Python hijacked/typosquat entries + 1 Python CVE-flagged version entry (BadHost)
• Python coverage scope (v4): primarily lockfile-based scanning (uv.lock / poetry.lock / requirements.txt). The CVE-flagged version layer is best-effort — it only flags packages that match _L3_CVE_LIST entries with strict semver-spec evaluation, and depends on packaging being installed for accurate version matching

Always cross-reference with live sources such as npm advisories, OSV.dev, and vendor security blogs listed in the References section.

False Positive Risk

The following IOC paths may, in rare cases, conflict with legitimate software:

Always verify IOC findings before running remediation. The ioc-scan.sh script reports findings for human review — it does not take any action. The respond.sh script requires explicit confirmation for every destructive action (default: NO) precisely because of this risk.

Network Scanning Limitations

• lsof-based network checks only detect currently active connections. A C2 beacon that connects intermittently may not be active at scan time.
• DNS cache checks are best-effort and OS-dependent. Cleared caches will not show historical connections.
• Encrypted or tunneled C2 traffic cannot be detected by port/IP matching alone.

Scope

• npm/yarn and Python (pip/poetry/uv). Does not cover cargo, go modules, or other package ecosystems.
• Known threats only. This is a pattern-matching tool, not a behavioral analysis engine.
• Point-in-time scan. Results reflect the state at the moment of execution. Continuous monitoring requires repeated execution or integration with CI/CD.

Integrity Verification

Verify that your copy of SCG has not been tampered with. Compare these SHA-256 checksums against your local files:

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

Para verificar:```bash
shasum -a 256 scripts/*.sh scripts/*.ps1 SKILL.md

Nota: Estas sumas de verificación corresponden a la última versión. Si has modificado archivos localmente, las sumas de verificación serán diferentes. Cuando SCG se actualiza, esta sección se actualiza junto con los cambios de código.

Licencia

MIT

Creado por Eris — porque tus dependencias no deberían ser la superficie de ataque de nadie más.