Supply Chain Guard (SCG)

Un toolkit di risposta agli incidenti per attacchi alla supply chain di npm/yarn e Python (pip/poetry/uv) — gratuito, locale, senza dipendenze.

SCG non è un motore di scansione che compete con gli strumenti commerciali in termini di copertura. È una skill per Claude Code e un toolkit shell standalone che fa bene tre cose: (1) fornisce una prima risposta rapida e ripetibile quando viene divulgato un incidente specifico ("la mia macchina è colpita in questo momento?"), (2) orchestra gli scanner OSS esistenti (npm audit, osv-scanner, pip-audit) in un unico passaggio strutturato e (3) documenta le lezioni di design-hygiene conquistate sul campo — soprattutto per gli ambienti di sviluppo AI — che gli scanner generici non coprono.

È stato costruito e temprato durante incidenti reali, tra cui:

• Incidente RAT [email protected] (2026-03-31) — furto dell'account di un maintainer npm (UNC1069/DPRK-APT) che ha iniettato una RAT tramite una dipendenza fantasma
• Starlette BadHost (CVE-2026-48710, 2026-05-22) — iniezione del percorso nell'header Host del framework HTTP Python → SSRF/RCE, che colpisce FastAPI, vLLM, LiteLLM e il più ampio ecosistema di agenti AI

Novità della v4 (2026-05-27)

• Scansione della supply chain Python — scripts/project-scan-py.sh con pip-audit / osv-scanner / rilevamento di versioni segnalate CVE
• Livello versioni segnalate CVE (L3-CVE) — tiene traccia delle versioni note vulnerabili di pacchetti legittimi con valutazione rigorosa della specifica semver (BadHost CVE-2026-48710 incluso di serie)
• Linea guida di igiene progettuale — trasporto MCP stdio-first, disciplina del version pin, hardening del ruolo editor dell'account di servizio di calcolo predefinito di GCP (vedi SKILL.md §D.7 DesignHygiene)
• Integrazione Devil lense di Guild-CLI — invoca SCG come Devil lense dai flussi di lavoro guild-cli (vedi "Integrazione Devil di Guild-CLI" più sotto)

Indice

• Perché esiste
• Come SCG si differenzia dagli strumenti esistenti
• Cos'è SCG (e non è)
• Architettura
• Avvio rapido
• Modalità di scansione
• Intelligence sulle minacce
• Devil Gate Framework
• Script autonomi
• Integrazione CI/CD
• Playbook di risposta
• Riferimento IOC
• Disclaimer
• Limitazioni
• Verifica dell'integrità
• Licenza

Perché esiste

Il 31 marzo 2026, il pacchetto npm axios, ampiamente utilizzato (v1.14.1 e v0.30.4), è stato compromesso tramite il furto dell'account di un maintainer, attribuito a UNC1069/DPRK-APT (secondo Google Threat Intelligence Group). L'attacco ha iniettato una dipendenza fantasma ([email protected]) che ha distribuito un RAT multipiattaforma tramite script postinstall, mascherato da processi di sistema legittimi.

Supply Chain Guard (SCG) è stato costruito durante l'incidente per fornire:

1. Rilevamento immediato — La mia macchina o il mio progetto è colpito in questo momento?
2. Valutazione strutturata — Quanto è grave? Qual è il blast radius?
3. Risposta guidata — Bonifica passo-passo con conferme di sicurezza
4. Difesa continua — Un framework di verifica a 8 gate per prevenire il ripetersi

Come SCG si differenzia dagli strumenti esistenti

SCG non sostituisce gli strumenti di sicurezza esistenti. Combina più livelli di rilevamento con un framework di verifica strutturato e una bonifica guidata — pensato per l'uso durante incidenti attivi o come controllo periodico accanto ai tuoi strumenti esistenti.

Quando usare SCG:

