Vor nicht allzu langer Zeit war der Endpunkt eines Entwicklers eine bekannte Größe. Jemand schrieb Code, zog ein paar Abhängigkeiten, die er selbst geprüft hatte, ließ Builds gegen eine CI-Pipeline laufen und pushte in ein Repository. Das Bedrohungsmodell dazu konnten die meisten Sicherheitsteams auf ein Whiteboard zeichnen.
Dieses Modell bekommt gerade Risse.
GitHub Copilot, Claude Code, Cursor und die übrigen KI-Coding-Assistenten sind von der Neuheit zum Standard geworden. Im Stack Overflow Developer Survey 2025 gaben 84 Prozent der Entwickler an, KI-Tools in ihrem Arbeitsablauf zu nutzen oder dies zu planen, und 51 Prozent der professionellen Entwickler setzen sie täglich ein. Das verändert spürbar, wie Code geschrieben wird, welche Pakete ins Projekt gelangen und was auf Entwicklerrechnern ausgeführt wird. Und es passiert größtenteils unter dem Radar, mit dem die meisten Organisationen Endpunktrisiken betrachten.
Was sich am Endpunkt verändert hat
Klassische Bedrohungsmodellierung für eine Entwickler-Workstation ging von einem recht überschaubaren Satz an Verhaltensweisen aus. Man erfasste die IDE, den Paketmanager, den Versionskontroll-Client und vielleicht ein paar Build-Tools. Riskante Ausführungen kamen aus bekannten Quellen: eine bösartige Abhängigkeit, ein kompromittiertes Maintainer-Konto, ein Phishing-Link.
KI-Coding-Assistenten haben diese Angriffsfläche auf eine Weise erweitert, über die zu selten gesprochen wird.
Zum einen beziehen sie Code aus einem probabilistischen Modell statt aus einem bekannten Repository. Das Ergebnis sieht aus, als hätte der Entwickler es selbst geschrieben, doch die Vorschläge sind statistische Rekonstruktionen von Mustern, die das Modell im Training gesehen hat. Für eine automatisch vervollständigte Funktion gibt es keine Nachweiskette, wie sie für eine eingebundene Bibliothek existiert.
Zum anderen führen agentenbasierte Workflows wie Claude Code oder der Agent-Modus von Cursor zunehmend selbst Befehle aus. Statt pip install requests nur vorzuschlagen, erledigt der Assistent die Installation gleich mit, schreibt und startet Skripte und ändert Dateien. Der Entwickler wird so zum Prüfer von Aktionen, die in seinem Namen ablaufen, und auch einem aufmerksamen Prüfer rutscht gelegentlich etwas durch.
Dann ist da noch die Paketebene, und dort wird es konkret.
Slopsquatting findet bereits statt
Schlägt ein Coding-Assistent ein Paket vor, das es nicht gibt, erhalten Sie einen Installationsfehler. Für sich genommen ist das harmlos, doch Angreifer haben längst bemerkt, welche Paketnamen Modelle gern erfinden, und genau diese auf npm oder PyPI registriert, samt Schadlast. Diese Angriffsart heißt Slopsquatting.
Ein Paper der USENIX Security 2025, das 576.000 Codebeispiele aus 16 verbreiteten LLMs analysierte, stellte fest, dass 5,2 Prozent der von kommerziellen Modellen und 21,7 Prozent der von Open-Source-Modellen empfohlenen Pakete halluziniert waren. Das ergibt Hunderttausende eindeutige, frei erfundene Paketnamen. Nicht alle davon werden besetzt, aber Angreifer brauchen keine hohe Trefferquote, wenn sie Modellausgaben in großem Umfang beobachten und die am häufigsten wiederkehrenden Halluzinationen registrieren können.
Das Tückische an Slopsquatting ist, dass es die meisten Heuristiken umgeht, die Sicherheitsteams rund um Supply-Chain-Angriffe aufgebaut haben. Ein Typosquatting-Paket setzt darauf, dass sich ein Entwickler vertippt. Eine bösartige Abhängigkeit verlangt, dass der Angreifer einen echten Maintainer kompromittiert oder einen echten Nutzer täuscht. Für Slopsquatting genügt es, dass das Modell selbstbewusst einen plausibel klingenden Namen vorschlägt.
Die Herkunft ist unklar geworden
Die Arbeit an Software Bills of Materials (SBOM) beruhte in den vergangenen Jahren auf einer einfachen Prämisse: Sie sollten wissen, was in Ihrer Software steckt, woher es stammt, wer es pflegt und welche Version Sie einsetzen.
KI-Assistenten verkomplizieren das auf subtile Weise. Übernimmt ein Entwickler eine 40-zeilige Autovervollständigung, die eine aus Trainingsdaten adaptierte Funktion enthält, welche Herkunft hat dieser Code dann? Er ist weder ein Stack-Overflow-Snippet, nach dem Sie Ihre Codebasis per grep durchsuchen könnten, noch eine eingebundene Abhängigkeit, die in der package.json erfasst ist. Er liegt einfach in Ihrem Repository und ist von allem anderen, was der Entwickler geschrieben hat, nicht zu unterscheiden.
Dasselbe gilt für Paketvorschläge im Chat. Fragt ein Entwickler einen Assistenten, welche Bibliothek sich für ein bestimmtes Parsing-Problem eignet, und der Assistent nennt eine, dann stammt dieser Vorschlag weder von Ihrer Liste freigegebener Anbieter noch aus Ihrer internen Paket-Registry oder einem Prüfprozess. Er beruht auf der besten Vermutung eines Modells darüber, welche Pakete existieren und welches zur Frage passt.
Ein Grund, die Tools zu verbieten, ist das nicht, denn ein Verbot wäre weder praktikabel noch sinnvoll. Es bedeutet aber, dass die Prüfung von Abhängigkeiten bis in die Gesprächsebene reichen muss und sich nicht auf das Lockfile beschränken darf.
Was mit erhöhten Rechten läuft
Am meisten Sorgen sollte Sicherheitsteams bereiten, was der KI-Assistent am Ende lokal ausführt, und mit wessen Rechten.
Der s1ngularity-Angriff auf das Build-System Nx im August 2025 ist bislang das deutlichste Beispiel. Angreifer kompromittierten das beliebte npm-Paket und betteten Malware ein, die unter anderem nach lokal installierten KI-Kommandozeilentools wie Claude Code, Gemini und Amazon Q suchte. Fand sie welche, startete sie diese mit freizügigen Flags wie –dangerously-skip-permissions und –yolo, um den Dateisystemzugriff der KI selbst für den Diebstahl von Zugangsdaten einzuspannen. Über tausend gültige GitHub-Tokens, npm-Tokens, SSH-Schlüssel und Cloud-Zugangsdaten flossen ab, bevor GitHub die Repositories der Angreifer abschalten konnte.
Dieses Angriffsmuster ist neu. Die Malware machte die KI-Tools des Entwicklers zu ihrem Komplizen, und das funktionierte unter anderem deshalb, weil Entwickler ihren KI-Assistenten im Sinne der Geschwindigkeit oft denselben Zugriff einräumen, den sie selbst haben: volle Lese- und Schreibrechte auf ihr Home-Verzeichnis, die Möglichkeit, beliebige Befehle auszuführen, und Zugriff auf ihre Cloud-Zugangsdaten und Quellcode-Repositories.
Hat der Entwickler dauerhafte Administratorrechte auf seinem Endpunkt, gilt das auch für alles, was die KI in seinem Namen ausführt.
Was das für den Blick auf Entwickler-Endpunkte bedeutet
Bevor es um Technik geht, verlangt das ein Umdenken. Entwicklerrechner waren schon immer ein privilegierter Bereich, aber man ging davon aus, dass der Mensch an der Tastatur die Entscheidungen trifft. Mit KI-Assistenten im Ablauf verteilen sich Entscheidungen darüber, was installiert, ausgeführt und gelesen wird, zunehmend zwischen Mensch und Modell. Das Modell ist schnell und selbstsicher, liegt aber in einem nicht zu vernachlässigenden Anteil der Fälle falsch.
Einige Grundsätze, über die es sich nachzudenken lohnt:
- Behandeln Sie von KI vorgeschlagene Pakete standardmäßig als nicht vertrauenswürdig. Gehen Sie damit so um wie mit einem Paket, das Ihnen ein Fremder in einem Internetforum empfiehlt. Prüfen Sie, ob es existiert, sehen Sie sich Veröffentlichungsdatum und Maintainer-Historie an und achten Sie auf die Warnsignale, die Angreifer hinterlassen, wenn sie eine entdeckte Halluzination möglichst schnell ausnutzen wollen.
- Lassen Sie KI-Agenten nicht mit mehr Rechten laufen, als sie brauchen. Das ist schlicht Least Privilege, angewandt auf einen neuen Akteur. Braucht der Entwickler für seine Arbeit keine dauerhaften Admin-Rechte, braucht sie auch der Assistent nicht, der in seinem Namen arbeitet. Just-in-Time-Rechteausweitung, beschränkt auf konkrete Aufgaben, begrenzt den Wirkungsradius eines kompromittierten Pakets oder eines fehlgeleiteten Modells.
- Prüfen Sie, was der Assistent getan hat. Die meisten Coding-Assistenten protokollieren ihre Aktionen, doch diese Protokolle landen selten im selben Audit-Trail wie die übrige Endpunktaktivität, obwohl sie dort hingehören. Geht etwas schief, wollen Sie nachvollziehen können, was installiert, was ausgeführt und welche Dateien angefasst wurden.
- Behalten Sie die Paketebene im Blick. Tools zur Herkunftsprüfung von Abhängigkeiten, Lockfile-Reviews und Pre-Commit-Checks sind nicht neu, aber Menge und Quelle neuer Abhängigkeiten, die in Projekte gelangen, haben sich verändert. Prozesse, die funktionierten, als Entwickler einmal pro Sprint von Hand Abhängigkeiten hinzufügten, halten womöglich nicht mehr, wenn ein Agent sie mitten im Gespräch ergänzt.
Ein anderes Bedrohungsmodell
Daraus folgt weder, dass KI-Coding-Assistenten schlecht sind, noch, dass Organisationen sie verbieten sollten. Die Produktivitätsgewinne sind real, auch wenn sie ungleichmäßiger ausfallen, als das Marketing vermuten lässt. Die Zahlen von Stack Overflow für 2025 zeigen, dass das Vertrauen der Entwickler in KI-Ausgaben gesunken ist, während die Nutzung zunahm: Nur 29 Prozent der Entwickler geben an, der Genauigkeit von KI zu vertrauen. Das ist vermutlich eine gesündere Ausgangslage als pauschale Begeisterung.
Der Punkt ist vielmehr, dass das Bedrohungsmodell, das Ihr Team vor zwei Jahren erstellt hat, vermutlich nichts davon berücksichtigt. Es geht von einem Entwickler aus, der Abhängigkeiten bewusst auswählt, Befehle absichtlich ausführt und sich in einer selbst gebauten Sandbox bewegt. Keine dieser Annahmen trifft heute noch ohne Weiteres zu.
Das Modell zu aktualisieren heißt anzuerkennen, dass der Entwickler-Endpunkt inzwischen eine hybride Umgebung ist: teils menschlicher Arbeitsplatz, teils Ausführungsumgebung für KI, teils Pipeline in Ihren Produktionscode. Ihn gut abzusichern heißt, die KI-Ebene so genau zu prüfen wie jeden anderen privilegierten Prozess auf einem sensiblen Rechner.
Still und leise ist daraus bereits ein anderes Bedrohungsmodell geworden als das, mit dem die meisten Teams arbeiten. Je früher sich das ändert, desto kleiner fällt die Überraschung aus, wenn die nächste Kampagne nach dem Muster von s1ngularity zuschlägt.
Dieser Blog wurde ursprünglich auf Englisch auf unserer Website veröffentlicht. Das Original finden Sie hier.
