Abhaengigkeits-Review

Das Problem

Jede Abhaengigkeit ist eine Verbindlichkeit. Teams installieren Pakete fuer triviale Funktionalitaet und fuegen Kilobytes zu Bundles und Angriffsflaeche zur Supply Chain hinzu. Aufgegebene Pakete ohne Updates seit 2 Jahren sitzen in Produktion. Lizenzen, die mit kommerzieller Nutzung inkompatibel sind, lauern in transitiven Abhaengigkeiten. Ein einziges kompromittiertes Paket kann boesartigen Code in den Build injizieren.

Der Prompt

Pruefe die folgende Abhaengigkeitsliste. Handle als Supply-Chain-Sicherheitsanalyst, der jedes Paket auf Risiko, Notwendigkeit und Alternativen bewertet.

PAKETMANAGER: [npm / pnpm / yarn / pip / cargo]
PROJEKTTYP: [z.B. React SPA, Node.js API, Astro Static Site]

ABHAENGIGKEITSDATEI:
[package.json, requirements.txt oder Cargo.toml einfuegen]

Bewerte jede Abhaengigkeit in diesen Dimensionen:

1. **Notwendigkeit**
   - Koennte dies durch native Sprach-/Plattform-Features ersetzt werden?
   - Wird das Paket fuer eine einzelne Funktion genutzt, die in 10 Zeilen handgeschrieben werden koennte?
   - Ist es eine Dev-Dependency, die faelschlich als Production-Dependency gelistet ist?

2. **Gesundheit**
   - Letztes Publish-Datum und Release-Frequenz
   - Anzahl Maintainer (Bus-Faktor)
   - Offene Issues und PR-Rueckstau
   - Downloads pro Woche (wachsend, stabil, ruecklaeufig?)

3. **Bundle-Auswirkung**
   - Minified + gzipped Groesse
   - Unterstuetzt das Paket Tree-Shaking (ESM Exports)?
   - Sind leichtere Alternativen mit gleicher Funktionalitaet verfuegbar?

4. **Sicherheit**
   - Bekannte CVEs in aktueller oder juengster Version
   - Hat das Paket postinstall-Scripts?
   - Wie tief ist der transitive Abhaengigkeitsbaum?

5. **Lizenz-Compliance**
   - Ist die Lizenz mit kommerzieller Nutzung kompatibel (MIT, Apache-2.0, BSD)?
   - Gibt es Copyleft-Lizenzen (GPL, AGPL) im Abhaengigkeitsbaum?

Ausgabe als Abhaengigkeits-Gesundheitsbericht:
| Paket | Groesse | Letztes Update | Lizenz | Risiko | Aktion |

Beispielausgabe

## Abhaengigkeits-Review: 12 Pakete analysiert

| Paket | Groesse (gzip) | Letztes Update | Lizenz | Risiko | Aktion |
|-------|----------------|----------------|--------|--------|--------|
| lodash | 71.5 KB | 2024-02 | MIT | mittel | Durch lodash-es oder native Methoden ersetzen |
| moment | 67.9 KB | 2022-09 | MIT | hoch | Durch date-fns oder dayjs ersetzen |
| is-even | 0.1 KB | 2018-03 | MIT | hoch | Entfernen: n % 2 === 0 |

### Kritisch: Supply-Chain-Risiko — colors@1.4.1
Der Maintainer hat absichtlich eine Endlosschleife in v1.4.1 eingefuegt.
Aktion: Sofort entfernen oder auf 1.4.0 pinnen. chalk als Alternative.

Wann verwenden

Bei Projektstart, bei vierteljaehrlichen Abhaengigkeits-Audits oder wenn Bundle-Groesse zum Problem wird. Unverzichtbar vor Sicherheitsaudits und beim Uebernehmen eines Projekts mit unbekannter package.json.

Profi-Tipps

• Transitive Abhaengigkeiten pruefen — npm ls --all ausfuehren und die Ausgabe fuer ein vollstaendiges Bild einbeziehen.
• Native Ersetzungen anfordern — “Zeige fuer jedes Paket mit ‘ersetzen’ den nativen JS/Node.js-Code, der es ersetzt.”
• Audit automatisieren — npm audit in CI einrichten und Dependabot/Renovate fuer automatisierte Schwachstellenwarnungen.