Entwickler nutzen einen KI-Coding-Assistenten, der ein Paket vorschlägt, das nicht auf Ihrer freigegebenen Liste steht. Was ist das Risiko, und was tun Sie?
Kurzantwort
Das Risiko ist Paket-Halluzination: Modelle können nicht existierende Bibliotheken vorschlagen, und Angreifer können diese Namen mit Schadcode registrieren, den Entwickler dann installieren. Behandeln Sie KI-Vorschläge als nicht vertrauenswürdige Eingabe: Prüfen Sie, ob das Paket existiert und legitim ist, installieren Sie nur über einen internen Proxy mit Allowlist, pinnen Sie Versionen, scannen Sie Abhängigkeiten und verlangen Sie menschliche Prüfung KI-generierter Abhängigkeitsänderungen.
Dieses Szenario prüft, ob Sie KI-Ausgaben als nicht vertrauenswürdige Eingabe behandeln und mit Supply-Chain-Kontrollen verbinden, statt das Werkzeug nur zu verbieten.
Das Risiko
OWASP führt Fehlinformation (LLM09:2025) als Top-Risiko für LLMs und nennt unsichere Codegenerierung: Modelle können „unsichere oder nicht existierende Code-Bibliotheken“ vorschlagen. Die Seite beschreibt Angreifer, die unter häufig halluzinierten Namen bösartige Pakete veröffentlichen, die Entwickler unwissentlich installieren. Übervertrauen, „Nutzer vertrauen KI-generierten Inhalten übermäßig und prüfen deren Richtigkeit nicht“, verschärft das.
Was Sie tun
Zuerst: den unbekannten Namen nicht installieren. Prüfen Sie, ob das Paket existiert, wer es pflegt, wann es erstellt wurde und ob es zum Bedarf des Codes passt. Langfristig strukturell absichern: Installationen über einen internen Registry-Proxy mit Allowlist leiten, Versionen per Lockfile pinnen, Software Composition Analysis laufen lassen und Abhängigkeitsänderungen im Pull Request prüfen lassen.
Abgleich mit OWASP-Maßnahmen
OWASP empfiehlt Gegenprüfung und menschliche Aufsicht, automatische Validierung wichtiger Ausgaben, sichere Programmierpraktiken und Schulung der Nutzer zu den Grenzen von LLMs.
Warum die Distraktoren verlocken
„Das Modell hat es validiert“ ist genau der Übervertrauensfehler. „In Produktion testen“ und „alles verbieten“ sind die Extreme.
Was Interviewer hören wollen
Paket-Halluzination benennen, Ausgabe als nicht vertrauenswürdig behandeln und gestufte, verhältnismäßige Kontrollen vorschlagen.
Wahrscheinliche Anschlussfragen
- Wie unterscheidet sich das von klassischer Dependency Confusion oder Typosquatting?
- Welche CI-Pipeline-Kontrollen würden ein frisch veröffentlichtes bösartiges Paket erkennen?
- Welche Kennzahlen zeigen, ob Entwickler KI-generiertem Code zu sehr vertrauen?