Share
Beitragsbild zu Kaspersky warnt: KI-gesteuertes Slopsquatting gefährdet zunehmend Lieferketten

Kaspersky warnt: KI-gesteuertes Slopsquatting gefährdet zunehmend Lieferketten

9. Mai 2025

Wenn KI-Code auf erfundene Bibliotheken zugreift

KI-gestützte Code-Assistenten sind aus der Softwareentwicklung kaum noch wegzudenken. Laut Schätzungen stammt bereits rund 40 Prozent des neu geschriebenen Codes aus der Feder künstlicher Intelligenz – Tendenz steigend. Microsoft-CTO Kevin Scott geht sogar davon aus, dass dieser Anteil innerhalb der nächsten fünf Jahre auf 95 Prozent anwachsen könnte. Umso drängender wird die Frage, wie sich KI-generierter Code sinnvoll warten und zuverlässig absichern lässt.

Denn eines steht fest: Der Sicherheitsstandard solcher Codes gilt bislang als niedrig. Fachleute warnen, dass KI-Programme klassische Programmierfehler häufig reproduzieren – etwa SQL-Injektionen, eingebettete Zugangsdaten, unsichere Deserialisierung oder fehlerhafte Eingabevalidierung. Doch ein weiteres Risiko rückt zunehmend in den Fokus: sogenannte „Halluzinationen“ von großen Sprachmodellen (LLMs).

Eine neue Studie zeigt, wie solche Halluzinationen dazu führen, dass KI-Systeme Bibliotheken aufrufen, die gar nicht existieren. Und genau hier wird es brisant: Was, wenn Angreifer diese erfundenen Bibliotheken tatsächlich nachbauen und im Netz bereitstellen? Der scheinbar harmlose Programmierfehler könnte so zum potenziellen Einfallstor für Schadsoftware werden – und die automatische Codegenerierung zur Sicherheitsfalle.

Phantom-Bibliotheken: Wie KI sich Abhängigkeiten ausdenkt

In einer groß angelegten Studie haben Forschende das Halluzinationsverhalten von 16 populären KI-Modellen untersucht – mit einem klaren Fokus auf erfundene Code-Bibliotheken. Dazu ließen sie die Systeme insgesamt 576.000 Code-Beispiele in Python und JavaScript generieren. Das Ergebnis: Je nach Modell variiert die Tendenz zur Fantasie deutlich. GPT-4 und GPT-4 Turbo schnitten am besten ab – hier traten Phantom-Bibliotheken in weniger als 5 % der Fälle auf. Am häufigsten halluzinierte CodeLlama 7B, mit über 25 % fiktiven Abhängigkeiten.

Besonders kritisch: Die künstlich erfundenen Paketnamen sind oft keine Zufallsergebnisse. In 43 % der Fälle wiederholten sich dieselben Halluzinationen bei mehrfacher Generierung identischer Prompts. Teilweise ähnelten die Namen echten Bibliotheken bis auf einen Buchstaben – oder wurden aus anderen Programmiersprachen übernommen. Python-Code war mit 16 % weniger betroffen als JavaScript (21 %), doch bei neueren Technologien stieg die Halluzinationsrate deutlich an.

Selbst gängige Techniken zur Reduktion der Zufälligkeit, wie Temperatur- oder Top-k-Parameter, konnten die Zahl der falschen Abhängigkeiten nicht auf ein sicheres Niveau senken. Damit bleibt das Risiko bestehen, dass Angreifer die von der KI erfundenen Pakete bewusst nachbauen – und über diesen Umweg Schadcode einschleusen.

Was ist Slopsquatting?

All dies kann eine neue Generation von Angriffen auf Open-Source-Repositorys auslösen, die in Anlehnung an Typosquatting bereits als „Slopsquatting“ bezeichnet wird. In diesem Fall wird das Squatting nicht durch Namen mit Tippfehlern ermöglicht, sondern durch Namen aus AI-Slop (minderwertige Ausgabe). Da AI-generierter Code Paketnamen wiederholt, können Angreifer beliebte Modelle ausführen, wiederkehrende halluzinierte Paketnamen im generierten Code finden und echte – und bösartige – Bibliotheken mit denselben Namen veröffentlichen. Wenn jemand gedankenlos alle im KI-generierten Code referenzierten Pakete installiert oder der KI-Assistent die Pakete selbst installiert, wird eine bösartige Abhängigkeit in die kompilierte Anwendung eingeschleust, wodurch die Lieferkette einem vollwertigen Angriff ausgesetzt wird (ATT&CK T1195.001). Dieses Risiko wird mit dem Vormarsch des Vibe-Coding – bei dem der Programmierer Code schreibt, indem er der KI Anweisungen gibt, ohne den tatsächlich erzeugten Code auch nur anzusehen – noch deutlich steigen.

Angesichts der Tatsache, dass alle großen Open-Source-Repositorys im vergangenen Jahr von Dutzenden bösartiger Pakete heimgesucht wurden (1, 2) und im gleichen Zeitraum fast 20.000 bösartige Bibliotheken entdeckt wurden, können wir davon ausgehen, dass jemand versuchen wird, diese neue Art von Angriff zu automatisieren. Dieses Szenario ist besonders gefährlich für Amateurprogrammierer sowie für IT-Abteilungen in Unternehmen, die einige Automatisierungsaufgaben intern lösen.

Halluzinierte Pakete vermeiden: Wie sich KI sicher in der Softwareentwicklung einsetzen lässt

Obwohl es etablierte Richtlinien für den sicheren Einsatz von KI in der Softwareentwicklung gibt – etwa von OWASP oder NIST – sind viele davon komplex und in der Praxis schwer umzusetzen. Um das konkrete Risiko halluzinierter Pakete zu minimieren, empfehlen Sicherheitsexperten einige pragmatische Maßnahmen:

1. Automatisierte Code-Prüfung einführen

KI-generierter Code sollte denselben Sicherheitsprüfungen unterliegen wie manuell geschriebener. Dazu gehören statische Code-Analysen, Token-Scanning und die Prüfung auf gültige und sichere Abhängigkeiten – idealerweise eingebunden in die CI/CD-Pipeline, etwa mit Tools wie Kaspersky Container Security.

2. KI-Modelle mit sich selbst gegenprüfen

Große Sprachmodelle können auch zur Validierung ihres eigenen Codes genutzt werden. Sie lassen sich etwa auffordern, die Existenz und Popularität referenzierter Pakete zu prüfen oder mit einer gepflegten Bibliotheksdatenbank abzugleichen. Studien zeigen: Mit solchen Methoden ließ sich die Zahl halluzinierter Pakete bei bestimmten Modellen signifikant senken – wenn auch nicht auf null.

3. Kritische Komponenten von KI fernhalten

Für besonders sensible Softwareteile sollte der Einsatz von KI-Assistenz untersagt sein. Bei weniger kritischen Aufgaben empfiehlt sich ein strikter Code-Review-Prozess mit klarer Checkliste, die speziell auf KI-generierten Code ausgelegt ist.

4. Whitelisting statt Wildwuchs

Eine firmeneigene Liste zugelassener Bibliotheken verhindert, dass KI-Tools oder Entwickler eigenmächtig ungetestete Abhängigkeiten integrieren. Nur geprüfte Pakete aus internen Repositories sollten zur Auswahl stehen.

5. Schulung ist Pflicht

Entwickler müssen im Umgang mit KI-Werkzeugen ebenso geschult werden wie in den Grundlagen der KI-Sicherheit. Nur wer die Risiken kennt, kann sie auch vermeiden.

Quelle: Kaspersky

Redaktion AllAboutSecurity

Teile diesen Beitrag: