KI-Coding-Agenten haben den letzten menschlichen Prüfer abgeschafft. Jetzt ist es Ihr Lieferketten-Problem.
Agentische Codegenerierung hat die Prüfung von Abhängigkeiten leise von Ingenieuren auf Maschinen verlagert, die gar nicht prüfen. Die Lösung ist nicht die Flucht aus einer Sprache oder einem Registry. Sie besteht darin, einzusperren, was Ihre Agenten ausführen.
Fragen Sie einen Ingenieur, welche Pakete letzte Woche in einem neuen Feature mitgeliefert wurden, und früher bekamen Sie eine Antwort. Fragen Sie heute, wenn ein Agent den Code geschrieben hat, bekommen Sie oft nur ein Schulterzucken. Der Agent hat die Abhängigkeit hinzugefügt. Der Paketmanager hat deren Abhängigkeiten nachgezogen. Gelesen hat das niemand, weil Lesen nie Teil des Workflows war, für den das Tool verkauft wurde. Das ist der unbequeme Kern der Software-Lieferkettensicherheit bei KI-Coding-Agenten.
Es lohnt sich, präzise zu sein, was „ein Agent hat es getan“ eigentlich bedeutet, denn hinter dem Satz stecken drei getrennte Mechanismen. Das modellgesteuerte Tool entscheidet, dass eine Bibliothek gebraucht wird, und schreibt den Import. Ihr Paketmanager entfaltet daraus einen Baum transitiver Abhängigkeiten, die Sie nie ausgewählt haben. Das Editor-Plugin führt die Installation aus, häufig samt Testsuite, als Nebeneffekt des „einfach mal Ausprobierens“ direkt in Ihrer Entwicklungsumgebung. Ein Mensch, der eine Bibliothek auswählt, wirft zumindest einen Blick auf das Repository, die Download-Zahlen, den letzten Commit. Der Resolver wirft gar keinen Blick, und das Plugin führt aus, was der Resolver ausgespuckt hat. Pakete drei Ebenen tiefer bekommen exakt die Prüfung, die diese Kette ihnen zugesteht: keine.
Nicht jeder Agent verhält sich so, und diese Einschränkung zählt. Viele halten vor jedem Shell-Befehl weiterhin an und fragen nach, und die Hersteller dokumentieren diese Freigabemechanismen: Cursors Agent verfügt über eine Auto-Run-Einstellung, die auf einer Positivliste stehende Befehle ohne Rückfrage ausführt, und Anthropics Claude Code bringt einen Auto-Accept-Modus sowie Berechtigungslisten neben den Standard-Rückfragen mit. Belegt ist, dass diese freizügigen Modi existieren und genau jene sind, die mit Geschwindigkeit beworben werden. Wie verbreitet Teams sie eingeschaltet lassen, veröffentlicht kein Hersteller. Die Behauptung, die menschliche Prüfung sinke auf null, ist daher als Argument zu lesen, nicht als Messung: Sie folgt aus der Funktionsweise der Modi, nicht aus einer Erhebung.
Was passiert, wenn ausgerechnet das ungeprüfte Paket bösartig ist?
Dann erleben Sie ein Fehlerbild, das längst eingetreten ist, und dessen Zahl weiter steigt. Der State of the Software Supply Chain 2024 von Sonatype zählte mehr als 512.000 bösartige Open-Source-Pakete in einem einzigen Jahr, ein Anstieg von 156 % gegenüber dem Vorjahr. Das ist eine Zählung, keine gemessene Wahrscheinlichkeit, aber die Richtung steht außer Frage: Je mehr feindselige Pakete in den Registries liegen, desto wahrscheinlicher trifft ein beliebiger Resolve-Vorgang auf eines, auch wenn niemand eine belastbare Quote nennen kann. Wo würde sich ein solches Paket verstecken? Die Dependency-Forschung von Endor Labs ergab, dass rund 95 % der verwundbaren Abhängigkeiten transitiv sind, also der indirekten Art, die kein Entwickler von Hand auswählt. Das sind verwundbare, keine bösartigen Pakete, die Zahl misst also, wo sich Fehler häufen, nicht wo Angriffe landen. Doch beide teilen sich ein Versteck: Wenn sich zufällige Schwachstellen bereits in den Ebenen sammeln, die ein Agent stillschweigend auflöst, ist das genau dort, wo auch eingeschleuster Code ungelesen bliebe.
Der dokumentierte Vorfall macht es greifbar. Sicherheitsforscher von Snyk beschrieben einen Entwickler, der eine Cursor-Editor-Integration testete und dabei eine vergiftete Kopie eines populären Python-Pakets als transitive Abhängigkeit zog. Der bösartige Code schrieb eine versteckte Startdatei, die beim Import ausgeführt wurde. Was den Angriff auffliegen ließ, war fast komisch: Die Payload erzeugte rekursiv Python-Subprozesse, bis der Maschine der Arbeitsspeicher ausging und sie abstürzte. Die Entdeckung war ein Zufallsprodukt der Ressourcenerschöpfung, kein Kontrollmechanismus, der ausgelöst hätte.
Folgt man dem Mechanismus, ist die Lehre unbequem. Niemand musste nachlässig sein. Das gewöhnliche Verhalten der Toolchain reichte aus: Der Agent forderte ein Paket an, der Resolver fügte etwas hinzu, wovon dieses Paket abhing, die Integration führte es aus. Kein Mensch hat den bösartigen Code ausgewählt. Drei automatisierte Schritte haben die gesamte Kette abgewickelt, und keiner davon prüft.
Die Flucht aus dem Registry ist der falsche Reflex
Der Reflex nach einem solchen Vorfall ist, dem Ökosystem zu misstrauen: dem Repository die Schuld zu geben, sich in eine Sprache mit „sichererem“ Ruf zurückzuziehen. Das verkennt, wo das Risiko tatsächlich sitzt. Es lag nie in der Marke eines Registrys. Es sitzt in ungeprüftem Code, mehrere Abhängigkeiten tief, und dieses Muster hat jedes öffentliche Ökosystem. Die Zahlen von Sonatype zu bösartigen Paketen umfassen npm, PyPI und den Rest, ein Registry-Wechsel ändert also nur, welcher Marke Sie misstrauen, während der ungelesene Code auf Ihrem Build-Server bleibt. Deutsche Teams kennen das Prinzip aus einem anderen Zusammenhang: Das Lieferkettensorgfaltspflichtengesetz verpflichtet Unternehmen, Verantwortung entlang ihrer gesamten Lieferkette zu übernehmen, nicht nur beim direkten Zulieferer. Für Code gilt dieselbe Logik, nur dass beim Softwarebau bislang kaum jemand die tieferen Glieder der Kette prüft.
Wie zähmt man einen Coding-Agenten in der Praxis?
Drei Kontrollen erledigen den Großteil der Arbeit, und keine davon ist exotisch oder hypothetisch. Jede zielt auf dasselbe: Hören Sie auf zu entscheiden, ob ein Paket vertrauenswürdig ist, und schränken Sie stattdessen ein, was ein nicht vertrauenswürdiges Paket anrichten kann.
Erstens: Default-Deny-Egress für den Build. Ein Build-Agent braucht einen Paketindex und vielleicht einen Git-Host. Er braucht nicht Ihren Cloud-Metadaten-Endpunkt, Ihr internes Netzwerk oder einen beliebigen Server im Ausland. Auf GitHub Actions ist das bereits heute im Einsatz, über Harden-Runner von StepSecurity, das ausgehenden Verkehr standardmäßig blockiert und eine Positivliste erlaubt:
# .github/workflows: Egress blockieren, nur freigeben, was der Build braucht
- uses: step-security/harden-runner@v2
with:
egress-policy: block
allowed-endpoints: >
pypi.org:443
files.pythonhosted.org:443
github.com:443
Eine Payload, die versucht, einen SSH-Schlüssel zu exfiltrieren, hat jetzt nirgendwo hin zu senden, und Harden-Runner protokolliert den blockierten Aufruf, sodass der Versuch im Run-Log auftaucht. Sie haben eingeschränkt, was das Paket tun kann, ohne zu urteilen, ob es sicher ist.
Zweitens: Installation aus einem versionierten Lockfile mit Hashes, und Ablehnung von allem, was nicht passt. Eine Top-Level-Version zu pinnen reicht nicht, denn die Gefahr sitzt im transitiven Baum. Ein Lockfile hält jedes aufgelöste Paket samt Hash fest, sodass eine ausgetauschte oder vergiftete Version nicht mehr still hereinkommen kann. Die Befehle existieren bereits: npm ci installiert strikt aus einer committeten package-lock.json, pip install --require-hashes -r requirements.txt verweigert jeden Download, dessen Hash fehlt oder falsch ist, und --ignore-scripts bei npm blockiert die Codeausführung bei der Installation, auf die sich viele Angriffe stützen. Mit gepinnten Hashes wird aus einer schlechten Kopie kein stiller Abruf mehr, sondern ein Diff, den ein Mensch oder ein Scanner prüft, bevor irgendetwas ausgeführt wird:
# package-lock.json, sichtbar im Pull Request
"node_modules/log-helper": {
- "version": "2.4.0",
- "integrity": "sha512-6b1e2c..."
+ "version": "2.4.1",
+ "integrity": "sha512-00d4af..."
Ohne Lockfile holt sich der Resolver einfach die neue Version, und die Änderung bleibt unsichtbar. Mit Lockfile ist die Mutation eine rote Linie, die auf Prüfung wartet, statt eine stille Installation.
Drittens: jede Abhängigkeitsänderung automatisch scannen und den Build stoppen, wenn der Scanner etwas findet, das er nicht rechtfertigen kann. Hier hat das Tooling aufgeholt. OSV-Scanner gleicht Lockfiles mit einer öffentlichen Schwachstellendatenbank ab, und Dienste wie Socket prüfen jedes neu hinzugefügte Paket direkt im Pull Request auf Installationsskripte, verschleierten Code und unerwartete Netzwerkzugriffe. Binden Sie das in dieselbe Sandbox ein und lassen Sie es bei jeder Lockfile-Änderung laufen:
# .github/workflows: PR abbrechen bei bekannt schlechter oder neu hinzugefügter Abhängigkeit
- uses: google/osv-scanner-action@v2
with:
scan-args: "--lockfile=package-lock.json"
Ein Modell obendrauf zu legen, ist der Punkt, an dem sich die Ökonomie meines Erachtens endlich zugunsten der Verteidiger neigt, auch wenn das Argument und kein Benchmark ist: Dieselben Modelle, die ungelesen installieren, können auch einen Dependency-Diff schneller lesen als ein Mensch, einen Startup-Hook markieren und einen Exfiltrationspfad nachzeichnen. So eingesetzt automatisiert der Angreifer den Angriff, und Sie automatisieren den Prüfer. Die oben genannten Scanner sind der einsatzbereite Kern, das Modell ist ein Beschleuniger obendrauf, kein Ersatz für Sandbox und Lockfile.
Dieselbe Disziplin bringen wir in jedes Beratungsmandat ein, und sie zieht sich durch die weiteren Analysen, die wir veröffentlichen: den Menschen dort im Loop halten, wo Urteilsvermögen zählt, und die Maschine dort einzäunen, wo es das nicht tut.
Die Agenten gehen nicht zurück in die Box, und das sollen sie auch nicht. Aber ein Team, das installiert, was es nie liest, hat seine eigene letzte Verteidigungslinie automatisiert wegrationalisiert. Die Antwort ist nicht, den Paketen mehr zu vertrauen. Sie besteht darin, dem Build einen sicheren Ort zum Laufen zu geben, ein Lockfile, das Manipulation sichtbar macht, und einen Scanner, der jede Änderung liest, damit keine Abhängigkeit ungelesen in Produktion gelangt.
Häufige Fragen
Sind KI-Coding-Agenten gefährlicher als ein Mensch, der Pakete installiert?
Es handelt sich um dieselbe Klasse von Lieferkettenangriff, aber die Angriffsfläche ist größer in den Auto-Genehmigungs- und Hintergrund-Installationsmodi, die Teams aus Geschwindigkeitsgründen aktivieren. Dort löst der Agent transitive Abhängigkeiten auf und führt sie aus, ohne dass kaum jemand einen Blick darauf wirft, sodass sich eine Kompromittierung ausbreiten kann, bevor sie jemand bemerkt.
Sollte ich nach einer Kompromittierung einer Abhängigkeit die Programmiersprache wechseln?
Nein. Jedes öffentliche Ökosystem trägt ungeprüften transitiven Code mit sich, und die Forschung von Endor Labs beziffert rund 95 % der verwundbaren Abhängigkeiten auf genau diese transitive Ebene. Ein Sprachwechsel verschiebt also nur, welcher Marke Sie misstrauen, löst aber nichts. Pinnen Sie Versionen mit einem gehashten Lockfile, verifizieren Sie Provenienz, und isolieren Sie die Ausführung stattdessen.
Kann ein KI-Agent auch beim Schutz vor bösartigen Paketen helfen, statt nur das Risiko zu verursachen?
Ja, und der einsatzbereite Kern ist nicht exotisch: Builds in einer Default-Deny-Sandbox wie Harden-Runner laufen lassen, und einen automatisierten Scanner wie OSV-Scanner oder Socket bei jeder Abhängigkeitsänderung einsetzen, um Installationsskripte, Verschleierung und unerwartete Netzwerkaufrufe zu markieren. Ein Modell kann die markierten Diffs schneller triagieren als ein Mensch, aber das ist ein Beschleuniger obendrauf, kein Ersatz für Scanner und Sandbox.
Verwandte Artikel
- Auf Ubuntu 26.04 LTS ist das coreutils, von dem Ihr Build abhängt, nicht mehr GNU
- Die Souveränitätsprämie: Warum souveräne KI-Lösungen für Unternehmen nicht wegen Tempo gewinnen, sondern wegen Zugriffssicherheit
- Der Streit ums Geschäftsgeheimnis ist entschieden, lange bevor jemand kündigt. Fragen Sie Faccenda Chicken.
- Security & Trust
Verfasst von einer KI-Redaktionspersona des proprietären Redaktionssystems von Abyshire und von unserem Team geprüft.