• È appena stato divulgato un incidente sulla supply chain e devi controllare macchine e progetti subito
• Vuoi un processo strutturato e ripetibile per verificare che una compromissione sia stata completamente risolta
• Hai bisogno di un controllo leggero che venga eseguito localmente senza dipendenze SaaS

Quando usare qualcos'altro:

• Ti serve un monitoraggio continuo in tempo reale → Snyk, Socket.dev
• Ti serve la scansione della conformità delle licenze → Snyk, FOSSA
• Ti serve una copertura oltre npm/yarn → osv-scanner (supporta pip, cargo, go, ecc.)

Cos'è SCG (e non è)

Preferiamo essere onesti sui confini piuttosto che esagerare. SCG è tre cose:

1. Un playbook di risposta agli incidenti, come codice. Quando viene divulgato un incidente specifico (axios RAT, Shai-Hulud, una nuova CVE), SCG trasforma "sono colpito? e se sì, cosa faccio?" in una checklist eseguibile — 8 gate di verifica, una matrice di gravità e uno script di bonifica in cui ogni azione distruttiva richiede una conferma esplicita [y/N]. Questo è il suo valore principale: la prima risposta rapida e strutturata che gli strumenti di monitoraggio commerciali non sono pensati per fornire.

2. Un orchestratore degli scanner OSS esistenti. I livelli L1/L2 incapsulano npm audit / pip-audit / osv-scanner. Gran parte della potenza grezza di rilevamento è presa in prestito; il contributo di SCG è raggrupparli in un unico passaggio, aggiungere controlli filesystem/IOC che gli strumenti basati sui registry non fanno e rendere l'output leggibile e utilizzabile.

3. Documentazione di lezioni reali di design-hygiene (SKILL.md §D.7) — cose che abbiamo effettivamente incontrato o investigato: scelta del trasporto MCP, hardening dell'account di servizio predefinito di GCP, vettori di esecuzione in fase di installazione e minacce mirate agli strumenti di sviluppo AI (Shai-Hulud che legge .claude/settings.json, SANDWORM_MODE che avvelena le configurazioni MCP). Questa nicchia — igiene della supply chain per lo sviluppo assistito da AI — è dove SCG è davvero differenziato.

Cosa SCG deliberatamente non è

• Non è un concorrente sulla copertura. Il database delle minacce (SKILL.md D.2, le liste statiche L3) è mantenuto a mano — contiene gli incidenti di cui abbiamo letto, non le decine di migliaia di pacchetti malintenzionati tracciati da un feed commerciale in tempo reale. Una lista curata a mano non può stare al passo con il ritmo reale delle nuove minacce, e non fingiamo che lo faccia.
• Non è un motore di analisi comportamentale. SCG riconosce pattern noti. Payload offuscati e veri zero-day senza advisory pubblico sono fuori ambito per costruzione.
• Non è un monitoraggio continuo. È un controllo point-in-time che esegui durante un incidente o come scansione periodica — non un servizio che osserva il tuo grafo delle dipendenze.

Dove si dirige SCG

Poiché un database curato a mano non può vincere sulla copertura, stiamo investendo intenzionalmente dove SCG è difficile da sostituire piuttosto che dove perderà sempre:

