TL; DR
Was uns die ENISE 2026 über die Sicherheit von KI-Codierungsagenten gelehrt hat
Die KI schreibt bereits Ihren Code. Die Entscheidung, was in die Produktion geht, liegt weiterhin bei Ihnen.
- Ein Satz genügte: Eine im Titel eines GitHub-Issues versteckte Aufforderung veranlasste einen KI-Triage-Agenten, eine Kette von Ereignissen auszulösen, die in einem unerlaubte Veröffentlichung von Cline, ein Programmierassistent mit mehr als fünf Millionen Nutzern.
- Es war keine CVE beteiligt: Der Angriff nutzte fünf fehlende Kontrollmechanismen aus, keine klassische Schwachstelle, sodass herkömmliche Scanner nichts zu erkennen hatten.
- Der Engpass hat sich verlagert: KI schreibt Code und findet schnell Sicherheitslücken. Die sichere Integration des Codes und die Validierung der gefundenen Schwachstellen stellen nun die eigentliche Herausforderung dar.
- Codierungsagenten sind Teil Ihrer Lieferkette: Angreifer zielen auf alles ab, was Ihren Code schreibt: erfundene Paketnamen, manipulierte Abhängigkeiten, sogar auf die KI-Assistenten auf dem Laptop eines Entwicklers.
Der erste Schritt: Beantworten Sie vier Fragen. Welche Akteure sind in Ihrem Entwicklungsprozess tätig, was können sie einbringen, was ist Ihr pipelines können ausgeführt werden, und welche Ergebnisse lassen sich tatsächlich überprüfen?
Auf der ENISE 2026 in León eröffnete unser CEO Jesús Cuadrado seinen Vortrag über die Sicherheit von KI-Programmieragenten mit einer Geschichte, nicht mit einer Folie voller Statistiken. Hier ist, was er dem Publikum erzählte, und die vier Fragen, die er jedem Teilnehmer stellte. CISO mit.
Ein Satz genügte.
Anfang des Jahres demonstrierte ein Sicherheitsforscher, dass man eine gefälschte Version eines von Millionen Entwicklern genutzten Programmierassistenten veröffentlichen kann – ganz ohne Sicherheitslücke, Zero-Day-Schwachstelle oder gestohlenes Passwort. Dazu genügte ein einziger Satz im Titel eines GitHub-Issues.
Das Tool war Cline, ein beliebter Open-Source-Programmierassistent. Wie bei vielen Projekten heutzutage hatte das Team einen Teil seiner Arbeit mithilfe von KI automatisiert: Ein Agent las jedes neue GitHub-Issue, klassifizierte es und antwortete. Um diese Aufgabe zu erfüllen, benötigte der Agent Terminalzugriff und wurde bei Issues ausgeführt, die von beliebigen Nutzern im Internet erstellt wurden. Der Forscher Adnan Khan nannte die Angriffskette „Clinejection“, und Simon Willison hat … eine klare Zusammenfassung, wie es funktionierte.
Die Kette brach an fünf Stellen:
- Externer Text wurde zu Anweisungen. Der Titel des Problems wurde direkt in die Eingabeaufforderung des Agenten übernommen, sodass eine Anfrage zur Installation eines Tools wie ein Befehl aussah.
- Der Agent hatte mehr Macht, als er benötigte. Es war eigentlich dazu da, Probleme zu priorisieren, aber es konnte auch Befehle ausführen, also tat es das auch.
- Triage und Freigabe nutzten einen gemeinsamen Cache. Das installierte Tool hat den CI-Cache verfälscht, und der Release-Workflow hat dies übernommen.
- Für die Releases wurde ein langlebiges Token verwendet. Nachdem der Cache manipuliert worden war, war das npm-Veröffentlichungstoken in Reichweite.
- Niemand hat die Veröffentlichung genehmigt. Für keine Version war eine menschliche Überprüfung vor der Auslieferung erforderlich.
Wochen später wurde die Sicherheitslücke ausgenutzt und eine unautorisierte Version, cline@2.3.0, veröffentlicht. Diese blieb etwa acht Stunden online und wurde rund viertausend Mal installiert. Diesmal installierte die Schadsoftware lediglich einen weiteren KI-Agenten. Es hätte sich um einen Credential-Stealer oder Ransomware handeln können.
Beachten Sie, was fehlte: keine SQL-Injection, keine CVE, nichts, was ein herkömmlicher Scanner erkennen würde. Wer also hat entschieden, dass diese Version veröffentlicht werden konnte?
Niemand.
Fünf fehlende Bedienelemente und was jedes einzelne schließt
Jedes Glied in der Clinejection-Kette war eine fehlende Kontrollinstanz. Für keine dieser Kontrollinstanzen war eine CVE-Kennzeichnung zur Ausnutzung erforderlich.
| Glied in der Kette | Was fehlte | Die Steuerung, die es schließt |
|---|---|---|
| 1. Titel der Ausgabe | Nicht vertrauenswürdiger Text gelangte direkt in die Eingabeaufforderung des Agenten. | Behandeln Sie alle externen Eingaben als nicht vertrauenswürdig und halten Sie sie von den Agentenanweisungen fern. |
| 2. Triage-Agent | Ein Triage-Agent könnte jeden beliebigen Befehl ausführen. | Prinzip der minimalen Berechtigungen: Jedem Agenten sollten nur die Werkzeuge zur Verfügung gestellt werden, die er für seine Aufgabe benötigt. |
| 3. Gemeinsamer Cache | Triage- und Release-Workflows verwendeten denselben Cache-Schlüssel. | Arbeitsabläufe isolieren und überprüfen pipeline Konfiguration als Code |
| 4. npm-Token | Die Veröffentlichungen basierten auf einem langlebigen Veröffentlichungstoken. | Kurzfristige, zeitlich begrenzte Berechtigung zum Veröffentlichen |
| 5. Freisetzung | Keine menschliche Genehmigung oder Überprüfung vor der Veröffentlichung | Für jede Veröffentlichung ist eine Genehmigung und ein unterzeichneter Herkunftsnachweis erforderlich. |
Das Schreiben von Code ist nicht länger der Flaschenhals.
Cline ist kein Einzelfall. Es ist ein Vorbote. KI-Programmieragenten schreiben, installieren und commit Sie programmieren in einem Tempo, für das kein Überprüfungsprozess ausgelegt ist, und selbst KI-Labore berichten, dass sie Änderungen schneller integrieren, als ihre eigenen Tools damit umgehen können.
Der Engpass hat sich verlagert. Code zu schreiben ist günstig. Ihn sicher zu integrieren nicht.
Schwachstellen zu finden ist billig. Zu wissen, welche davon echt sind, nicht.
KI ist auch sehr gut darin, Schwachstellen aufzuspüren. Was sie aber nicht von allein kann, ist, Ihnen zu sagen, welche davon tatsächlich vorhanden sind.
Die Entwickler von curl, der Bibliothek, die auf Milliarden von Geräten läuft, machten dies auf schmerzhafte Weise deutlich. Die meisten der eingegangenen Sicherheitsberichte waren keine echten Schwachstellen, doch jeder einzelne band die Mitglieder eines kleinen Freiwilligenteams stundenlang. Im Januar 2026 curl hat sein Bug-Bounty-Programm beendetunter Verweis auf die Flut von qualitativ minderwertigen, KI-generierten Berichten.
Dieselbe Technologie, die KI-gestützte Datenanalyse, kann entweder Hunderte von echten Erkenntnissen oder eine Flut von irrelevanten Daten liefern. Der Unterschied liegt darin, wer diese validiert und welche Kosten damit verbunden sind.
Ihr Codierungsagent ist nun Teil Ihrer Lieferkette.
Angreifer haben die logische Schlussfolgerung gezogen: Wenn Agenten den Code schreiben, warum sollte man dann den Code angreifen? Man greift denjenigen an, der ihn schreibt.
- Slopsquatting. Untersuchungen zu KI-generiertem Code haben ergeben, dass Modelle regelmäßig nicht existierende Pakete empfehlen und dabei oft dieselben erfundenen Namen verwenden. Ein Angreifer muss lediglich ein Paket registrieren und warten.
- KI-Assistenten wandten sich gegen ihre Besitzer. Beim s1ngularity-Angriff auf das beliebte Build-Tool Nx suchte die Malware auf dem Rechner des Entwicklers nach KI-Programmierassistenten und forderte diese auf, geheime Informationen wie .env-Dateien, SSH-Schlüssel und Cloud-Tokens zu finden. Die KI des Opfers selbst erledigte die Arbeit des Angreifers.
Die Angriffsfläche beschränkt sich nicht mehr nur auf Ihren Code. Sie umfasst alles, was für Sie Code schreibt. Viele dieser Risiken sind nun in der Datenbank abgebildet. OWASP Top 10 für LLM-Bewerbungen und in den OWASP Top 10 für agentenbasierte Anwendungen, die wir in unserem Leitfaden erläutern. OWASP Agentic AI Top 10.
Sicherheit von KI-Codierungsagenten: Vier Fragen pro Tag CISO sollte in der Lage sein, diese Frage zu beantworten.
Jesús hat all dies in vier Fragen zusammengefasst. Versuchen Sie, diese für Ihre eigene Organisation zu beantworten:
- Welche Akteure und Modelle wirken heute in unserer Entwicklung? Nicht die, die Sie genehmigt haben: die, die bereits vorhanden sind. IDE-Assistenten, GitHub-Bots, Agenten, die jemand eingerichtet hat, um Zeit zu sparen.
- Was können sie in unsere Software einbringen? Erfundene Pakete, Köderabhängigkeiten, IDE-Erweiterungen, MCP-Server, Modelle, die von beliebigen Orten heruntergeladen wurden.
- Was können wir pipelines wird ausgeführt, und mit welchen Berechtigungen? In Cline reichte ein gemeinsamer Cache aus, um das Veröffentlichungstoken zu erreichen.
- Welche der uns mitgeteilten Erkenntnisse können wir tatsächlich überprüfen?
Die vierte Frage ist wichtiger, als es zunächst scheint: Man kann sich nicht auf die Selbstdarstellung eines Agenten verlassen. Man benötigt unabhängige Beweise.
Wie beantwortet Xygeni diese Fragen?
Schau, was es dort gibt. Xygeni KI-Sicherheit Es erstellt ein Inventar der Modelle, Agenten, MCP-Server und KI-Programmierwerkzeuge in Ihren Repositories und ordnet die Risiken den OWASP Top 10 für LLM-Anwendungen zu. Man kann nur steuern, was man kennt.
Verhindere, dass alles hineingelangt. Frühwarnung vor Malware Erkennt schädliche Pakete, bevor eine Signatur existiert, und ist in unserem kostenlosen Tarif enthalten. Xygeni Shield blockiert schädliche Pakete auf Entwickler-Workstations, bevor sie installiert werden können, und erzwingt ein Mindestalter für Pakete, IDE-Erweiterungen und Plugins, wodurch das Zeitfenster geschlossen wird, auf das diese Angriffe angewiesen sind.
Beschütze die pipeline. CI/CD Sicherheitsprüfungen umfassen Arbeitsabläufe, Berechtigungen und Geheimnisse. Build Security fügt Unterschrift hinzu SLSA Bestätigungen, damit Sie nachweisen können, dass das, was Sie veröffentlicht haben, auch das ist, was Sie gebaut haben. Genau das ist bei Cline gescheitert.
Untermauern Sie Ihre Aussagen mit Beweisen, nicht mit Meinungen. Hier verspricht KI am meisten und liegt am häufigsten falsch. Ein Ergebnis, das sich bei jeder Ausführung ändert, kann weder als Beweismittel für einen Prüfer noch als Kontrollkriterium dienen. pipelineBei Xygeni trifft die KI also keine Entscheidungen. Im KI-Penetrationstesting plant ein LLM den Angriff wie ein Penetrationstester, doch ein deterministisches Orakel entscheidet anhand eines realen und sicheren Signals, ob er erfolgreich war. Jedes Ergebnis ist entweder ausnutzbar, nicht ausnutzbar oder unklar und beinhaltet einen wiederholbaren Proof of Concept, den Sie Ihrem Auditor oder Ihrem Vorstand präsentieren können.
Die KI macht Vorschläge. Ein deterministisches System entscheidet. Sie behalten die Beweise.
Die decisIon gehört immer noch dir.
Jesús schloss dort, wo er begonnen hatte. Eine Version von Cline wurde ohne Autorisierung ausgeliefert, nicht etwa aus Nachlässigkeit des Teams, sondern weil niemand rechtzeitig die richtigen Fragen gestellt hatte. Genau darum geht es bei der Sicherheit von KI-Programmieragenten: diese Fragen zu stellen, bevor ein Agent etwas für Sie ausliefert.
Die KI schreibt bereits Ihren Code. Die Entscheidung, was in die Produktion geht, liegt weiterhin bei Ihnen.
Welche der vier Fragen können Sie heute nicht beantworten?
Wir haben drei Tage an Stand 62 verbracht und mit Sicherheits- und Entwicklungsteams genau über diese Fragen gesprochen. Vielen Dank an alle, die vorbeigekommen sind.
Das Xygeni-Team auf der ENISE 2026, von links nach rechts: Jesus-Platz, Marcos Martin, und Agustín Sánchez Fonseca.
Möchten Sie sehen, wie Xygeni diese Fragen in Ihrer Umgebung beantwortet? Kostenlos starten or Demo buchen.
Häufig gestellte Fragen
Was versteht man unter der Sicherheit von KI-Codierungsagenten?
Die Sicherheit von KI-Codierungsagenten ist die Praxis, zu kontrollieren, was KI-Codierungsassistenten und -agenten im Softwareentwicklungszyklus sehen, installieren, ausführen und veröffentlichen dürfen. Sie umfasst die Agenten selbst, die von ihnen eingebrachten Komponenten und die pipelineSie können Auslöser identifizieren und Sie erhalten die Beweise, die Sie benötigen, um ihren Ergebnissen vertrauen zu können.
Was war ein Clinejection-Anfall?
Clinejection war eine Angriffskette gegen das Cline-Repository, bei der eine in einem GitHub-Issue-Titel versteckte Aufforderung einen KI-Triage-Agenten dazu verleitete, Befehle auszuführen. Durch Cache-Poisoning erlangte der Angreifer ein npm-Veröffentlichungstoken und veröffentlichte eine nicht autorisierte Version von Cline, die rund viertausend Mal installiert wurde.
Was ist Slopsquatting?
Slopsquatting ist ein Lieferkettenangriff, bei dem ein Angreifer Paketnamen registriert, die KI-Modelle generieren. Installiert ein Entwickler oder ein Codierungsagent das generierte Paket, erhält er stattdessen den Code des Angreifers.
Kann KI Sicherheitsergebnisse selbstständig validieren?
Nicht zuverlässig. KI kann zwar Schwachstellen finden und erklären, aber ihre Ergebnisse können sich von Durchlauf zu Durchlauf ändern, was sie als Beweismittel nutzlos macht. Ein sichererer Ansatz besteht darin, die KI Vorschläge machen zu lassen und eine deterministische Engine entscheiden zu lassen, sodass dieselbe Eingabe immer dasselbe, überprüfbare Ergebnis liefert.
