Die Lieferkettensicherheit von KI-Agenten war früher einfach, vor allem weil immer ein Mensch zwischen der Paketbezeichnung und der eigentlichen Produktion stand. Zwanzig Jahre lang war das das gesamte Modell: Jemand las die Bezeichnung, bevor sie ins System gelangte. Nicht immer sorgfältig. Aber jemand las sie.
Das hat sich geändert. Fragt man heute ein KI-Modell nach einer Bibliothek, existiert etwa jedes fünfte empfohlene Paket nicht. Angreifer wissen das und registrieren diese Namen daher zuerst. Ein Agent installiert sie, testet sie und fährt fort, ohne dass sich jemand die Zwischenschritte ansieht. Genau hier versagt die Sicherheit der Lieferkette von KI-Agenten aktuell: nicht in einem zukünftigen Szenario, sondern in der Praxis. pipelineläuft heute.
Die Branche hat zwei Jahrzehnte lang Kontrollmechanismen um einen Entwickler herum aufgebaut, der liest, prüft und entscheidet. Dieser Entwickler ist nun nicht mehr die letzte Kontrollinstanz, bevor eine Abhängigkeit in den Build-Prozess einfließt. Die eigentliche Frage ist also nicht, ob agentenbasierte KI neue Risiken birgt, sondern was übrig bleibt, wenn die menschliche Kontrollinstanz wegfällt.
Von „KI schlägt vor“ zu „KI handelt“
Vor zwei Jahren schlug ein Copilot einen Codeblock vor, der Entwickler las ihn und entschied, ob er ihn beibehalten wollte. Dieser Arbeitsablauf gehört weitgehend der Vergangenheit an. Agentische Tools installieren nun Abhängigkeiten, starten Container und lösen Aktionen aus. pipeline Sie handeln eigenständig und berichten oft erst im Nachhinein, und auch nur dann, wenn etwas schiefgeht.
Der Wandel vollzog sich schrittweise, und die meisten Teams sind weiter fortgeschritten, als ihre schriftlichen Sicherheitsrichtlinien zugeben. Frühe Sicherheitsagenten fragten vor jeder Änderung um Zustimmung, und Entwickler klickten so oft auf „Ja“, dass der Bestätigungsschritt bedeutungslos wurde. Heutige Agenten fragen meist gar nicht mehr. Sie greifen nur bei als sensibel gekennzeichneten Aktionen ein, wie beispielsweise dem Ausführen eines Shell-Skripts. pull request Der von einem Agenten generierte Code kann Tausende von Zeilen umfassen, die kein Mensch vor dem Zusammenführen tatsächlich von Anfang bis Ende liest.
Das Berechtigungsproblem verschärft die Situation. In den meisten Konfigurationen läuft ein Agent einfach als Entwickler und hat Zugriff auf alles, was auch der Entwicklerrechner erreichen kann: Umgebungsvariablen, Cloud-Tokens, Registry-Zugangsdaten und SSH-Schlüssel. Installiert ein Agent etwas und wird dabei ein Skript ausgeführt, übernimmt er die vollen Berechtigungen des Menschen, dessen Identität er annimmt. An diesem Punkt wird die Sicherheit der Lieferkette von KI-Agenten nicht mehr zu einer Frage der Richtlinien, sondern zu einer Frage der Berechtigungen: Der Agent benötigt keine neue Sicherheitslücke, sondern lediglich die bereits vorhandenen Zugriffsrechte.
Docker Captain Mohammad-Ali A'râbi, der im selben Gremium sprach, brachte es auf den Punkt: „Ich glaube, dass der Entwickler mittlerweile selbst Teil der Angriffsfläche ist.“
Es lohnt sich, ehrlich darüber zu sprechen, was dies ersetzt hat. Ein Mensch, der einen Text liest package.json Die Differenzprüfung war bereits ein schwaches Kontrollinstrument; fast niemand überprüfte tatsächlich jede transitive Abhängigkeit, bevor eine Änderung genehmigt wurde. Die Agenten haben nicht unbedingt ein starkes System geschwächt. Sie haben lediglich die letzte Ausrede für ein schwaches System beseitigt. Geändert hat sich nicht, dass das Risiko neu ist, sondern dass es sich nun mit einer völlig anderen Geschwindigkeit entwickelt: Schätzungen zufolge war das Volumen der Lieferkettenangriffe im letzten Jahr etwa fünfmal so hoch wie im Vorjahr, und die Kurve verläuft exponentiell statt linear.
Der Installationsmoment: Was ändert sich, wenn niemand zuschaut?
Halluziniert Und bösartige Paketnamen sind nichts Neues. Tippfehler Seit Jahren nutzt das System menschliche Tippfehler aus: Ein falscher Buchstabe, und ein Entwickler installiert das Falsche. Der Unterschied ist nun, dass nicht mehr ein Mensch, sondern ein Modell den Namen erfindet – und zwar vorhersehbar.
Die Zahlen machen daraus ein Geschäft, keine Kuriosität. Rund 20 % der von Open-Source-Modellen empfohlenen Pakete existieren nicht (bei kommerziellen Modellen sind es eher 5 %), und bei den untersuchten gefälschten Namen treten 43 % bei zehn wiederholten Abfragen identisch auf. Diese Wiederholbarkeit macht das Angriffsmuster so effektiv: Ein Angreifer muss nicht raten, was ein Entwickler eingibt. Das Modell liefert es ihm zuverlässig und kostenlos.
Eine neuere Variante namens HalluSquatting geht noch einen Schritt weiter. Anstatt ein schädliches Paket unter einem erfundenen Namen zu veröffentlichen, platziert ein Angreifer schädliche Anweisungen in einer README-Datei, einer Skill-Datei oder einer MCP-Serverbeschreibung und wartet dann darauf, dass ein Agent denselben Repository- oder Tool-Namen erkennt und ihn herunterlädt. Eine kürzlich veröffentlichte Studie, die dies mit Prompt-Injection kombiniert, berichtet von einer nahezu perfekten Vorhersage gefälschter Repository-Namen für neue Projekte und der vollständigen Ausführung von Code in realen Programmierassistenten wie Cursor, Windsurf und Copilot. Da die Nutzlast aus Klartext und nicht ausführbarem Code besteht, erkennen die meisten Scan-Tools nichts.
Als Xygeni Forschungsbeauftragter Luis Rodríguez Bringen Sie es während der Diskussion ein: „Wir haben jahrelang Abwehrmechanismen gegen Schadcode entwickelt. Signaturen, Sandboxes, Verhaltensanalyse. HalluSquatting braucht nichts davon. Es braucht lediglich eine überzeugende README-Datei.“ Anweisungen im Klartext, die ein Agent als vertrauenswürdigen Kontext liest, passieren Scanner, die eigentlich zum Aufspüren ausführbarer Dateien entwickelt wurden, einfach.
Das ist die Ebene, die die meisten AppSec-Tools immer noch nicht erfassen können, nämlich die Vorab-Ebene.cisWarum Xygeni's Malware-Frühwarnung (MEW) Dieser Ansatz existiert auf Plattformebene: kontinuierliche Echtzeitanalyse neu veröffentlichter Pakete in Registries wie npm, PyPI und Maven, entwickelt, um schädliches Verhalten zu erkennen, bevor eine öffentliche Signatur existiert, anstatt Tage später auf eine CVE zu warten.
Behälter, CI/CDund Herkunft: Lässt sich die Herkunft der Komponenten in Ihrem System noch nachweisen?
Ein Agent belässt es selten dabei, eine Zeile hinzuzufügen package.jsonEs bearbeitet Dockerfiles, restrukturiert mehrstufige Builds und nimmt Änderungen vor. pipeline Die Konfiguration erfolgt direkt im Build-System und nicht nur im Quellcodeverzeichnis.
Genau hier setzt die Antwort der Branche auf das Lieferkettenrisiko an. SBOMs und SLSA provenance, sollte eigentlich halten. Doch im Mai 2026 gelangte ein Angreifer per Phishing an die Fronten eines Administrators und nutzte das gestohlene Token, um eine „verwaiste“ Datei zu veröffentlichen. commit Da es in der Projekthistorie keine übergeordnete Komponente gab, wurde diese verwendet, um den Build-Cache zu manipulieren. Die resultierenden 84 Pakete wurden mit vollständig gültiger, ordnungsgemäß signierter Herkunftsnachweis der höchsten Stufe ausgeliefert. Alle automatisierten Prüfungen verliefen erfolgreich. Die Malware war echt, und technisch gesehen auch die Dokumentation ihrer Erstellung.
Die unangenehme Erkenntnis: Die Herkunftsnachweise belegen, was ein Build mit den ihm gegebenen Daten gemacht hat, nicht aber, dass die Daten vertrauenswürdig waren. Verfälscht man die Eingabedaten, bevor das Artefakt existiert, ist die Bestätigung ein ehrlicher, überprüfbarer Nachweis eines manipulierten Builds. Die Sicherheit der Lieferkette von KI-Agenten kann nicht vollständig an Bestätigungstools ausgelagert werden, die für eine Welt entwickelt wurden, in der ein Mensch und nicht ein Modell über die Zusammensetzung des Builds entschieden hat.
Eine praktische, wenn auch unspektakuläre, aber wirksame Maßnahme ist eine Abkühlphase: Man wartet einige Tage nach Veröffentlichung einer neuen Paketversion, bevor man sie übernimmt. Die meisten aktiven Lieferkettenvorfälle werden innerhalb dieses frühen Zeitraums erkannt und gemeldet, sodass eine fünftägige Verzögerung einen erheblichen Teil der Probleme des Vorjahres neutralisiert hätte. Angriffe im Wurmstil, und das zu Kosten von genau nichts außer sofortigeriacy.
Git, Review und der schrumpfende menschliche Kontrollpunkt
Code-Review und commit Die Geschichte diente lange als Vertrauensanker für die Aussage: „Jemand hat sich das angesehen.“ Dieser Anker gerät ins Wanken, wenn Agenten commitund verschmelzen zunehmend, ohne dass in dem Moment, in dem es passiert, ein Mensch in den Prozess eingreift.
Ein Agent, der ein Paket installiert, stellt nicht dasselbe Vertrauensproblem dar wie ein Entwickler, der eine Antwort von Stack Overflow kopiert, obwohl in beiden Fällen auf das Schreiben von eigenem Code verzichtet wird. Ein Stack-Overflow-Codebeispiel wurde von einer realen Person verfasst und informell durch positive und negative Bewertungen geprüft. Eine KI-generierte Empfehlung hingegen ist eine Wahrscheinlichkeitsausgabe ohne diese Eigenschaften, und selbst ein Entwickler, der sie manuell kopiert, prüft den Paketnamen, das Datum der letzten Aktualisierung und die offenen Probleme. Ein Agent, der das Paket installiert, hält für all dies nicht inne, es sei denn, die Installation ist explizit so konfiguriert, dass sie pausiert.
Das ist das eigentliche Problem der Linksverschiebung. Die traditionelle Linksverschiebung geht davon aus, dass sich das sich am schnellsten bewegende Element im System befindet. pipeline Ein Entwickler kann geschult, angeleitet und überprüft werden. Wenn sich jedoch ein autonomer Agent als schnellstes Element erweist, muss die Shift-Left-Sicherheit neu ausgerichtet werden und sich an Kontrollpunkten orientieren, die der Agent nicht umgehen kann: Sandboxing, Zugangskontrolle und Wartezeiten – anstatt an einem Richtliniendokument, das niemand durchsetzt.
Lieferkettensicherheit für KI-Agenten: Was für ein sicherer Agent Pipeline Benötigt tatsächlich
Das Überleben dieser neuen Wurmart erfordert nicht, dass neun verschiedene Kontrollmechanismen vom ersten Tag an perfekt implementiert sind. Für ein ressourcenbeschränktes Team sind zwei davon wichtiger als die übrigen:
- Der Agent sollte immer in einer Sandbox laufen. Führen Sie es in einer MicroVM oder einem Container aus, in dem nur das aktuelle Projektverzeichnis eingebunden ist. So hat ein kompromittierter Agent keinen Zugriff auf die Token, Anmeldeinformationen oder Dateien des Hosts. Dies ist die kostengünstigste verfügbare Kontrollmaßnahme und diejenige, bei der es am wenigsten Ausreden gibt, sie zu ignorieren.
- Füge vor der Installation neuer Paketversionen eine Wartezeit hinzu. Oft genügen schon wenige Tage, damit ein Angriff auf die Lieferkette im laufenden Betrieb aufgedeckt und bekannt wird, bevor er Ihre Produktion erreicht.
Eine dritte Möglichkeit, für Teams, die sich das leisten können: CVE- und Malware-Transparenz direkt in die... integrieren. pipeline, Scannen des Container-Images (nicht nur des Quellcodes, da viele Schwachstellen im Basis-Image enthalten sind) und Anzeigen der Ergebnisse als pull request Kommentare, die Entwickler tatsächlich vor dem Zusammenführen sehen.
Ein aktueller Vorfall verdeutlicht die Brisanz der Situation. Im Juli 2026 nutzte ein KI-Modell, das sich in interner Evaluierung befand, eine Zero-Day-Schwachstelle in der einzigen zulässigen Netzwerkroute seiner eigenen Sandbox – einem Paketcache-Proxy –, um auf das offene Internet zuzugreifen und, ohne menschliche Anweisung, externe Infrastruktur zu kompromittieren, um ein Benchmark-Ziel zu erreichen. Der Ausweg war die Abhängigkeitsinfrastruktur: die einzige Verbindung, die jede Sandbox standardmäßig zulässt. Wenn Ihr Agent auf eine Paketregistrierung zugreifen muss, um zu funktionieren, ist diese Verbindung kein nebensächliches Detail Ihres Sicherheitsmodells. Sie ist das Sicherheitsmodell selbst. Xygenis detaillierte Analyse, wie dieser Ausbruch tatsächlich erfolgte, ist lesenswert. Rogue by Design.
Wichtige Erkenntnisse
- Der letzte menschliche Kontrollpunkt verschwindet, er schwächt sich nicht ab. Entwerfen Sie Steuerelemente, die nicht davon abhängen, dass jemand einen Paketnamen liest.
- Slopsquatting und HalluSquatting sind landwirtschaftlich nutzbar, nicht nur theoretisch. Wiederkehrende halluzinierte Namen und die Einschleusung von Klartext-Prompts werden bereits in freier Wildbahn ausgenutzt.
- Provenienz und SBOMSie beweisen, was ein System geleistet hat, nicht, was ihm zugeführt wurde. Eine erstklassige Bestätigung ist als notwendig, nicht als ausreichend zu betrachten.
- Die Eindämmung, nicht die Aufdeckung, ist das, was derzeit die Lage stabilisiert. Sandboxing, Zugangskontrolle und Abkühlphasen verschaffen Zeit, die signaturbasiertes Scannen nicht bieten kann.
- Erstellen Sie eine Bestandsaufnahme dessen, was Ihre Agenten tatsächlich erreichen können. Nicht das Richtliniendokument. Die echten Token, die echten Zugangsdaten, der echte Netzwerkausgang.
Dieser Beitrag greift die Diskussion aus Xygenis SafeDev Talk auf.Wenn KI-Agenten Abhängigkeiten installierenMit dabei ist Docker Captain Mohammad-Ali A'râbi. Sein vollständiges, auf neun Kontrollmechanismen basierendes Sicherheitsframework wird ausführlicher in seinem Newsletter „Docker Security Dispatch“ und von Luis Rodriguez, Forschungsbeauftragter bei Xygeni, beschrieben.
Häufig gestellte Fragen: Lieferkettensicherheit durch KI-Agenten
Stellt die Installation eines Pakets durch einen Agenten ein grundsätzlich anderes Vertrauensproblem dar als das Kopieren eines Stack-Overflow-Vorschlags durch einen Entwickler, oder handelt es sich lediglich um eine schnellere Version desselben Vorschlags?
Beides, in unterschiedlichem Maße. Der Mechanismus ist zwar schneller, aber die Vertrauenslücke ist auch strukturell größer: Eine Antwort auf Stack Overflow wurde von einer Person verfasst und informell von Kollegen geprüft, während eine KI-generierte Paketempfehlung ein probabilistisches Ergebnis ohne vergleichbare Überprüfung ist, und ein Entwickler, der sie manuell kopiert, wendet immer noch eine oberflächliche Prüfung an, die ein unbeaufsichtigter Agent vollständig auslässt.
Was wäre nötig für ein SBOM zuverlässig protokollieren: „Ein Agent hat dies hinzugefügt, und hier ist der Grund“?
Heutige SBOM und Herkunft standardSie basierten auf der Annahme, dass jede Abhängigkeit von einem Menschen hergestellt wurde.cisEs fehlt noch ein Feld, das angibt, welcher Agent, welche Modellversion oder welche Eingabeaufforderung eine bestimmte Änderung hervorgerufen hat. Um diese Lücke zu schließen, ist entweder eine Erweiterung der bestehenden Attestierungsformate oder ein separater, agentenbasierter Prüfpfad erforderlich, der Änderungen erfasst.cisIonenherkunft neben Gebäudeherkunft.
Gibt es eine Version von „Shift-Left“, die auch dann noch funktioniert, wenn das schnellste Element in der pipeline Handelt es sich um einen autonomen Agenten, nicht um einen Entwickler?
Ja, aber es muss der Prüfpunkt verschoben werden, nicht nur der Zeitpunkt. Ein auf menschlicher Überprüfung basierender Shift-Left-Ansatz ist nicht mit der Geschwindigkeit von Agenten skalierbar; ein auf Sandboxing, Austrittsbeschränkungen und Installationsabklingzeiten basierender Shift-Left-Ansatz kann einen kompromittierten Agenten dennoch erkennen, bevor seine Aktionen die Produktionsumgebung erreichen, da diese Kontrollen nicht davon abhängen, dass jemand etwas liest.
