KI-Supply-Chain-Angriffe auf ML-Modelle

Wie sich die Lieferkette von KI-Systemen zusammensetzt

Kaum ein Unternehmen trainiert Modelle von Grund auf. Üblich ist es, ein vortrainiertes Basismodell von einer öffentlichen Plattform zu laden, es mit eigenen Daten anzupassen und über Open-Source-Frameworks bereitzustellen. Jede Stufe bringt Fremdbestandteile mit:

• Modelle und Gewichte von Modell-Hubs, Forschungsgruppen oder kommerziellen Anbietern
• Datensätze aus öffentlichen Quellen, Web-Crawls oder von Datenlieferanten
• Software-Abhängigkeiten wie ML-Frameworks, Tokenizer, Konvertierungswerkzeuge und deren transitive Pakete
• Erweiterungen für Sprachmodelle, etwa Plugins, Tool-Anbindungen und Agenten-Frameworks
• Dienste wie gehostete Modell-APIs, Vektordatenbanken und Annotationsdienstleister

Typische Angriffswege

Schadcode in Modelldateien

Verbreitete Speicherformate für Modelle basieren auf Pythons Pickle-Serialisierung. Beim Laden einer solchen Datei kann beliebiger Code ausgeführt werden. Ein harmlos wirkendes Modell von einer öffentlichen Plattform kann so beim ersten Laden eine Hintertür auf dem Entwicklerrechner oder im Trainingscluster öffnen. Formate wie Safetensors speichern ausschließlich Gewichte und schließen diesen Angriffsweg aus.

Manipulierte Modelle mit Hintertür

Ein Modell kann so trainiert sein, dass es im Normalfall korrekt arbeitet, bei einem bestimmten Auslöser aber gezielt falsch reagiert, etwa eine bestimmte Datei als harmlos einstuft oder bei einem Schlüsselwort vertrauliche Anweisungen befolgt. Solche Hintertüren sind durch normale Qualitätstests kaum zu finden, weil sie nur bei dem Auslöser sichtbar werden.

Vergiftete Datensätze

Wer Einfluss auf öffentlich gesammelte Trainingsdaten hat, etwa über abgelaufene Domains, die in Datensatzlisten verlinkt sind, oder über gezielt platzierte Inhalte, kann das Verhalten späterer Modelle beeinflussen. Die OWASP Top 10 for LLM Applications 2025 führen dies als eigenes Risiko (Data and Model Poisoning).

Kompromittierte Pakete

ML-Projekte haben oft lange Abhängigkeitsketten. Typosquatting, Dependency Confusion und übernommene Maintainer-Konten sind hier ebenso wirksam wie in anderen Softwareprojekten. Ein bekanntes Beispiel ist der Vorfall um die PyTorch-Nightly-Builds Ende 2022, bei dem über ein gleichnamiges Paket im öffentlichen Paketindex Schadcode verteilt wurde.

Unsichere Erweiterungen und Dienste

Plugins und Tool-Anbindungen erhalten oft weitreichende Rechte. Ein manipuliertes oder schlecht abgesichertes Plugin kann Daten abgreifen oder Aktionen im Namen des Nutzers ausführen.

Relevanz für mittelständische Unternehmen

Auch wer keine eigenen Modelle entwickelt, ist betroffen: Softwarelieferanten bauen zunehmend Open-Source-Modelle in ihre Produkte ein, und interne Teams laden Modelle für Prototypen herunter, oft auf Rechnern mit Zugriff auf Quellcode und Zugangsdaten. NIS2 verpflichtet betroffene Einrichtungen ausdrücklich zur Sicherheit der Lieferkette; KI-Komponenten sind davon nicht ausgenommen. Die OWASP Top 10 for LLM Applications führen Supply-Chain-Risiken als eigene Kategorie, und MITRE ATLAS dokumentiert entsprechende Angriffstechniken.

Schutzmaßnahmen

1. Quellen festlegen: Modelle und Datensätze nur aus definierten, vertrauenswürdigen Quellen beziehen; Herausgeber, Lizenz und Versionsstand prüfen und dokumentieren.
2. Sichere Formate bevorzugen: Modelle möglichst im Safetensors-Format laden und Pickle-basierte Dateien nur nach Prüfung mit einem Modell-Scanner und in isolierten Umgebungen öffnen.
3. Integrität prüfen: Prüfsummen und, wo verfügbar, kryptografische Signaturen verifizieren. Interne Kopien in einem eigenen Modell-Register ablegen, statt bei jedem Build aus dem Internet nachzuladen.
4. Inventar führen: Eine Stückliste für KI-Komponenten (AI-BOM oder ML-BOM) erfassen, welche Modelle, Datensätze und Pakete in welchem System stecken. CycloneDX und SPDX 3.0 unterstützen entsprechende Angaben.
5. Abhängigkeiten absichern: Paketversionen fest pinnen, einen internen Paketspiegel nutzen und Abhängigkeiten laufend auf bekannte Schwachstellen prüfen.
6. Modelle vor Einsatz testen: Neben Qualitätstests auch gezielt auf auffälliges Verhalten prüfen, etwa mit Red-Teaming-Szenarien und Tests auf ungewöhnliche Auslöser.
7. Rechte begrenzen: Plugins und Agenten nur mit minimal nötigen Berechtigungen betreiben und kritische Aktionen bestätigen lassen.
8. Lieferanten einbeziehen: Von Softwareanbietern Angaben dazu verlangen, welche KI-Modelle enthalten sind, woher sie stammen und wie Updates abgesichert werden.

Fazit

Die Lieferkette ist bei KI-Systemen besonders lang und schwer einsehbar, denn Modelle lassen sich nicht wie Quellcode lesen. Wer Herkunft, Integrität und Berechtigungen seiner KI-Komponenten systematisch kontrolliert, schließt die häufigsten Angriffswege. SecTepe unterstützt dabei, KI-Komponenten in das Lieferanten- und Schwachstellenmanagement einzubinden.

Häufige Fragen

Sind Modelle von großen Plattformen automatisch sicher?

Nein. Öffentliche Modell-Hubs führen teilweise automatische Prüfungen durch, jeder kann dort aber Modelle hochladen. Maßgeblich sind Herausgeber, Format und eigene Prüfung.

Was unterscheidet eine KI-Supply-Chain von einer klassischen Software-Lieferkette?

Zu Code und Paketen kommen Modelle und Daten hinzu. Deren Verhalten lässt sich nicht durch Codeprüfung bewerten, sondern nur durch Tests, Herkunftsnachweise und Überwachung im Betrieb.