Rivera beschreibt das Problem als Folge eines Temposprungs in der Softwareentwicklung: KI-Assistenten generieren oder ergänzen Code mitsamt Drittanbieter-Abhängigkeiten mit Maschinengeschwindigkeit, während klassische Prüfprozesse für die Aufnahme neuer Komponenten aus einer langsameren Entwicklungsrealität stammen. Nachgelagerte Software-Composition-Analysis-Scans nach dem Commit könnten mit diesem Tempo nur schwer Schritt halten, wenn ungeprüfte oder halluzinierte Abhängigkeiten bereits in den Code gelangt sind.

Der Text verweist auf eine USENIX-Security-Studie, die 16 populäre Codegenerierungsmodelle anhand von mehr als 500.000 Codebeispielen untersucht hat. Demnach existiert ein messbarer Anteil der von KI vorgeschlagenen Paketnamen in öffentlichen Registern gar nicht. Von den vorgeschlagenen Abhängigkeiten, die tatsächlich auf reale Pakete verweisen, enthalte fast die Hälfte bekannte CVEs oder veraltete Versionen.

Als konkreten Angriffsweg nennt Rivera Slopsquatting, auch als Ausnutzung von KI-Pakethalluzinationen bezeichnet. Wenn ein Modell einen Paketnamen vorschlägt, der in PyPI oder npm nicht existiert, könnten Angreifer diese Namen beobachten, registrieren und mit schädlicher Nutzlast versehen. Anschließend warteten sie darauf, dass automatisierte Entwicklerumgebungen oder CI/CD-Build-Systeme das Paket abrufen.

Dass dieser Vektor praktisch relevant ist, untermauert der Beitrag mit einem Beispiel aus Anfang 2026. Sicherheitsforscher hätten damals einen einzelnen halluzinierten npm-Paketnamen, „react-codeshift“, verfolgt, der aus 47 KI-generierten Agenten-Fähigkeiten in einem einzigen Commit stammte. Laut Text verbreitete sich dieser Name organisch über Forks in mehr als 230 Repositories, bevor ein Ingenieur bemerkte, dass kein Mensch das Paket je ausdrücklich ausgewählt hatte. Rivera betont, das Problem sei dabei keine böswillige Absicht des Entwicklers gewesen, sondern das völlige Fehlen von Aufnahmekontrollen.

Der Beitrag verortet die Folgen nicht nur in Unternehmen, sondern auch im Open-Source-Ökosystem. Dieselben KI-Assistenten, die in Unternehmensnetzen unkontrollierte Abhängigkeiten vorschlagen, erzeugten auch automatisierte Pull Requests für von der Community gepflegte Projekte. Das belaste menschliche Maintainer zusätzlich. Genannt werden unterschiedliche Richtlinien großer Projekte wie Kubernetes, Linux-Kernel, LLVM und Godot zu KI-unterstützten Beiträgen: Manche untersagten KI-generierten Code vollständig, andere erlaubten ihn nur dann, wenn ein menschlicher Beitragender die volle Verantwortung für jede hinzugefügte Zeile übernimmt.

Zusätzlich verweist Rivera auf eine Auswertung von CodeRabbit zu 470 Open-Source-Pull-Requests. Demnach wiesen von KI mitverfasste Beiträge 70 Prozent mehr Fehler auf als von Menschen verfasster Code, obwohl sie oberflächlich sauber wirkten. Wenn halluzinierte oder verwundbare Pakete bereits durch die Aufnahmeprozesse in Unternehmen gelangen, setze sich dieser Aufwand upstream fort, weil freiwillige Maintainer Abhängigkeiten prüfen müssten, die kein Mensch bewusst bewertet habe.

Auch die von Rivera angeführten Zahlen aus Kusaris Bericht „Application Security in Practice“ zielen auf diese Lücke: 85 Prozent der Organisationen nutzten KI-Coding-Assistenten, 38 Prozent setzten KI zur Unterstützung der Codeprüfung in der Pull-Request-Phase ein, aber nur 9 Prozent verfügten über dedizierte KI-AppSec-Kontrollen. Daraus leitet Rivera ab, dass das Kernproblem nicht die Genauigkeit der Modelle, sondern die Geschwindigkeit sei.

Als Gegenmaßnahmen nennt der Text drei Schritte: den direkten Zugriff von Entwicklerarbeitsplätzen und KI-Agenten auf ungeprüfte öffentliche Paketquellen während der Codevervollständigung zu blockieren, neu eingeführte Abhängigkeiten zunächst in isolierte Sandboxes für automatisierte Erreichbarkeits- und Schwachstellenanalysen zu leiten und den Aufnahme-Gateway selbst zu steuern, sodass empfohlene Pakete vorab gegen bösartige Typosquats und Slopsquatting-Ziele geprüft werden. Rivera beschreibt dies als Verlagerung der Verteidigung noch weiter nach links – also vor den Build und vor die eigentliche Übernahme der Abhängigkeit.