KI-Coding-Assistenten wie GitHub Copilot, Claude Code, Cursor oder ChatGPT haben die Art, wie Software entwickelt wird, grundlegend verändert. Entwickler schreiben schneller, finden schneller Lösungen und können Routineaufgaben delegieren. Das Problem: Diese Werkzeuge haben einen kritischen blinden Fleck. Sie schlagen Bibliotheken und Pakete vor – und niemand im Prozess prüft automatisch, ob diese Pakete sicher, aktuell oder überhaupt vertrauenswürdig sind. In einer Welt, in der Software-Lieferketten zunehmend angegriffen werden, ist das ein Risiko, das Unternehmen kennen müssen.
Wenn die KI eine Bibliothek empfiehlt – und niemand genauer hinschaut
Stellen Sie sich vor, Ihr Entwickler fragt ChatGPT oder Claude Code: „Wie komprimiere ich Bilder in Node.js?" Die KI antwortet mit einem vollständigen Code-Snippet inklusive npm install-Befehl für eine bestimmte Bibliothek. Der Entwickler führt den Befehl aus, der Code läuft – und schon ist ein Paket im Projekt, das nie auf Sicherheitslücken geprüft wurde, dessen letztes Update vor vier Jahren war und das von einem einzigen Maintainer ohne Backup betrieben wird. KI-Assistenten haben keinen Zugriff auf aktuelle Sicherheitsdatenbanken, können keinen npm audit ausführen und wissen nicht, ob ein Paket aktiv gewartet wird. Sie generieren Antworten, die plausibel klingen – und plausibel klingende Paketnamen sind leider ein bekanntes Einfallstor.
Bevor Sie ein von einer KI empfohlenes Paket installieren: Suchen Sie es auf npmjs.com. Wann wurde es zuletzt veröffentlicht? Wie viele wöchentliche Downloads hat es? Gibt es ein aktives GitHub-Repository? Ein Paket mit dem letzten Update vor drei Jahren und 200 wöchentlichen Downloads sollte ein Warnsignal sein.
Halluzinierte Paketnamen: Das „Slopsquatting"-Problem
KI-Modelle erfinden manchmal Paketnamen, die gar nicht existieren – sie halluzinieren. Klingt harmlos. Ist es nicht. Sicherheitsforscher haben dokumentiert, dass Angreifer systematisch beobachten, welche Paketnamen KI-Tools häufig vorschlagen, und diese Namen vorsorglich als eigene, bösartige Pakete auf npm registrieren. Das Phänomen nennt sich „Slopsquatting". Ein Entwickler führt npm install mit einem KI-generierten Befehl aus, findet das Paket tatsächlich – und merkt nicht, dass es von einem Angreifer erstellt wurde. Das Paket stiehlt Zugangsdaten, schleust einen Keylogger ein oder lädt eine Backdoor nach. Ähnlich funktioniert klassisches Typosquatting: crossenv statt cross-env, ein einzelner Buchstabe Unterschied, der teuer werden kann.
Software-Lieferketten sind das neue Einfallstor. Wer die eigene Entwicklung absichert, aber die Abhängigkeiten ignoriert, schließt die Haustür ab und lässt das Kellerfenster offen.
Verseuchte Pakete: Was in der Realität passiert ist
Das sind keine theoretischen Szenarien. 2021 wurde das Paket ua-parser-js kompromittiert, das zu diesem Zeitpunkt 15 Millionen wöchentliche Downloads verzeichnete. Ein Angreifer übernahm den npm-Account des Maintainers und veröffentlichte eine bösartige Version, die Passwörter und SSH-Schlüssel stahl. Betroffen waren unter anderem Build-Pipelines großer Technologieunternehmen. 2022 traf es node-ipc mit 40 Millionen wöchentlichen Downloads: Der Maintainer baute absichtlich Code ein, der auf Systemen in Russland und Weißrussland Dateien löschte – als politischer Protest zum Ukraine-Krieg. Ebenfalls 2022 wurden colors.js und faker.js vom Maintainer mit absichtlichen Endlosschleifen versehen. Faker.js hatte zu diesem Zeitpunkt über zwei Millionen wöchentliche Downloads. Weltweit fielen Build-Pipelines aus. Das verbindende Element aller dieser Vorfälle: Die betroffenen Pakete waren weit verbreitet, scheinbar seriös – und niemand hatte erwartet, dass ausgerechnet dort Schadsoftware auftauchen würde.
Führen Sie npm audit regelmäßig aus – idealerweise als fester Schritt in Ihrer CI/CD-Pipeline. Das Kommando prüft alle installierten Pakete gegen bekannte Sicherheitslücken und gibt konkrete Empfehlungen. Es ist kostenlos und in jeder aktuellen npm-Version enthalten.
Was passiert, wenn niemand aktualisiert
Im Dezember 2021 wurde Log4Shell (CVE-2021-44228) bekannt – eine kritische Sicherheitslücke in Apache Log4j, einer in Java-Projekten weltweit genutzten Logging-Bibliothek. Der CVSS-Score war 10.0, die höchstmögliche Bewertung. Die Lücke erlaubte es Angreifern, beliebigen Code aus der Ferne auszuführen – ohne Authentifizierung, mit einem einzigen manipulierten String. Innerhalb von Stunden nach der Veröffentlichung wurde sie aktiv ausgenutzt. Unternehmen, die ihre Java-Abhängigkeiten nicht aktuell hielten, standen vor einem Notfall in der Weihnachtswoche. Der Schaden weltweit: Schätzungen zufolge über zehn Milliarden Dollar. 2017 erlitt Equifax – einer der größten Kreditauskunfteien der USA – einen Datenbreach, bei dem persönliche Daten von 147 Millionen Menschen gestohlen wurden. Die Ursache: eine bekannte Lücke in Apache Struts2, für die bereits Monate zuvor ein Patch verfügbar gewesen war. Equifax hatte ihn nicht eingespielt. Das Muster ist immer dasselbe: Die Lücke ist bekannt, der Fix ist verfügbar – und es passiert trotzdem nichts.
Sicherheit als Prozess: Was jedes Entwicklungsteam braucht
Wer auf KI-gestützte Entwicklung setzt, braucht flankierende Sicherheitsprozesse. Erstens: Lockfiles konsequent nutzen und committen. package-lock.json oder yarn.lock stellen sicher, dass auf allen Systemen exakt dieselben Paketversionen installiert werden. Zweitens: Automatisierte Dependency-Updates einrichten. Tools wie Dependabot (kostenlos auf GitHub) oder Renovate öffnen automatisch Pull Requests, wenn neue Paketversionen – insbesondere Sicherheits-Patches – verfügbar sind. Drittens: npm audit in die CI/CD-Pipeline integrieren. Ein Build, der mit kritischen Sicherheitslücken in den Dependencies besteht, sollte fehlschlagen. Viertens: Paketreputation vor der Installation prüfen. Snyk Advisor gibt für npm-Pakete einen strukturierten Sicherheits-Score. Fünftens: KI-Empfehlungen als Vorschläge behandeln, nicht als verifizierten Stand der Technik. Jede npm install-Empfehlung einer KI ist ein Ausgangspunkt für eigene Prüfung – kein Endpunkt.
Fazit
KI-Coding-Assistenten sind mächtige Werkzeuge – und sie werden die Softwareentwicklung weiter verändern. Aber sie verlagern Verantwortung, sie ersetzen sie nicht. Wer KI-generierte Abhängigkeiten blind installiert und Pakete jahrelang nicht aktualisiert, baut auf einem Fundament, das andere ausgehöhlt haben könnten. Die gute Nachricht: Die Gegenmaßnahmen sind bekannt, größtenteils kostenlos und mit überschaubarem Aufwand umsetzbar. Was fehlt, ist oft nicht das Werkzeug, sondern das Bewusstsein für das Risiko.
Freiberuflicher IT-Berater mit M.Sc. Informatik (THM Gießen) und über 20 Jahren Praxiserfahrung. Schreibt über IT-Strategie, Software-Entwicklung und Digitalisierung im deutschen Mittelstand.
