Supply Chain

Angriffsfläche

Tools & externe Daten

Eine kompromittierte Komponente — ein manipuliertes Modell, ein bösartiger Adapter, ein gekaperter Konvertierungsschritt, ein vergifteter Datensatz oder ein verwundbares Paket — gelangt ins System oder wird an der Stelle ausgetauscht, an der ein Artefakt in eine vertrauenswürdige Umgebung übernommen wird.

Was es ist

Die Lieferkette eines großen Sprachmodells reicht weit über den Anwendungscode hinaus. Das Basismodell, jedes darauf zusammengeführte Fine-Tune oder jeder Adapter, die Datensätze dahinter, die Konvertierungs-, Merge- und Quantisierungsschritte, die das Modell umformen, das Serving-Framework und die umgebenden Pakete: All das sind externe Komponenten, die ein Angreifer manipulieren kann, bevor eine Anwendung läuft. Die Ausgabe 2026 behandelt Modellartefakte, Herkunftsnachweise und diese Transformationsschritte als vollwertige Angriffsflächen.

Herkunftsnachweise sind standardmäßig schwach. Eine Model Card dokumentiert ein Modell, beweist aber nicht seine Herkunft. Eine Pipeline, die ein Artefakt über eine veränderliche Referenz auflöst — ein `latest`-Tag, Autor und Modellname — statt über einen unveränderlichen Digest, kann an der Übernahmegrenze einen Ersatz untergeschoben bekommen. Signieren hilft, beweist aber die Herkunft, nicht die Sicherheit: Ein gültig signiertes Modell eines kompromittierten Anbieters kann trotzdem eine Hintertür enthalten.

Die agentische Ebene vervielfacht die Eintrittspunkte: Jeder MCP-Server und jede Tool-Registry, die ein Agent zur Laufzeit erreicht, ist eine eigene Abhängigkeit. Diese agentische Dimension behandelt Supply Chain Compromise (T17) gesondert.

Arten

Anfällige oder veraltete Komponenten: Ungepatchte Pakete, Serving-Frameworks oder Modelle geben einem Angreifer einen bekannten Exploit in die Hand — auch Abhängigkeiten, die ein Coding-Assistent halluziniert und ein Angreifer vorab registriert hat („Slopsquatting“).
Manipulierte vortrainierte Modelle: Ein Modell trägt eine versteckte Hintertür aus vergifteten Daten oder direkter Parametermanipulation. Der Verzicht auf unsichere Formate wie Pickle senkt das Risiko, beseitigt es aber nicht, denn eine Hintertür kann auch im Rechengraphen des Modells stecken.
Schwache Herkunftsnachweise: Nichts verknüpft ein heruntergeladenes Modell, einen Adapter oder einen Datensatz mit dem Konto, von dem es angeblich stammt, und ein freigewordener Namespace lässt sich unter demselben Namen neu registrieren.
Kompromittierte Adapter und Transformationen: Ein bösartiger LoRA-Adapter, ein gekaperter Konvertierungs- oder Merge-Dienst oder Gewichte, die bei voller Präzision harmlos wirken, sich nach der Quantisierung aber bösartig verhalten.

Angriffsszenarien

In einem Multi-Agenten-System

Ein Agent lädt einen MCP-Tool-Server eines Drittanbieters aus einer ungeprüften Registry, der jeden von ihm weitergeleiteten Tool-Aufruf still exfiltriert.

Bösartige Paketabhängigkeit

Ein bösartiges Paket überdeckt eine legitime Abhängigkeit in einer öffentlichen Registry, und eine Umgebung für die Modellentwicklung installiert es als gewöhnliche Abhängigkeit.

Manipuliertes Modell auf einem Hub

Ein Angreifer veröffentlicht ein Modell mit gezielt veränderten Parametern unter einem vertrauenswürdig wirkenden Namen. Es besteht die üblichen Benchmarks und verbreitet dabei Fehlinformationen.

Wiederverwendeter Namespace

Eine Organisation bezieht ein Modell nur über Autor und Namen. Der ursprüngliche Autor löscht sein Konto, ein Angreifer registriert den Namespace neu, und die Pipeline lädt das Modell des Angreifers.

Kompromittierte Build-Pipeline

Eine kompromittierte Build-Pipeline veröffentlicht ein trojanisiertes Release, signiert von der eigenen Infrastruktur der Organisation. Es besteht damit jede Herkunftsprüfung, die nur extern bezogene Komponenten markiert.

Abwehrmaßnahmen

Jede Quelle prüfen: Modellanbieter, Datensätze sowie deren Nutzungsbedingungen und Datenschutzrichtlinien prüfen, bevor man ihnen vertraut, regelmäßig erneut auditieren und bestätigen, dass eine von der KI vorgeschlagene Abhängigkeit existiert und das beabsichtigte Paket ist.
Signiertes Inventar führen, per Digest fixieren: Eine Stückliste (Bill of Materials) für Modelle, Adapter, Datensätze und Abhängigkeiten führen, Artefakte gegen ein Transparenz-Log signieren und sie über einen unveränderlichen Digest auflösen — dieselbe Disziplin, die eine geprüfte Tool Registry für von Agenten geladene Tools durchsetzt.
Transformationen als Übernahmepunkte behandeln: Konvertierungs-, Merge- und Quantisierungsdienste als hochriskant überwachen und das Artefakt evaluieren, das tatsächlich ausgerollt wird, nicht sein Original in voller Präzision.
Reichweite eines geladenen Tools eingrenzen: Jedes Tool und jeden MCP-Server gemäß Permission-scoped Tools nur an den Zugriff binden, den seine Aufgabe benötigt, und Drittanbietermodelle vor der Übernahme per Red-Teaming prüfen.

Quellen

Sicherheit

Wohin als Nächstes

SicherheitAlle BedrohungenÖffnen