Wenn KI Pakete erfindet, die es nicht gibt
KI-Coding-Tools schlagen beim Generieren von Code regelmäßig Software-Bibliotheken vor, die schlicht nicht existieren. Untersuchungen beziffern den Anteil erfundener Paketnamen auf rund 20 Prozent aller Vorschläge. Für sich genommen wäre das ein Ärgernis – ein fehlgeschlagener Installationsbefehl, schnell bemerkt und korrigiert.
Warum daraus ein Angriffsmuster wird
Der eigentliche Risikofaktor ist Wiederholbarkeit: 58 Prozent der erfundenen Paketnamen tauchen bei ähnlichen Prompts wiederholt auf – dieselbe Anfrage oder ähnliche Formulierungen führen verlässlich zum selben, nicht existierenden Namen. Genau dieses Muster machen sich Angreifer zunutze: Sie registrieren gezielt Schadcode unter erfundenen, aber vorhersagbar wiederkehrenden Paketnamen, in der Erwartung, dass Entwickelnde diesen Namen früher oder später tatsächlich installieren.
Ein Risiko, das sich mit bestehenden Lücken verbindet
Slopsquatting tritt selten isoliert auf: KI-generierter Code bringt oft zusätzlich bekannte Schwachstellenmuster mit (siehe voriges Modul) – unsichere API-Aufrufe, fehlende Fehlerbehandlung, unzureichende Eingabeprüfung. In Kombination mit einer halluzinierten, durch Schadcode ersetzten Abhängigkeit entsteht so ein zusammengesetztes Risiko für die gesamte Software-Lieferkette, nicht nur für eine einzelne Zeile Code.
Praxis-Teil: drei konkrete Schutzmaßnahmen
Sicherheitsforschende empfehlen drei konkrete Gegenmaßnahmen, die sich direkt in bestehende Entwicklungsprozesse einbauen lassen: erstens jeden von einer KI vorgeschlagenen Paketnamen vor der Installation gegen die offizielle Paket-Registry verifizieren, zweitens Versionen fest pinnen statt automatische Updates zuzulassen, drittens Hash-Prüfungen für installierte Pakete durchführen. Alle drei Maßnahmen sind Standard-Praktiken der Software-Lieferketten-Sicherheit – bei KI-generiertem Code werden sie vom optionalen Extra zur Notwendigkeit.