Supply Chain Guard (SCG)

Ein Incident-Response-Toolkit für npm/yarn- und Python (pip/poetry/uv)-Supply-Chain-Angriffe – kostenlos, lokal, ohne Abhängigkeiten.

SCG ist kein Scan-Engine, der mit kommerziellen Tools in der Abdeckung konkurriert. Es ist eine Claude-Code-Skill und ein eigenständiges Shell-Toolkit, das drei Dinge gut beherrscht: (1) eine schnelle, wiederholbare Erstreaktion bietet, wenn ein spezifischer Vorfall eintritt („Ist mein Rechner jetzt betroffen?“), (2) vorhandene OSS-Scanner (npm audit, osv-scanner, pip-audit) in einen strukturierten Durchlauf orchestriert und (3) hart erarbeitete Design-Hygiene-Lektionen dokumentiert – insbesondere für KI-Entwicklungsumgebungen – die generische Scanner nicht abdecken.

Es wurde während realer Vorfälle entwickelt und gehärtet, darunter:

• [email protected] RAT-Vorfall (2026-03-31) — npm-Maintainer-Kontoübernahme (UNC1069/DPRK-APT) durch Injektion einer Phantom-Abhängigkeit mit RAT
• Starlette BadHost (CVE-2026-48710, 2026-05-22) — Python-HTTP-Framework Host-Header-Pfad-Injektion → SSRF/RCE, das FastAPI, vLLM, LiteLLM und das gesamte KI-Agenten-Ökosystem betrifft

Neuerungen in v4 (2026-05-27)

• Python-Supply-Chain-Scan — scripts/project-scan-py.sh mit pip-audit / osv-scanner / CVE-gekennzeichneter Versionserkennung
• CVE-gekennzeichnete Versionsschicht (L3-CVE) — Verfolgen bekannter verletzlicher Versionen legitimer Pakete mit strenger semver-Spezifikationsbewertung (BadHost CVE-2026-48710 ist standardmäßig enthalten)
• Design-Hygiene-Richtlinie — stdio-first MCP-Transport, Versions-Pin-Disziplin, Härtung des GCP-Standard-Compute-SA-Editors (siehe SKILL.md §D.7 DesignHygiene)
• Guild-CLI-Devil-Linsen-Integration — Aufruf von SCG als Devil-Linse aus guild-cli-Workflows (siehe „Guild-CLI-Devil-Integration“ unten)

Inhaltsverzeichnis

• Warum es das gibt
• Wie SCG sich von bestehenden Tools unterscheidet
• Was SCG ist (und nicht ist)
• Architektur
• Schnellstart
• Scan-Modi
• Bedrohungsinformationen
• Devil-Gate-Framework
• Eigenständige Skripte
• CI/CD-Integration
• Reaktionshandbuch
• IOC-Referenz
• Haftungsausschluss
• Einschränkungen
• Integritätsprüfung
• Lizenz

Warum es das gibt

Am 31. März 2026 wurde das weit verbreitete axios npm-Paket (v1.14.1 und v0.30.4) durch eine Kontoübernahme eines Maintainers kompromittiert, die UNC1069/DPRK-APT zugeschrieben wird (laut Google Threat Intelligence Group). Der Angriff injizierte eine Phantom-Abhängigkeit ([email protected]), die über postinstall-Skripte einen plattformübergreifenden RAT bereitstellte, getarnt als legitime Systemprozesse.

Supply Chain Guard (SCG) wurde während des Vorfalls entwickelt, um Folgendes bereitzustellen:

1. Soforterkennung — Ist mein Rechner oder Projekt jetzt betroffen?
2. Strukturierte Bewertung — Wie schwerwiegend ist es? Wie ist der Blast Radius?
3. Geführte Reaktion — Schritt-für-Schritt-Behobung mit Sicherheitsbestätigungen
4. Fortlaufende Verteidigung — Ein 8-Gate-Verifikationsrahmen zur Vermeidung von Wiederholungen

Wie SCG sich von bestehenden Tools unterscheidet

