Supply-Chain-Auditor

Das Problem

Die Anwendung ist nur so sicher wie ihre schwaechste Abhaengigkeit. Das durchschnittliche Node.js-Projekt zieht Hunderte transitiver Abhaengigkeiten ein, jede ein potenzieller Angriffsvektor. Typosquatting-Pakete imitieren beliebte Bibliotheken mit schaedlichem Code. Kompromittierte Maintainer-Konten pushen trojanisierte Updates. Postinstall-Skripte fuehren bei jedem npm install beliebigen Code aus. Eine einzige vergiftete Abhaengigkeit kann Secrets exfiltrieren, Backdoors installieren oder Kryptowaehrung schuerfen.

Der Prompt

Du bist ein Software-Supply-Chain-Sicherheitsspezialist. Pruefe die Abhaengigkeitskette meines Projekts auf Sicherheitsrisiken.

PAKETMANAGER: [z.B. npm, pnpm, yarn, pip, cargo]
PROJEKTTYP: [z.B. Webanwendung, API-Server, CLI-Tool, Bibliothek]

ZU PRUEFENDE DATEIEN:
[package.json, Lockfile-Auszug, .npmrc, CI/CD-Config einfuegen]

Diese Supply-Chain-Sicherheitschecks durchfuehren:

1. **Abhaengigkeits-Audit**: Bekannte CVEs auflisten
2. **Typosquatting-Erkennung**: Paketnamen gegen bekannte Typosquats pruefen
3. **Maintainer-Risiko**: Pakete mit Einzel-Maintainern oder kuerzlichen Eigentuemerwechseln
4. **Postinstall-Skripte**: Alle Pakete mit Install/Postinstall-Skripten auflisten
5. **Lockfile-Integritaet**: Pruefen ob Lockfile eingecheckt ist und mit package.json uebereinstimmt
6. **Phantom-Abhaengigkeiten**: Imports finden, die nicht in package.json stehen
7. **Abhaengigkeits-Aktualitaet**: Nicht gepflegte Pakete (2+ Jahre ohne Updates) markieren
8. **Lizenz-Compliance**: Auf Copyleft-Lizenzen in Produktionsabhaengigkeiten pruefen
9. **Bundle-Groesse**: Aufgeblaehte Abhaengigkeiten mit leichteren Alternativen identifizieren
10. **Transitive Tiefe**: Tief verschachtelte Abhaengigkeitsketten (>5 Ebenen) markieren

Fuer jedes gefundene Risiko:
- Risikostufe und betroffenes Paket
- Empfohlene Aktion (aktualisieren, ersetzen oder entfernen)

Einen automatisierten CI-Check fuer meine Pipeline bereitstellen.

Beispielausgabe

## Supply-Chain-Audit: 6 Risiken gefunden

### KRITISCH: Bekannte Schwachstelle in lodash@4.17.19
CVE-2021-23337: Prototype Pollution ueber set/setWith-Funktionen.
Loesung: Auf lodash@4.17.21 aktualisieren oder durch native Alternativen ersetzen.

### HOCH: Postinstall-Skript in electron-builder
Fuehrt download-electron.js bei jeder Installation aus — laedt 80MB Binary herunter.
Risiko: Koennte kompromittiert werden, um Malware herunterzuladen.

Wann verwenden

Supply-Chain-Audits bei jeder neuen Abhaengigkeit, im CI/CD bei jedem Pull Request und woechentlich fuer Produktionsprojekte ausfuehren. Unverzichtbar nach Major-Version-Upgrades, beim Einbinden von Open-Source-Abhaengigkeiten oder bei unerwarteten Paketen im Lockfile.

Profi-Tipps

• Alles locken — Lockfile immer committen und npm ci (nicht npm install) im CI verwenden fuer reproduzierbare Builds.
• Postinstall-Skripte auditieren — npm ls --all | grep -E "postinstall|preinstall" ausfuehren, um Pakete zu finden, die Code bei der Installation ausfuehren.
• Socket.dev oder Snyk nutzen — automatisiertes Supply-Chain-Monitoring erkennt Bedrohungen schneller als manuelle Audits.
• Exakte Versionen fuer kritische Deps pinnen — exakte Versionen (ohne ^ oder ~) fuer Authentifizierungs-Bibliotheken und Krypto-Pakete verwenden.