LLM Supply Chain: Schwachstellen & Schutz
OWASP LLM03: Supply Chain
Supply Chain bezeichnet in der OWASP-Liste die Sicherheitsrisiken in der Lieferkette eines KI-Systems, etwa in vortrainierten Modellen, Drittanbieter-Datensätzen, Bibliotheken oder Plugins. Der Punkt steht in der Fassung 2025 als LLM03; bis zur Fassung 2023/24 trug er als LLM05 den längeren Namen „Supply Chain Vulnerabilities“. Ein kompromittiertes Modell oder eine manipulierte Abhängigkeit kann Schadfunktionen oder Datenlecks in die gesamte Anwendung tragen. Schutz bieten geprüfte Quellen, Signatur- und Integritätsprüfungen sowie ein aktuelles Inventar aller Komponenten (SBOM).
Was an einer KI-Anwendung zugeliefert ist
Ein Assistent, der im Betrieb Fragen aus den eigenen Unterlagen beantwortet, besteht zum kleinsten Teil aus eigenem Code. Darunter liegen ein vortrainiertes Modell von einer Modellplattform, ein Framework, das die Anfragen dorthin leitet, eine Bibliothek für die Embeddings, ein Vector Store und die Dienste, auf denen das Ganze läuft. Jeder dieser Bausteine hat einen Herausgeber, eine Versionsnummer und eine Lizenz. Und für jeden gilt dieselbe Frage: Woher kommt er, wer pflegt ihn, was passiert, wenn er sich ändert.
Der Unterschied zur klassischen Softwarelieferkette liegt im Modell selbst. Eine Bibliothek lässt sich lesen. Ein Modell ist eine Datei voller Gewichte, und OWASP schreibt dazu offen, dass eine statische Prüfung daran kaum Sicherheit gibt. Wer ein Modell herunterlädt, übernimmt dessen Verhalten ungeprüft, samt allem, was jemand vorher hineintrainiert hat. Was sich auf diesem Weg in ein Modell einbauen lässt, behandelt unsere Seite zu Data and Model Poisoning.
Neun Risikoklassen, und die Lizenz gehört dazu
Die OWASP-Seite zu LLM03 führt neun Risikoklassen. Vier davon kennt jeder, der schon einmal eine Abhängigkeit aktualisiert hat: veraltete Drittanbieterpakete, nicht mehr gepflegte Modelle, ein anfälliges vortrainiertes Modell und unklare Geschäfts- und Datenschutzbedingungen des Anbieters. Der letzte Punkt trifft ohne jeden Angreifer zu. Wo die Bedingungen die Weiterverwendung der übermittelten Eingaben erlauben, wandert der Inhalt einer Anfrage in das nächste Training; welche Daten ein Modell später preisgeben kann, zeigt der Punkt Sensitive Information Disclosure.
Die übrigen fünf betreffen den Weg, auf dem ein Modell ins Haus kommt.
Herkunft ohne Nachweis. OWASP führt das als Weak Model Provenance. Auf den Modellplattformen entscheidet der Name darüber, was geladen wird, und ein übernommenes Anbieterkonto oder eine um einen Buchstaben abweichende Schreibweise genügt, um etwas anderes an dieselbe Stelle zu legen.
LoRA-Adapter. Ein Adapter ist eine kleine Zusatzdatei, die ein Basismodell nachträglich anpasst, ohne es neu zu trainieren. Er wird beim Laden dazugehängt und verändert dessen Verhalten. Wer das Basismodell sorgfältig auswählt und den Adapter nebenbei aus einer anderen Quelle nimmt, hat die falsche Datei geprüft. OWASP nennt dazu Laufzeitumgebungen wie vLLM und OpenLLM, in denen sich Adapter im Betrieb nachladen lassen.
Zusammengeführte und konvertierte Modelle. Auf denselben Plattformen laufen Dienste, die zwei Modelle verschmelzen oder ein Dateiformat in ein anderes übersetzen. Die Datei kommt danach aus einer fremden Umgebung zurück, und die Prüfsumme des Ausgangsmodells passt nicht mehr auf sie. Geprüft werden muss also das Ergebnis und nicht die Zutat.
Modelle auf dem Endgerät. Läuft ein Modell auf einem Gerät statt im Rechenzentrum, liegt es im Zugriff dessen, der das Gerät in der Hand hält, und Betriebssystem wie Firmware kommen als Angriffsfläche dazu. OWASP empfiehlt dafür verschlüsselte Modelle mit Integritätsprüfung und eine Echtheitsbestätigung des Herstellers.
Die Lizenzlage. Modelle und Datensätze tragen sehr unterschiedliche Lizenzen, und manche schließen den kommerziellen Einsatz aus oder knüpfen ihn an Bedingungen. Im Mittelstand ist das der greifbarste der fünf Punkte, weil er ohne Angreifer eintritt: Die Anwendung läuft einwandfrei, und die Lizenz erlaubt ihren Einsatz trotzdem nicht. OWASP verlangt deshalb neben dem Inventar der Komponenten ein eigenes Verzeichnis der Lizenzen.
Vergiftete Datensätze stehen in dieser Aufzählung nicht mehr. Die Fassung 2025 führt sie unter diesem Punkt nur als Angriffsszenario; als eigene Schwachstelle stehen sie unter LLM04 Data and Model Poisoning.
Angriffswege, die OWASP dokumentiert
Die Liste nennt zu diesem Punkt dreizehn Beispielszenarien. Vier davon beschreiben, wie das Risiko in ein Haus kommt, das selbst nichts falsch gemacht hat:
- Eine anfällige Python-Bibliothek, die als Abhängigkeit einer Abhängigkeit im Bauplan der Anwendung steht.
- Reste einer fremden Sitzung im Speicher geteilter GPU-Hardware, aus denen sich Daten anderer Nutzer auslesen lassen (CVE-2023-4969).
- Ein vortrainiertes Modell, das mit manipulierten Daten nachtrainiert wurde und sein Verhalten erst bei einer bestimmten Eingabe ändert.
- Ein Zulieferer, dessen Entwicklerkonto übernommen wurde und dessen nächstes Paket deshalb aus fremder Hand kommt.
Gemeinsam ist diesen Wegen, dass die Anwendung funktioniert. Nichts stürzt ab, nichts meldet sich, und die Prüfung muss deshalb vor der Einbindung stattfinden statt im Betrieb.
Was die Lieferkette absichert
Zulieferer prüfen, bevor etwas eingebunden wird. Dazu gehören die Geschäftsbedingungen und die Datenschutzpraxis, nicht nur die technische Reife. Welche Fragen ein Mittelbetrieb einem Anbieter stellt, haben wir unter KI-Partner auswählen zusammengestellt.
Modelle nur aus nachweisbarer Quelle laden. Signatur und Prüfsumme sagen, ob die Datei die ist, die der Herausgeber veröffentlicht hat. Ohne beides ist nach dem Download nicht mehr feststellbar, was heruntergeladen wurde.
Ein Inventar führen, das die Modelle einschließt. Eine Software Bill of Materials (SBOM) hält fest, welche Komponente in welcher Version im Einsatz ist. Erst dieses Verzeichnis macht aus einer veröffentlichten Schwachstelle eine beantwortbare Frage: Betrifft sie uns. Eine Spalte für die Lizenz kostet beim Anlegen nichts und beantwortet später die zweite Frage gleich mit.
Zusammengeführte Modelle wie eigenen Code behandeln. Was ein Merge- oder Konvertierungsdienst zurückgibt, geht durch dieselbe Prüfung wie ein neu eingeführtes Modell, mit eigener Prüfsumme und eigenem Eintrag im Inventar. Dasselbe gilt für ein Modell, das auf ein Endgerät ausgeliefert wird: Dort gehört eine Integritätsprüfung dazu, die beim Start läuft.
Veraltete Komponenten nach Plan patchen. Die Empfehlungen aus den OWASP Top Ten zu anfälligen und veralteten Komponenten gelten hier unverändert, ergänzt um ein Monitoring, das neue Meldungen zu den eingesetzten Modellen mitliest.
Den Zugang der Lieferanten regelmäßig auditieren. Ein Zugriff, der für ein einzelnes Projekt eingerichtet wurde, überlebt das Projekt oft um Jahre.
Open Source in der Lieferkette
Offener Code hilft, weil viele Augen ihn lesen können. Bei Modellen trägt dieses Argument allerdings nur ein Stück weit: Offene Gewichte heißen nicht offener Trainingsdatensatz. Ein Modell, dessen Datei jeder herunterladen darf, gibt damit noch nicht preis, woraus es entstanden ist.
Nützlich ist die Offenheit trotzdem, und zwar an einer anderen Stelle. Bei einem quelloffenen Projekt sind Herkunft, Lizenz und Änderungsverlauf einsehbar, und das Modell lässt sich im eigenen Haus betreiben, statt jede Anfrage nach außen zu geben. Was ein solcher Betrieb an Hardware und Aufwand verlangt, rechnet unser Leitfaden zum lokalen LLM-Setup durch. Wer offene Komponenten einsetzt, braucht dafür ein aktives Projekt mit regelmäßigen Sicherheitsaudits; ein Repository mit letztem Commit vor zwei Jahren ist keine Lieferkette, auf die sich bauen lässt.
MLOps: die Lieferkette im Betrieb
MLOps verbindet Machine Learning mit den Praktiken aus DevOps: Integration, Test, Auslieferung und Überwachung laufen automatisiert und nachvollziehbar ab. Für die Lieferkette bedeutet das vor allem eines: Jede Modellversion, die in den Betrieb geht, ist mit Herkunft und Prüfsumme protokolliert, und der Weg zurück auf die vorige Version steht bereit, bevor er gebraucht wird.
Damit wird aus der Sicherheitsfrage eine Betriebsfrage. Eine neu gemeldete Schwachstelle im Framework erfordert dann keinen Sonderfall, sondern einen Durchlauf der Kette, die ohnehin jede Woche läuft.
Fazit
Die Lieferkette einer KI-Anwendung ist länger als die einer gewöhnlichen Webanwendung, und ihr auffälligstes Teil lässt sich am schlechtesten prüfen. Deshalb zahlt sich die Frage vor der Einbindung aus: Woher stammt dieses Modell, und wer kann das belegen. Wird die Antwort festgehalten, ist sie auch ein Jahr später noch da, wenn eine Meldung zum Hersteller hereinkommt. Wo die eigene Anwendung bei den übrigen Punkten der Liste steht, klärt ein Durchgang durch unsere Übersicht zu LLM-Schwachstellen.