Supply Chain
- Tools & externe Daten
Eine kompromittierte Komponente — ein vergiftetes Basismodell, ein bösartiges Fine-Tuning, ein manipuliertes Plugin oder ein manipulierter MCP-Server, oder ein kompromittierter Datensatz — gelangt vor oder während des Deployments in das System.
Was es ist
Die Lieferkette eines großen Sprachmodells reicht weit über den Anwendungscode hinaus — das Basismodell, jedes darauf zusammengeführte Fine-Tuning oder jeder Adapter, die dahinterliegenden Datensätze sowie die Plugins oder MCP-Server, die ein Agent zur Laufzeit lädt, sind allesamt externe Komponenten, die Angreifende manipulieren können, bevor eine Anwendung je läuft. Frei zugängliche Modelle, parametereffiziente Fine-Tuning-Methoden wie LoRA und gemeinsam genutzte Model-Merge-Plattformen senken die Hürde, eine kompromittierte Komponente in eine Kette einzuschleusen, die kein einzelnes Team vollständig kontrolliert. Ein agentisches System vervielfacht die Eintrittspunkte: Jeder Tool-Server, jede MCP-Integration oder jedes Drittanbieter-Modell, das ein Agent zur Laufzeit erreichen kann, ist eine eigene Supply-Chain-Abhängigkeit, und ein einziges kompromittiertes Glied kann jeden nachgelagerten Agenten still korrumpieren.
Arten
- Anfällige oder veraltete Komponenten
- Ungepatchte Pakete von Drittanbietern oder Abhängigkeiten der Modellentwicklung verschaffen Angreifenden einen bekannten Exploit in die Pipeline, mit größerem Schadensradius, wenn die Abhängigkeit in der Modellentwicklung oder im Fine-Tuning sitzt.
- Manipulierte vortrainierte Modelle
- Ein aus einem öffentlichen Repository bezogenes Modell trägt eine versteckte Hintertür oder Verzerrung, die durch direkte Parametermanipulation oder einen vergifteten Trainingsdatensatz eingebracht wurde — eine binäre Blackbox, die statische Prüfung nicht erkennen kann.
- Anfällige Adapter & Merges
- Ein bösartiger LoRA-Adapter oder ein kompromittierter Model-Merge- oder Format-Konvertierungsdienst schleust bei der Zusammenführung eine Hintertür in ein ansonsten vertrauenswürdiges Basismodell ein.
- Schwache Herkunftsnachweise
- Nichts überprüft, ob ein heruntergeladenes Modell oder ein Datensatz tatsächlich von dem Konto stammt, das es vorgibt — Angreifende können ein Anbieterkonto kompromittieren oder imitieren, ohne dass eine Signatur dies erkennt.
Angriffsszenarien
Ein Agent lädt einen MCP-Tool-Server eines Drittanbieters aus einer ungeprüften Registry, der jeden von ihm weitergeleiteten Tool-Aufruf still exfiltriert.
Kompromittierte Abhängigkeit
Angreifende platzieren Schadsoftware in einer öffentlichen Paketregistrierung; eine Modellentwicklungsumgebung installiert sie als gewöhnliche Abhängigkeit und verschafft Angreifenden so einen Fuß in der Tür, bevor das Modell je bereitgestellt wird.
Direkte Modellmanipulation
Angreifende bearbeiten die Parameter eines veröffentlichten Modells direkt und veröffentlichen es unter seinem ursprünglichen Namen erneut, wodurch sie Fehlinformationen über ein scheinbar unverändertes, vertrauenswürdiges Modell verbreiten.
Bösartiger Adapter-Merge
Ein kompromittierter Adapter eines Drittanbieters, einmal über einen öffentlichen Model-Merge-Dienst in ein produktives Basismodell integriert, verschafft Angreifenden einen verdeckten Einstiegspunkt, der während des gewöhnlichen Betriebs aktiviert wird.
Imitierte Modellveröffentlichung
Nachdem ein populäres offenes Modell entfernt wurde, veröffentlichen Angreifende eine gleichnamige, mit Schadsoftware gebündelte Version erneut und nutzen so den früheren Ruf des Modells, um Opfer zu erreichen, die annehmen, der Name bedeute immer noch dasselbe.
Abwehrmaßnahmen
- Jede Quelle prüfen
- Prüfen Sie Datenquellen, Modellanbieter sowie deren Nutzungsbedingungen und Datenschutzrichtlinien, bevor Sie ihnen vertrauen, und auditieren Sie regelmäßig erneut — die Sicherheitslage eines Anbieters ist keine einmalige Prüfung.
- Herkunft mit einer signierten Stückliste nachverfolgen
- Führen Sie für jedes Modell, jeden Datensatz und jede Abhängigkeit eine signierte Stückliste (Bill of Materials) und verifizieren Sie Hashes bei allem, was aus einem Repository bezogen wird — dieselbe Disziplin, die eine geprüfte Tool Registry für von Agenten geladene Tools durchsetzt.
- Reichweite eines geladenen Tools eingrenzen
- Beschränken Sie jedes Tool oder jeden MCP-Server, den ein Agent lädt, per Permission-scoped Tools auf genau den Zugriff, den seine Aufgabe benötigt, damit eine kompromittierte Abhängigkeit nicht über ihren deklarierten Umfang hinausreichen kann.
- Kontinuierlich Red-Teaming betreiben und patchen
- Bewerten Sie Drittanbietermodelle vor der Übernahme mit adversarial Red-Teaming, und pflegen Sie eine Patch-Richtlinie für bekanntermaßen verwundbare Komponenten, statt Integration als einmaliges Ereignis zu behandeln.