SCG ist kein Ersatz für bestehende Sicherheitstools. Es kombiniert mehrere Erkennungsschichten mit einem strukturierten Verifikationsrahmen und geführter Behebung – entwickelt für den Einsatz während aktiver Vorfälle oder als regelmäßige Überprüfung neben Ihrer vorhandenen Toolausstattung.

Wann SCG verwenden:

• Ein Supply-Chain-Vorfall ist gerade bekannt geworden und Sie müssen Ihre Rechner und Projekte sofort überprüfen
• Sie möchten einen strukturierten, wiederholbaren Prozess zur Verifikation, dass eine Kompromittierung vollständig behoben wurde
• Sie benötigen eine leichtgewichtige Prüfung, die lokal ohne SaaS-Abhängigkeiten läuft

Wann etwas anderes verwenden:

• Sie benötigen kontinuierliche Echtzeitüberwachung → Snyk, Socket.dev
• Sie benötigen Lizenz-Compliance-Scans → Snyk, FOSSA
• Sie benötigen Abdeckung über npm/yarn hinaus → osv-scanner (unterstützt pip, cargo, go usw.)

Was SCG ist (und nicht ist)

Wir möchten lieber ehrlich über die Grenzen sein, als zu viel zu versprechen. SCG ist drei Dinge:

1. Ein Incident-Response-Playbook als Code. Wenn ein benannter Vorfall eintritt (axios RAT, Shai-Hulud, eine neue CVE), verwandelt SCG „Bin ich betroffen, und wenn ja, was tue ich?“ in eine ausführbare Checkliste – 8 Verifikationsgates, eine Schweregradmatrix und ein Behebungsskript, bei dem jede destruktive Aktion eine explizite [j/N]-Bestätigung benötigt. Dies ist sein primärer Wert: die schnelle, strukturierte Erstreaktion, für die kommerzielle Überwachungstools nicht ausgelegt sind.

2. Ein Orchestrator bestehender OSS-Scanner. Die L1/L2-Schichten kapseln npm audit / pip-audit / osv-scanner ein. Der Großteil der rohen Erkennungsleistung ist entliehen; SCGs Beitrag besteht darin, sie in einen Durchlauf zu bündeln, Dateisystem-/IOC-Prüfungen hinzuzufügen, die die Registry-Tools nicht durchführen, und die Ausgabe lesbar und umsetzbar zu machen.

3. Dokumentation echter Design-Hygiene-Lektionen (SKILL.md §D.7) – Dinge, auf die wir tatsächlich gestoßen sind oder die wir untersucht haben: MCP-Transportwahl, Härtung des GCP-Standard-SA, Installationszeit-Ausführungsvektoren und Bedrohungen, die KI-Entwicklungstools ins Visier nehmen (Shai-Hulud liest .claude/settings.json, SANDWORM_MODE vergiftet MCP-Konfigurationen). Diese Nische – Supply-Chain-Hygiene für KI-gestützte Entwicklung – ist der Bereich, in dem SCG wirklich differenziert ist.

Was SCG bewusst NICHT ist

• Kein Abdeckungskonkurrent. Die Bedrohungsdatenbank (SKILL.md D.2, die statischen L3-Listen) ist handgepflegt – sie enthält die Vorfälle, von denen wir gelesen haben, nicht die zehntausende bösartigen Pakete, die ein kommerzieller Live-Feed verfolgt. Eine handkuratierte Liste kann nicht mit der tatsächlichen Rate neuer Bedrohungen Schritt halten, und wir geben nicht vor, dass sie es tut.
• Kein Verhaltensanalyse-Engine. SCG erkennt bekannte Muster. Obfuskierte Payloads und echte Zero-Days ohne öffentliches Advisory sind von Natur aus ausgeschlossen.
• Keine kontinuierliche Überwachung. Es ist eine punktuelle Überprüfung, die Sie während eines Vorfalls oder als regelmäßigen Durchlauf ausführen – kein Dienst, der Ihren Abhängigkeitsgraphen überwacht.

