Lieferkette (Supply Chain)
Die KI-Lieferkette umfasst alle extern bezogenen oder übergebenen Bestandteile, auf denen eine KI-Anwendung aufbaut: Modellgewichte, Feintuning-Adapter, Einbettungsmodelle, Datensätze, Bibliotheken, Frameworks, Model-Hub-Artefakte, Werkzeuge und Deployment-Umgebungen. Ein Lieferkettenrisiko entsteht, wenn Herkunft, Integrität, Version oder Sicherheitszustand eines solchen Bestandteils nicht ausreichend geprüft sind. Anders als bei klassischer Software können dabei nicht nur ausführbarer Code, sondern auch Daten und Modellparameter das spätere Systemverhalten beeinflussen.
Einordnung
OWASP behandelt diese Gefährdung als LLM04:2026. Die Beschreibung umfasst Risiken für Trainingsdaten, Modelle und Deployment-Plattformen und verweist zusätzlich auf vortrainierte Drittmodelle, schwache Modellprovenienz, veraltete Komponenten und LoRA-Adapter.1 Die Abgrenzung zur Datenvergiftung liegt im Blickwinkel: Datenvergiftung beschreibt die Manipulation von Daten oder Modellwissen, Lieferkettensicherheit betrachtet den gesamten Beschaffungs-, Änderungs- und Integritätspfad. Eine Backdoor kann daher zugleich Ergebnis von Vergiftung und Lieferkettenkompromittierung sein.
Besonders wichtig ist die Unterscheidung zwischen Dokumentation und Nachweis. Model Cards, Readmes oder Angaben in einem Hub helfen bei Auswahl und Bewertung, beweisen aber nicht selbst, dass ein Artefakt wirklich aus der behaupteten Quelle stammt oder seit Veröffentlichung unverändert blieb. OWASP weist ausdrücklich darauf hin, dass solche Informationen keine Herkunftsgarantie bieten.1 Daraus folgt nicht, dass offene Modelle grundsätzlich ungeeignet sind. Es bedeutet, dass Modelle, Daten und Adapter denselben Prozess für Freigabe, Integritätsprüfung und Aktualisierungsmanagement benötigen wie sicherheitskritische Softwareabhängigkeiten.
Dokumentiertes Beispiel
Microsoft beschreibt eine Forschungsdemonstration, bei der ein geringfügig modifiziertes Modell in einem öffentlichen Repository normal wirkte, bei einer bestimmten Anfrage aber gezielt eine Falschinformation ausgab. Das Szenario veranschaulicht eine Lieferketten-Backdoor: Die Manipulation geschieht vor der Integration und wird von der nachnutzenden Organisation mit dem Modell übernommen.2 Solche demonstrierten Fälle sind kein Beleg für eine allgemeine Unsicherheit aller Modell-Hubs; sie zeigen jedoch, dass Gewichte und Adapter nicht als bloße „Daten“ außerhalb des Sicherheitsprozesses behandelt werden dürfen.
Bedeutung für die Abwehr
Eine wirksame Praxis beginnt mit einem Inventar: Welche Modelle, Datenquellen, Adapter, Bibliotheken, Tools und externen Dienste sind in welcher Version im Einsatz? Daran schließen feste Versionsbindungen, Prüfung von Hashes oder Signaturen, Lieferantenprüfung, Zugriffsrechte für Repositories, Schwachstellenmanagement und isolierte Validierung neuer Artefakte an.2 OWASP empfiehlt ebenfalls Lieferanten- und Datenquellenprüfung, Evaluationen von Drittmodellen sowie Monitoring von Änderungen.1 Eine KI-Stückliste, oft als AI-BOM oder ML-BOM bezeichnet, ersetzt keine Prüfung, macht aber Abhängigkeiten, Zuständigkeiten und Rückrufe sichtbar. Für die Incident Response ist genau diese Rückverfolgbarkeit entscheidend: Nur wer weiß, welches Artefakt wann woher eingebunden wurde, kann eine kompromittierte Komponente gezielt sperren, ersetzen und Folgen bewerten.
Quellen
- OWASP Gen AI Security Project, „LLM04:2026 Supply Chain“, 3. August 2026, https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/ ↩
- Microsoft, „6. Supply Chain Vulnerabilities (OSS)“, abgerufen 20. August 2026, https://learn.microsoft.com/en-us/security/zero-trust/catalog-ai-attack-techniques/supply-chain-vulnerabilities ↩