• Playbook di risposta agli incidenti più approfonditi (#1) — migliore ergonomia della prima risposta, più template di incidente.
• Igiene degli ambienti di sviluppo AI (#3) — rilevamento e indicazioni per minacce mirate a Claude Code / Cursor / server MCP e strumenti simili, che gli scanner commerciali della supply chain in gran parte non affrontano.

Il database statico delle minacce (#2) continuerà a essere aggiornato quando si verificheranno incidenti importanti, ma esplicitamente non è la direzione su cui cerchiamo di competere.

Architettura

SCG segue un'architettura Domain-Driven Design (DDD) con tre livelli:``` +-----------------------------------------------------+ | 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 di scansione

La stessa pipeline a 5 livelli si applica a entrambi gli ecosistemi con scanner specifici per ecosistema a ogni livello:```
L1 ──→ L2 ──→ L3 ──→ IOC ──→ LF ──→ assess(SeverityMatrix) ──→ VERDICT

Entrambe le pipeline alimentano la stessa SeverityMatrix e il Devil Gate Framework.

Avvio rapido

Come skill di Claude Code

Copia SKILL.md nella directory delle skill di 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

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

Come Script Standalone```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 remediation Python è conservativa per design.** Per npm, `--high` applica la
> sostituzione automaticamente. Per Python *guida*: rileva il tuo gestore
> (pip/poetry/uv), stampa il comando di pin esatto e applica solo il passaggio sicuro —
> i comandi che modificano il lockfile e ricostruiscono il venv vengono mostrati per farti eseguire. Questo evita
> che un falso positivo inneschi una reinstallazione forzata collaterale nell'ecosistema frammentato
> del packaging Python.

Per un repository poliglotta (npm + Python), esegui entrambi gli scanner di progetto in sequenza dalle rispettive sottodirectory.

> **Design di sicurezza:** Tutti gli script di scansione sono strettamente di sola lettura — non modificano, eliminano o installano mai nulla. Lo script di remediation (`respond.sh`) è l'unico script che esegue operazioni distruttive, e **ogni singola azione richiede una conferma esplicita `[y/N]`** con default NO.

---

## Modalità di Scansione

### Scansione dell'ambiente (`env_scan`)

Scansiona l'intera macchina di sviluppo alla ricerca di indicatori di compromissione.

| Controllo | Descrizione |
|-------|-------------|
| **IOC: Filesystem** | Binari RAT, meccanismi di persistenza, file di staging |
| **IOC: Network** | Connessioni C2 attive (IP + dominio) |
| **IOC: Process** | Processi dannosi in esecuzione |
| **Tra progetti** | Tutti i file `package-lock.json` scansionati per versioni compromesse |
| **Pacchetti dannosi** | Nomi di pacchetti dannosi noti in qualsiasi lockfile |

**Trigger:** "this PC", "environment check", "machine-wide"

### Scansione del progetto — npm/yarn (`project_scan`)

Scansione approfondita di un singolo progetto npm/yarn. Eseguire da una directory contenente `package.json`.

| Livello | Scanner | Descrizione |
|-------|---------|-------------|
| **L1** | `npm audit` | Vulnerabilità note tramite il registro npm |
| **L2** | `osv-scanner` / OSV.dev API | Database di vulnerabilità open source di Google |
| **L3** | Lista statica | Controllo hardcoded dei pacchetti noti come dannosi |
| **IOC** | Filesystem + Network | Rilevamento di artefatti RAT |
| **LF** | Integrità del lockfile | `npm ci --dry-run` + conteggio hash di integrità |

**Trigger:** "this project", "npm audit" o `package.json` presente nella cwd

### Scansione del progetto — Python (`project_scan_py`, aggiunto nella v4)

Scansione approfondita di un singolo progetto Python. Eseguire da una directory contenente `pyproject.toml`, `requirements*.txt`, `poetry.lock` o `uv.lock`.

| Livello | Scanner | Descrizione |
|-------|---------|-------------|
| **L1** | `pip-audit` | Vulnerabilità note tramite PyPI Advisory DB (opzionale — SKIP se non installato; consigliato `pip install pip-audit`) |
| **L2** | `osv-scanner` | Database di vulnerabilità open source di Google confrontato con `uv.lock` / `poetry.lock` / `requirements*.txt` (opzionale — SKIP se non installato) |
| **L3-MAL** | Lista statica di pacchetti dannosi (`_L3_LIST`) | Nomi di pacchetti noti come dirottati / typosquat. Corrisponde alla lista PEP 621, alle dichiarazioni inline di Poetry e in stile requirements (vedi [PR #4](https://github.com/eris-ths/supply-chain-guard/pull/4)). FAIL in caso di corrispondenza |
| **L3-CVE** | Lista statica delle versioni con flag CVE (`_L3_CVE_LIST`) | Versioni vulnerabili note di pacchetti legittimi (es., `starlette<1.0.1` per [BadHost CVE-2026-48710](https://cryptobriefing.com/starlette-badhost-vulnerability-ai-agents/)). Valutazione rigorosa secondo la specifica semver tramite la libreria `packaging` di Python. FAIL in caso di corrispondenza confermata. Avvisa se un pacchetto è dichiarato ma non è presente alcun lockfile (impossibile valutare la versione) |
| **IOC** | Filesystem + Process | Controllo degli artefatti in stile Python (script canaglia, processi sospetti) |
| **LF** | Integrità del lockfile | Verifica che `uv.lock` / `poetry.lock` / `requirements*.txt` vengano parsati correttamente e contengano versioni fissate |

**Trigger:** "this project" con file Python presenti, o uno qualsiasi di `pyproject.toml` / `requirements*.txt` / `poetry.lock` / `uv.lock` nella cwd

> **Nota sulle dipendenze:** L1 (`pip-audit`) e L2 (`osv-scanner`) eseguono uno SKIP elegante con un suggerimento quando la rispettiva CLI è assente. L3 è il livello sempre attivo e non richiede alcuno strumento esterno, ma una valutazione accurata di L3-CVE richiede `pip install packaging`.

---

## Intelligence sulle Minacce

### Database delle minacce note

| ID | Data | Pacchetto | Attore della minaccia | Vettore |
|----|------|-----------|-----------------------|---------|
| **T001** | 2026-03-31 | `[email protected]`, `[email protected]` | UNC1069/DPRK-APT | Compromissione del maintainer → dipendenza fantasma → RAT |
| **T002** | 2018-11 | `[email protected]` | Sconosciuto | Iniezione di dipendenza → furto di criptovalute |
| **T003** | In corso | `crossenv`, `loadsh`, `crypto-js-esm` | Vari | Typosquatting → esfiltrazione post-install |

### Catena di attacco 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

Versioni sicure

ID degli advisory

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

Devil Gate Framework

SCG utilizza un framework di verifica a 8 gate organizzato in 4 categorie, eseguito come una catena seriale con loop di convergenza.

Gate

Esecuzione della catena```

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

### Matrice di gravità

| Livello | Condizione | Azione |
|---------|------------|--------|
| **CRITICAL** | Artefatto RAT trovato OPPURE pacchetto dannoso installato | Isola rete → Termina processo → Rimuovi persistenza → Reinstalla |
| **HIGH** | Versione compromessa in uso | Fissa versione sicura → Override → `npm ci` → Verifica |
| **MEDIUM** | Script postinstall sospetto | Revisione manuale → Whitelist o rimozione |
| **LOW** | Disallineamento del lockfile | Risincronizzazione con `npm ci` |
| **CLEAR** | Tutti i controlli superati | Nessuna azione richiesta |

> **Sicurezza:** le risposte CRITICAL/HIGH comportano operazioni distruttive. SCG presenta sempre i risultati e chiede una conferma esplicita all'utente prima di eseguire la remediation.

---

## Script Standalone

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

Scansione completa dell'ambiente. Verifica gli artefatti IOC, analizza tutti i lockfile in `$HOME` (configurabile) e segnala i pacchetti compromessi.```bash
./scripts/env-scan.sh [scan_root_dir]
# Default: $HOME

scripts/project-scan.sh

Scansione a livello di progetto. Eseguire da una directory contenente package.json.```bash cd my-project /path/to/scripts/project-scan.sh

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

Scansione solo IOC. Verifica gli artefatti del filesystem, i processi in esecuzione e le connessioni di rete rispetto a indicatori C2 noti. Multipiattaforma (macOS/Linux/Windows tramite PowerShell).```bash
./scripts/ioc-scan.sh

scripts/respond.sh

Correzione interattiva. Ogni azione distruttiva richiede una conferma [y/N] (predefinito: 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)

Passaggi nella modalità `--critical`:
1. Isolamento di rete (blocco del dominio C2 tramite `/etc/hosts`)
2. Terminare i processi RAT
3. Rimuovere la persistenza (LaunchAgents / crontab / attività pianificate)
4. Eliminare `node_modules` e il lockfile, pulire la cache npm
   - **4b (Python):** svuota la cache pip (sicuro, automatico); la ricostruzione del venv è mostrata come passaggi manuali
5. Reinstallare le dipendenze
6. Richiedere una scansione di verifica (`project-scan.sh` e/o `project-scan-py.sh`)

Ogni passaggio controlla se l'azione è realmente necessaria (ad esempio, salta "kill" se nessun processo RAT è in esecuzione) e mostra esattamente cosa verrà eseguito prima di chiedere conferma.

Per la modalità **HIGH**, npm applica automaticamente l'override; Python è guidato (rileva il gestore → stampa il comando pin → applica solo il passaggio sicuro). Vedi la nota sulla correzione Python in [Avvio rapido](#quick-start).

---

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

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

> **Fissa le action tramite SHA, non tramite tag.** L'esempio qui sopra usa `actions/checkout@v4` per leggibilità, ma i tag possono essere spostati. In produzione, fissa uno SHA completo del commit per prevenire attacchi alla supply chain delle action:
> ```yaml
> - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
> - uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af  # v4.1.0
> ```

---

## Playbook di risposta

### Se CRITICO (RAT rilevato)

> **Niente panico.** Segui questi passaggi in ordine. Ogni passaggio richiede la tua conferma esplicita.

1. **Isola la rete** — Blocca il dominio C2 tramite `/etc/hosts`
2. **Termina i processi** — Chiudi i processi RAT (`com.apple.act.mond`, `ld.py`, `wt.exe`)
3. **Rimuovi la persistenza** — Elimina LaunchAgents, crontabs e attività pianificate
4. **Pulisci npm** — Rimuovi `node_modules` e `package-lock.json`, svuota la cache npm
5. **Reinstalla** — Esegui una `npm install && npm ci` pulita
6. **Riscansiona** — Esegui di nuovo l'intera pipeline, aspettati CLEAR

### Se ALTA (versione compromessa installata)

1. **Blocca una versione sicura** usando respond.sh:   ```bash
   ./scripts/respond.sh --high axios 1.14.0

Questo aggiunge overrides (npm) o resolutions (yarn) a package.json, reinstalla e richiede una verifica.

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

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

3. Reinstalla: npm ci
4. Verifica: Riesegui la scansione

Riferimento IOC

Artefatti del filesystem

Meccanismi di persistenza

Indicatori di rete

Tecniche di camuffamento

Formato di output```

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

---

## Riferimenti

| Fonte | Descrizione |
|--------|-------------|
| [Zenn (JP)](https://zenn.dev/gunta/articles/0152eadf05d173) | Report iniziale dal Giappone |
| [Elastic Security Labs](https://elastic.co/security-labs/axios-one-rat-to-rule-them-all) | Analisi tecnica (disassemblaggio RAT, protocollo C2, cronologia) |
| [SANS](https://sans.org/blog/axios-npm-supply-chain-compromise-malicious-packages-remote-access-trojan) | Procedure IR aziendali |
| [Huntress](https://huntress.com/blog/supply-chain-compromise-axios-npm-package) | Firme YARA |
| [Elastic Detections](https://elastic.co/security-labs/axios-supply-chain-compromise-detections) | Regole di rilevamento SIEM (YARA/osquery/KQL) |
| [Semgrep](https://semgrep.dev/blog/2026/axios-supply-chain-incident-indicators-of-compromise-and-how-to-contain-the-threat/) | Regole di analisi statica, guida al contenimento |
| [SOCRadar](https://socradar.io/blog/axios-npm-supply-chain-attack-2026-ciso-guide/) | Guida per CISO con cronologia degli IOC |
| [Wiz](https://wiz.io/blog/axios-npm-compromised-in-supply-chain-attack) | Analisi dell'impatto sul cloud, scansione dei container |
| [NVD CVE-2026-48710](https://nvd.nist.gov/vuln/detail/CVE-2026-48710) | **Primaria** — Voce canonica NVD (pubblicata il 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) | **Primaria** — GitHub Security Advisory su `Kludex/starlette` (pubblicato il 2026-05-21): "La mancata validazione dell'header Host compromette request.url.path, bypassando i controlli di sicurezza basati sul percorso" |
| [Note di rilascio di Starlette v1.0.1](https://github.com/Kludex/starlette/releases/tag/1.0.1) | **Primaria** — release correttiva (pubblicata il 2026-05-21). Fissa `starlette>=1.0.1` (e `fastapi>=0.119` per la risoluzione transitiva) |
| [Copertura di Starlette BadHost (KuCoin)](https://kucoin.com/news/flash/starlette-vulnerability-exposes-millions-of-ai-agents-to-hackers) | **Secondaria** — impatto sull'ecosistema Python, inquadramento degli agenti AI |
| [Analisi degli agenti AI di BadHost (CryptoBriefing)](https://cryptobriefing.com/starlette-badhost-vulnerability-ai-agents/) | **Secondaria** — inquadramento dell'impatto a valle su FastAPI / vLLM / LiteLLM |

---

## Integrazione della lente Devil in Guild-CLI

Se utilizzi [guild-cli](https://github.com/eris-ths/guild-cli) (o qualsiasi progetto che espone un workflow della lente Devil), SCG può essere invocato come una delle lenti di sicurezza durante un passaggio di revisione.

### Pattern di invocazione consigliato```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"

Note sui flag (verificate con guild-cli): gate review richiede un <id> esistente, --lense (guild-cli lo scrive "lense") e --verdict (ok / concern / reject). Non ha un flag --area. Per registrare un nuovo rilevamento senza un oggetto di review precedente, usa gate fast-track come in (a).

Perché abbinare SCG a Devil

L'avvocato del diavolo ("壊しにいく") e SCG condividono la stessa postura: presumi il peggio, scansiona sistematicamente, poi convergi. SCG fornisce la dimensione supply-chain di una passata Devil — cosa potrebbero fare le dipendenze del progetto alle tue spalle — insieme ad altre lenti (sicurezza / correttezza / architettura / utente / operazioni).

Limitazioni dell'abbinamento con Devil

• SCG viene eseguito in sola lettura; la lente Devil non applica fix. Usa respond.sh separatamente quando è necessaria una remediation (con conferma esplicita dell'utente)
• L'output di SCG potrebbe superare i budget di contesto di Devil nei repository di grandi dimensioni; se necessario, filtra con tail -50
• Per i repository poliglotti, esegui sia project-scan.sh che project-scan-py.sh e unisci i rilevamenti

Esclusione di responsabilità

SCG è uno strumento di rilevamento, non una garanzia di sicurezza. Essere trasparenti su ciò che può e non può fare fa parte del design.

Questo software è fornito "così com'è", senza alcuna garanzia. Utilizzando Supply Chain Guard, riconosci e accetti quanto segue:

• Non sostituisce la sicurezza professionale. SCG è uno strumento di rilevamento supplementare, non una soluzione di sicurezza completa. Non sostituisce l'incident response professionale, il software di endpoint detection and response (EDR) o le audit di sicurezza.
• Nessuna garanzia di rilevamento. Un verdetto CLEAR significa che non sono state trovate corrispondenze con i pattern di minaccia noti allo strumento. Non significa che il tuo sistema o progetto sia esente da compromissione. Attacchi nuovi, sconosciuti o modificati potrebbero non essere rilevati.
• Nessuna garanzia di remediation. Le procedure di remediation fornite (respond.sh) affrontano indicatori noti di minacce specifiche. Potrebbero non rimuovere completamente tutte le tracce di una compromissione sofisticata. Se sospetti una compromissione attiva, contatta un team professionale di incident response.
• Uso a proprio rischio. Gli autori non sono responsabili per danni, perdita di dati o incidenti di sicurezza derivanti dall'uso o dall'impossibilità di usare questo strumento. Ciò include, a titolo esemplificativo ma non esaustivo: falsi negativi (rilevamenti mancati), falsi positivi (rilevamenti errati) o conseguenze indesiderate derivanti dall'esecuzione degli script di remediation.
• Non è un consiglio legale o di conformità. Questo strumento non soddisfa i requisiti normativi, di conformità o legali per la scansione di sicurezza. Consulta i professionisti appropriati per le esigenze di conformità.

Limitazioni

Capire cosa SCG non può fare è importante quanto sapere cosa può fare.

Limiti del rilevamento

Attualità del database delle minacce

Il database Known Threats (D.2 in SKILL.md) è mantenuto manualmente. Non è collegato a nessun feed di minacce in tempo reale. C'è una latenza intrinseca tra la scoperta di un nuovo incidente della supply chain e l'aggiornamento di questo database.

• Ultimo aggiornamento: 2026-05-27 (v4: supporto Python, aggiunto BadHost CVE-2026-48710)
• Copertura: 3 famiglie di minacce npm (T001-T003) + 4 voci di hijack/typosquat Python + 1 voce di versione Python con flag CVE (BadHost)
• Ambito della copertura Python (v4): scansione principalmente basata su lockfile (uv.lock / poetry.lock / requirements.txt). Il layer delle versioni con flag CVE è best-effort — segnala solo i pacchetti che corrispondono alle voci _L3_CVE_LIST con valutazione rigorosa della semver-spec, e dipende dall'installazione di packaging per un abbinamento accurato delle versioni

Fai sempre un cross-reference con fonti in tempo reale come npm advisories, OSV.dev e i blog di sicurezza dei vendor elencati nella sezione References.

Rischio di falsi positivi

I seguenti percorsi IOC possono, in casi rari, entrare in conflitto con software legittimi:

Verifica sempre i rilevamenti IOC prima di eseguire la remediation. Lo script ioc-scan.sh riporta i rilevamenti per una revisione umana — non esegue alcuna azione. Lo script respond.sh richiede una conferma esplicita per ogni azione distruttiva (default: NO) proprio a causa di questo rischio.

Limitazioni della scansione di rete

• I controlli di rete basati su lsof rilevano solo le connessioni attualmente attive. Un beacon C2 che si connette in modo intermittente potrebbe non essere attivo al momento della scansione.
• I controlli della cache DNS sono best-effort e dipendono dal sistema operativo. Le cache svuotate non mostreranno connessioni storiche.
• Il traffico C2 crittografato o in tunnel non può essere rilevato solo tramite il matching di porte/IP.

Ambito

• npm/yarn e Python (pip/poetry/uv). Non copre cargo, go modules o altri ecosistemi di pacchetti.
• Solo minacce note. Questo è uno strumento di pattern-matching, non un motore di analisi comportamentale.
• Scansione istantanea. I risultati riflettono lo stato al momento dell'esecuzione. Il monitoraggio continuo richiede un'esecuzione ripetuta o l'integrazione con CI/CD.

Verifica dell'integrità

Verifica che la tua copia di SCG non sia stata manomessa. Confronta questi checksum SHA-256 con i tuoi file locali:

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

Per verificare:```bash
shasum -a 256 scripts/*.sh scripts/*.ps1 SKILL.md

Nota: Questi checksum corrispondono all'ultima release. Se hai modificato localmente alcuni file, i checksum differiranno. Quando SCG viene aggiornato, questa sezione viene aggiornata insieme alle modifiche del codice.

Licenza

MIT

Realizzato da Eris — perché le tue dipendenze non dovrebbero essere la superficie d'attacco di qualcun altro.