Wohin SCG sich entwickelt

Da eine handkuratierte Datenbank in der Abdeckung nicht gewinnen kann, investieren wir bewusst in Bereiche, in denen SCG schwer zu ersetzen ist, anstatt wo es immer verlieren wird:

• Tiefere Incident-Response-Playbooks (#1) – bessere Ergonomie für die Erstreaktion, mehr Vorfallvorlagen.
• KI-Entwicklungsumgebungs-Hygiene (#3) – Erkennung und Anleitung für Bedrohungen gegen Claude Code / Cursor / MCP-Server und ähnliche Tools, die kommerzielle Supply-Chain-Scanner weitgehend nicht adressieren.

Die statische Bedrohungs-DB (#2) wird weiterhin aktualisiert, wenn bemerkenswerte Vorfälle eintreten, aber sie ist ausdrücklich nicht die Richtung, in der wir versuchen zu konkurrieren.

Architektur

SCG folgt einer Domain-Driven Design (DDD)-Architektur mit drei Schichten:``` +-----------------------------------------------------+ | 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) | +-----------------------------------------------------+

### Scan-Pipeline

Die gleiche 5-stufige Pipeline gilt für beide Ökosysteme mit Ökosystem-spezifischen Scannern auf jeder Ebene:```
L1 ──→ L2 ──→ L3 ──→ IOC ──→ LF ──→ assess(SeverityMatrix) ──→ VERDICT

Beide Pipelines speisen dieselbe SeverityMatrix und das Devil Gate Framework.

Schnellstart

Als Claude-Code-Skill

Kopieren Sie SKILL.md in Ihr Claude-Code-Skills-Verzeichnis:```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

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

Als eigenständige Skripte```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-Korrektur ist von Natur aus konservativ.** Für npm wendet `--high` die Überschreibung automatisch an. Für Python *führt* es: es erkennt Ihren Manager (pip/poetry/uv), gibt den genauen Pin-Befehl aus und wendet nur den sicheren Schritt an — Befehle zur Änderung der Lockdatei und zum Neuerstellen der venv werden zur Ausführung angezeigt. Dies vermeidet, dass ein falsch positives Ergebnis eine kollaterale Zwangsneuinstallation im fragmentierten Python-Paketierungs-Ökosystem auslöst.

Für ein polyglottes Repository (npm + Python) führen Sie beide Projekt-Scanner nacheinander aus den entsprechenden Unterverzeichnissen aus.

> **Sicherheitsdesign:** Alle Scan-Skripte sind streng schreibgeschützt – sie ändern, löschen oder installieren nichts. Das Korrektur-Skript (`respond.sh`) ist das einzige Skript, das destruktive Operationen ausführt, und **jede einzelne Aktion erfordert eine explizite `[y/N]`-Bestätigung** mit Standardwert NEIN.

---

## Scan-Modi

### Umgebungs-Scan (`env_scan`)

Durchsucht Ihre gesamte Entwicklungsmaschine nach Kompromittierungsindikatoren.

| Prüfung | Beschreibung |
|---------|--------------|
| **IOC: Dateisystem** | RAT-Binärdateien, Persistenzmechanismen, Staging-Dateien |
| **IOC: Netzwerk** | Aktive C2-Verbindungen (IP + Domain) |
| **IOC: Prozess** | Laufende schädliche Prozesse |
| **Projektübergreifend** | Alle `package-lock.json`-Dateien auf kompromittierte Versionen durchsucht |
| **Schädliche Pakete** | Bekannte schädliche Paketnamen in jeder Lockdatei |

**Auslöser:** "dieser PC", "Umgebungsprüfung", "maschinenweit"

### Projekt-Scan — npm/yarn (`project_scan`)

Tiefenscan eines einzelnen npm/yarn-Projekts. Führen Sie ihn aus einem Verzeichnis aus, das `package.json` enthält.

| Ebene | Scanner | Beschreibung |
|-------|---------|--------------|
| **L1** | `npm audit` | Bekannte Schwachstellen über npm-Registry |
| **L2** | `osv-scanner` / OSV.dev API | Googles Open-Source-Schwachstellendatenbank |
| **L3** | Statische Liste | Hartcodierte Prüfung auf bekannte schädliche Pakete |
| **IOC** | Dateisystem + Netzwerk | RAT-Artifikaterkennung |
| **LF** | Lockdatei-Integrität | `npm ci --dry-run` + Integritäts-Hash-Anzahl |

**Auslöser:** "dieses Projekt", "npm audit", oder `package.json` im aktuellen Arbeitsverzeichnis vorhanden

### Projekt-Scan — Python (`project_scan_py`, hinzugefügt in v4)

Tiefenscan eines einzelnen Python-Projekts. Führen Sie ihn aus einem Verzeichnis aus, das `pyproject.toml`, `requirements*.txt`, `poetry.lock` oder `uv.lock` enthält.

| Ebene | Scanner | Beschreibung |
|-------|---------|--------------|
| **L1** | `pip-audit` | Bekannte Schwachstellen über PyPI Advisory DB (optional – ÜBERSPRINGEN, wenn nicht installiert; `pip install pip-audit` empfohlen) |
| **L2** | `osv-scanner` | Googles Open-Source-Schwachstellendatenbank gegen `uv.lock` / `poetry.lock` / `requirements*.txt` (optional – ÜBERSPRINGEN, wenn nicht installiert) |
| **L3-MAL** | Statische Schadliste (`_L3_LIST`) | Bekannte gekaperte / Typosquat-Paketnamen. Passt auf PEP 621-Liste, Poetry-inline und requirements-artige Deklarationen (siehe [PR #4](https://github.com/eris-ths/supply-chain-guard/pull/4)). FEHLER bei Treffer |
| **L3-CVE** | Statische CVE-gekennzeichnete Versionsliste (`_L3_CVE_LIST`) | Bekannte angreifbare Versionen legitimer Pakete (z.B. `starlette<1.0.1` für [BadHost CVE-2026-48710](https://cryptobriefing.com/starlette-badhost-vulnerability-ai-agents/)). Strenge semver-Prüfung mittels Pythons `packaging`-Bibliothek. FEHLER bei bestätigtem Treffer. Warnt, wenn ein Paket deklariert ist, aber keine Lockdatei vorhanden ist (Version nicht auswertbar) |
| **IOC** | Dateisystem + Prozess | Python-spezifische Artifaktprüfung (betrügerische Skripte, verdächtige Prozesse) |
| **LF** | Lockdatei-Integrität | Überprüft, ob `uv.lock` / `poetry.lock` / `requirements*.txt` sauber geparst werden und gepinnte Versionen enthalten. |

**Auslöser:** "dieses Projekt" mit vorhandenen Python-Dateien oder eine von `pyproject.toml` / `requirements*.txt` / `poetry.lock` / `uv.lock` im aktuellen Arbeitsverzeichnis

> **Abhängigkeitshinweis:** L1 (`pip-audit`) und L2 (`osv-scanner`) werden mit einem Hinweis elegant ÜBERSPRUNGEN, wenn ihr jeweiliges CLI fehlt. L3 ist die immer aktive Ebene und benötigt kein externes Tool, aber eine genaue L3-CVE-Auswertung erfordert `pip install packaging`.

---

## Bedrohungsinformationen

### Datenbank bekannter Bedrohungen

| ID | Datum | Paket | Bedrohungsakteur | Vektor |
|----|-------|-------|------------------|--------|
| **T001** | 2026-03-31 | `[email protected]`, `[email protected]` | UNC1069/DPRK-APT | Kompromittierung des Maintainers → Phantom-Abhängigkeit → RAT |
| **T002** | 2018-11 | `[email protected]` | Unbekannt | Abhängigkeitsinjektion → Krypto-Diebstahl |
| **T003** | Laufend | `crossenv`, `loadsh`, `crypto-js-esm` | Verschiedene | Typosquatting → Postinstall-Exfiltration |

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

Safe Versions

Advisory-IDs

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

Devil Gate Framework

SCG verwendet ein 8-Gate-Verifizierungsframework, das in 4 Kategorien unterteilt ist und als serielle Kette mit Konvergenzschleife ausgeführt wird.

Gates

Chain Execution```

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

### Schweregrad-Matrix

| Stufe | Bedingung | Aktion |
|-------|-----------|--------|
| **KRITISCH** | RAT-Artefakt gefunden ODER bösartiges Paket installiert | Netzwerk isolieren → Prozess beenden → Persistenz entfernen → Neu installieren |
| **HOCH** | Kompromittierte Version in Verwendung | Sichere Version festlegen → Überschreiben → `npm ci` → Überprüfen |
| **MITTEL** | Verdächtiges Postinstall-Skript | Manuelle Prüfung → Whitelist oder entfernen |
| **NIEDRIG** | Lockdatei-Abweichung | `npm ci` neu synchronisieren |
| **KLAR** | Alle Prüfungen bestanden | Keine Aktion erforderlich |

> **Sicherheit:** KRITISCHE/HOHE Antworten beinhalten destruktive Operationen. SCG präsentiert stets die Ergebnisse und fordert explizite Benutzerbestätigung vor der Durchführung der Behebung.

---

## Eigenständige Skripte

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

Vollständige Umgebungsprüfung. Überprüft IOC-Artefakte, scannt alle Lockdateien unter `$HOME` (konfigurierbar) und meldet kompromittierte Pakete.```bash
./scripts/env-scan.sh [scan_root_dir]
# Default: $HOME

scripts/project-scan.sh

Projektweiter Scan. Aus einem Verzeichnis ausführen, das package.json enthält.```bash cd my-project /path/to/scripts/project-scan.sh

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

IOC-only-Scan. Überprüft Dateisystemartefakte, laufende Prozesse und Netzwerkverbindungen auf bekannte C2-Indikatoren. Plattformübergreifend (macOS/Linux/Windows über PowerShell).```bash
./scripts/ioc-scan.sh

scripts/respond.sh

Interaktive Remediation. Jede zerstörerische Aktion erfordert [y/N]-Bestätigung (Standard: 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)

Schritte im `--critical`-Modus:
1. Netzwerk isolieren (C2-Domain über `/etc/hosts` blockieren)
2. RAT-Prozesse beenden
3. Persistenz entfernen (LaunchAgents / crontab / geplante Aufgaben)
4. `node_modules` und Lockfile löschen, npm-Cache leeren
   - **4b (Python):** pip-Cache leeren (sicher, automatisch); venv-Neuaufbau als manuelle Schritte dargestellt
5. Abhängigkeiten neu installieren
6. Zur Überprüfungsscan auffordern (`project-scan.sh` und/oder `project-scan-py.sh`)

Jeder Schritt prüft, ob die Aktion tatsächlich erforderlich ist (z.B. überspringt „kill“, wenn kein RAT-Prozess läuft) und zeigt genau an, was ausgeführt wird, bevor um Bestätigung gebeten wird.

Für den **HIGH**-Modus wendet npm die Überschreibung automatisch an; Python wird geführt (Manager erkennen → Pin-Befehl ausgeben → nur den sicheren Schritt anwenden). Siehe den Python-Behebungsvermerk unter [Schnellstart](#quick-start).

---

## CI/CD-Integration

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

Härtungsempfehlungen```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

> **Aktionen per SHA pinnen, nicht per Tag.** Das obige Beispiel verwendet `actions/checkout@v4` aus Gründen der Lesbarkeit, aber Tags können verschoben werden. In der Produktion sollte auf einen vollständigen Commit-SHA gepinnt werden, um Angriffe auf die Lieferkette der Aktionen zu verhindern:
> ```yaml
> - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
> - uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af  # v4.1.0
> ```

---

## Reaktionshandbuch

### Bei KRITISCH (RAT erkannt)

> **Keine Panik.** Befolgen Sie diese Schritte der Reihe nach. Jeder Schritt erfordert Ihre ausdrückliche Bestätigung.

1. **Netzwerk isolieren** — C2-Domain über `/etc/hosts` blockieren
2. **Prozesse beenden** — RAT-Prozesse beenden (`com.apple.act.mond`, `ld.py`, `wt.exe`)
3. **Persistenz entfernen** — LaunchAgents, Crontabs, geplante Aufgaben löschen
4. **npm bereinigen** — `node_modules` und `package-lock.json` entfernen, npm-Cache leeren
5. **Neu installieren** — Frische `npm install && npm ci`
6. **Erneut scannen** — Gesamte Pipeline erneut ausführen, CLEAR erwarten

### Bei HOCH (kompromittierte Version installiert)

1. **Sichere Version pinnen** mit respond.sh:   ```bash
   ./scripts/respond.sh --high axios 1.14.0

Dies fügt overrides (npm) oder resolutions (yarn) zu package.json hinzu, installiert neu und fordert zur Bestätigung auf.

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

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

3. Neu installieren: npm ci
4. Überprüfen: Scan erneut ausführen

IOC-Referenz

Dateisystem-Artefakte

Persistenzmechanismen

Netzwerk-Indikatoren

Tarnungstechniken

Ausgabeformat```

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

---

## Referenzen

| Quelle | Beschreibung |
|--------|-------------|
| [Zenn (JP)](https://zenn.dev/gunta/articles/0152eadf05d173) | Japanischer Früher Bericht |
| [Elastic Security Labs](https://elastic.co/security-labs/axios-one-rat-to-rule-them-all) | Technische Analyse (RAT-Disassemblierung, C2-Protokoll, Zeitplan) |
| [SANS](https://sans.org/blog/axios-npm-supply-chain-compromise-malicious-packages-remote-access-trojan) | Unternehmens-IR-Verfahren |
| [Huntress](https://huntress.com/blog/supply-chain-compromise-axios-npm-package) | YARA-Signaturen |
| [Elastic Detections](https://elastic.co/security-labs/axios-supply-chain-compromise-detections) | SIEM-Erkennungsregeln (YARA/osquery/KQL) |
| [Semgrep](https://semgrep.dev/blog/2026/axios-supply-chain-incident-indicators-of-compromise-and-how-to-contain-the-threat/) | Statische Analyseregeln, Eindämmungsleitfaden |
| [SOCRadar](https://socradar.io/blog/axios-npm-supply-chain-attack-2026-ciso-guide/) | CISO-Leitfaden mit IOC-Zeitleiste |
| [Wiz](https://wiz.io/blog/axios-npm-compromised-in-supply-chain-attack) | Cloud-Auswirkungsanalyse, Container-Scanning |
| [NVD CVE-2026-48710](https://nvd.nist.gov/vuln/detail/CVE-2026-48710) | **Primär** — NVD-kanonischer Eintrag (veröffentlicht 2026-05-26, CVSS 3.1 Basis 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) | **Primär** — GitHub-Sicherheitshinweis auf `Kludex/starlette` (veröffentlicht 2026-05-21): „Fehlende Host-Header-Validierung vergiftet request.url.path und umgeht pfadbasierte Sicherheitsprüfungen.“ |
| [Starlette v1.0.1 Versionshinweise](https://github.com/Kludex/starlette/releases/tag/1.0.1) | **Primär** — Fehlerbehebungsversion (veröffentlicht 2026-05-21). Festlegen `starlette>=1.0.1` (und `fastapi>=0.119` für transitive Auflösung) |
| [Starlette BadHost-Berichterstattung (KuCoin)](https://kucoin.com/news/flash/starlette-vulnerability-exposes-millions-of-ai-agents-to-hackers) | Sekundär — Auswirkungen auf das Python-Ökosystem, Framing von KI-Agenten |
| [BadHost KI-Agentenanalyse (CryptoBriefing)](https://cryptobriefing.com/starlette-badhost-vulnerability-ai-agents/) | Sekundär — Framing der nachgelagerten Auswirkungen auf FastAPI / vLLM / LiteLLM |

---

## Guild-CLI-Devil-Integration

Wenn Sie [guild-cli](https://github.com/eris-ths/guild-cli) (oder ein Projekt, das einen Devil-Linsen-Workflow bereitstellt) verwenden, kann SCG als eine der Sicherheitslinsen während eines Überprüfungsdurchlaufs aufgerufen werden.

### Empfohlenes Aufrufmuster```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 erfordert eine vorhandene <id>, --lense (guild-cli schreibt es „lense“) und --verdict (ok / concern / reject). Es hat kein --area-Flag. Für die Protokollierung eines neuen Befunds ohne vorheriges Review-Objekt verwenden Sie gate fast-track wie in (a).

Warum SCG mit Devil kombinieren

Devil's Advocate („壊しにいく“) und SCG teilen dieselbe Grundhaltung: vom Schlimmsten ausgehen, systematisch scannen, dann zusammenführen. SCG liefert die Lieferketten-Dimension eines Devil-Durchlaufs – was die Abhängigkeiten des Projekts hinter Ihrem Rücken tun könnten – zusammen mit anderen Linsen (Sicherheit/Korrektheit/Architektur/Benutzer/Betrieb).

Einschränkungen der Devil-Kombination

• SCG läuft schreibgeschützt; die Devil-Linse wird keine Korrekturen pushen. Verwenden Sie respond.sh separat, wenn Behebung erforderlich ist (mit expliziter Benutzerbestätigung).
• Die SCG-Ausgabe kann in großen Repositorys das Devil-Kontextbudget überschreiten; leiten Sie sie bei Bedarf durch tail -50.
• Für Polyglot-Repositorys führen Sie sowohl project-scan.sh als auch project-scan-py.sh aus und führen die Ergebnisse zusammen.

Haftungsausschluss

SCG ist ein Erkennungswerkzeug, keine Sicherheitsgarantie. Offen zu sagen, was es kann und was nicht, ist Teil des Designs.

Diese Software wird „wie besehen“ ohne jegliche Gewährleistung geliefert. Durch die Nutzung von Supply Chain Guard erkennen Sie Folgendes an und stimmen dem zu:

• Kein Ersatz für professionelle Sicherheit. SCG ist ein ergänzendes Erkennungswerkzeug, keine umfassende Sicherheitslösung. Es ersetzt keine professionelle Incident-Response-, Endpoint-Detection-and-Response-Software (EDR) oder Sicherheitsaudits.
• Keine Garantie für Erkennung. Ein CLEAR-Urteil bedeutet, dass keine Übereinstimmungen mit den bekannten Bedrohungsmustern des Werkzeugs gefunden wurden. Es bedeutet nicht, dass Ihr System oder Projekt frei von Kompromittierung ist. Neue, unbekannte oder modifizierte Angriffe werden möglicherweise nicht erkannt.
• Keine Garantie für Behebung. Die bereitgestellten Behebungsschritte (respond.sh) adressieren bekannte Indikatoren bestimmter Bedrohungen. Sie entfernen möglicherweise nicht alle Spuren einer ausgeklügelten Kompromittierung. Wenn Sie eine aktive Kompromittierung vermuten, beauftragen Sie ein professionelles Incident-Response-Team.
• Nutzung auf eigenes Risiko. Die Autoren haften nicht für Schäden, Datenverlust oder Sicherheitsvorfälle, die aus der Nutzung oder Unfähigkeit zur Nutzung dieses Werkzeugs entstehen. Dies umfasst, ist aber nicht beschränkt auf: falsch negative (übersehene Erkennungen), falsch positive (fälschliche Erkennungen) oder unbeabsichtigte Folgen der Ausführung von Behebungsskripten.
• Keine Rechts- oder Compliance-Beratung. Dieses Werkzeug erfüllt keine regulatorischen, Compliance- oder rechtlichen Anforderungen an Sicherheitsscans. Konsultieren Sie für Compliance-Bedürfnisse entsprechende Fachleute.

Einschränkungen

Zu verstehen, was SCG nicht kann, ist genauso wichtig wie zu wissen, was es kann.

Erkennungsgrenzen

Aktualität der Bedrohungsdatenbank

Die Datenbank der bekannten Bedrohungen (D.2 in SKILL.md) wird manuell gepflegt. Sie ist mit keinem Live-Bedrohungsfeed verbunden. Es besteht eine inhärente Latenz zwischen der Entdeckung eines neuen Lieferkettenvorfalls und der Aktualisierung dieser Datenbank.

• Zuletzt aktualisiert: 2026-05-27 (v4: Python-Unterstützung, BadHost CVE-2026-48710 hinzugefügt)
• Abdeckung: 3 npm-Bedrohungsfamilien (T001-T003) + 4 Python-Entführungs-/Typosquat-Einträge + 1 Python-CVE-gekennzeichneter Versioneintrag (BadHost)
• Python-Abdeckungsumfang (v4): hauptsächlich Lockfile-basiertes Scannen (uv.lock / poetry.lock / requirements.txt). Die CVE-gekennzeichnete Versionsebene ist Best-Effort – sie kennzeichnet nur Pakete, die mit _L3_CVE_LIST-Einträgen übereinstimmen und einer strengen Semver-Auswertung unterliegen, und ist für eine genaue Versionsübereinstimmung auf die Installation von packaging angewiesen.

Überprüfen Sie immer Querverweise mit Live-Quellen wie npm advisories, OSV.dev und Sicherheitsblogs von Anbietern, die im Abschnitt Referenzen aufgeführt sind.

Falsch-Positiv-Risiko

Die folgenden IOC-Pfade können in seltenen Fällen mit legitimer Software kollidieren:

Überprüfen Sie IOC-Funde immer vor der Durchführung von Behebungsmaßnahmen. Das Skript ioc-scan.sh meldet Funde zur menschlichen Überprüfung – es führt keine Aktionen aus. Das Skript respond.sh erfordert für jede destruktive Aktion eine explizite Bestätigung (Standard: NEIN), genau wegen dieses Risikos.

Einschränkungen des Netzwerkscans

• lsof-basierte Netzwerkprüfungen erkennen nur derzeit aktive Verbindungen. Ein C2-Beacon, der intermittierend verbindet, ist zum Scanzeitpunkt möglicherweise nicht aktiv.
• DNS-Cache-Prüfungen sind Best-Effort und betriebssystemabhängig. Gelöschte Caches zeigen keine historischen Verbindungen.
• Verschlüsselter getunnelter C2-Verkehr kann allein durch Port-/IP-Abgleich nicht erkannt werden.

Umfang

• npm/yarn und Python (pip/poetry/uv). Deckt nicht cargo, go modules oder andere Paket-Ökosysteme ab.
• Nur bekannte Bedrohungen. Dies ist ein Musterabgleichswerkzeug, keine Verhaltensanalyse-Engine.
• Punktueller Scan. Ergebnisse spiegeln den Zustand zum Zeitpunkt der Ausführung wider. Kontinuierliche Überwachung erfordert wiederholte Ausführung oder Integration in CI/CD.

Integritätsprüfung

Überprüfen Sie, ob Ihre Kopie von SCG nicht manipuliert wurde. Vergleichen Sie diese SHA-256-Prüfsummen mit Ihren lokalen Dateien:

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

Zur Überprüfung:```bash
shasum -a 256 scripts/*.sh scripts/*.ps1 SKILL.md

Hinweis: Diese Prüfsummen entsprechen der neuesten Version. Wenn Sie lokale Dateien geändert haben, weichen die Prüfsummen ab. Wenn SCG aktualisiert wird, wird dieser Abschnitt zusammen mit den Codeänderungen aktualisiert.

Lizenz

MIT

Erstellt von Eris — denn Ihre Abhängigkeiten sollten nicht die Angriffsfläche eines anderen sein.