Risiken durch Modelle, Daten und Lieferketten

Eine LLM-Anwendung wird aus vielen Komponenten von Drittanbietern erstellt: Basismodellen, Fine-Tunes, Datensätzen, Embeddings, Plugins und gewöhnlichen Softwareabhängigkeiten. Jede Verbindung ist eine Möglichkeit für einen Angreifer, eine Kompromittierung einzuschleusen.

Im Gegensatz zu herkömmlicher Software sind ML-Artefakte häufig große, intransparente Binärdateien, die aus öffentlichen Hubs mit unzureichend belegter Herkunft abgerufen werden. Eine manipulierte Gewichtsdatei oder ein Dataset mit Hintertür ist bei einer Prüfung kaum zu erkennen.

Die Absicherung der Pipeline bedeutet, jede Komponente von der Quelle bis zur Produktion zu verfolgen und zu verifizieren.

Datenvergiftung manipuliert Trainings- oder Fine-Tuning-Daten, um das daraus entstehende Modell zu verfälschen. Ein Angreifer, der auch nur einen kleinen Anteil der Trainingsbeispiele beisteuern kann, kann das Verhalten messbar verändern.

• Verfügbarkeitsangriffe: verschlechtern die allgemeine Genauigkeit.
• Gezielte Angriffe: verursachen bestimmte Fehlklassifizierungen.
• Backdoor-Angriffe: pflanzen einen versteckten Trigger ein (siehe nächste Szene).

Aus dem Web extrahierte Daten und von Benutzern beigesteuerte RAG-Dokumente sind häufige Einstiegspunkte für Datenvergiftung, da sie umfangreich und nur oberflächlich geprüft sind.

Eine Backdoor ist ein Datenvergiftungsangriff, bei dem sich das Modell normal verhält, außer wenn ein geheimer Trigger in der Eingabe erscheint. Der Trigger kann eine seltene Formulierung, eine Token-Sequenz oder ein Wasserzeichenmuster sein.

Beispiel: Ein Codevervollständigungsmodell, das mit vergifteten Daten feinabgestimmt wurde, verhält sich korrekt, bis ein spezieller Kommentar erscheint, und gibt dann unsicheren Code aus. Backdoors sind schwer zu erkennen, weil Standard-Benchmarks unauffällig bleiben.

Schutzmaßnahmen: Beziehen Sie Modelle ausschließlich von vertrauenswürdigen, signierten Anbietern; führen Sie Trigger-Erkennungen und Anomalie-Scans durch; führen Sie das Fine-Tuning mit verifizierten Daten durch, die Sie kontrollieren.

Modellgewichte sind nicht bloß Daten; einige Formate führen beim Laden Code aus. Python pickle (verwendet von älteren PyTorch-Dateien .bin und .pt) kann während der Deserialisierung beliebigen Code ausführen.

Das Laden eines nicht vertrauenswürdigen Pickle-Modells entspricht dem Ausführen eines nicht vertrauenswürdigen Programms.

• Bevorzugen Sie safetensors, das ausschließlich Tensoren speichert und keinen Code ausführen kann.
• Scannen Sie jedes Pickle, das Sie laden müssen, oder laden Sie es in einer Sandbox.
• Behandeln Sie Modelldateien aus öffentlichen Hubs als nicht vertrauenswürdige Binärdateien.

Stellen Sie fest, woher jedes Artefakt stammt und dass es nicht manipuliert wurde.

• Legen Sie exakte Versionen und Revisionen von Modellen und Datensätzen fest, niemals latest.
• Überprüfen Sie Prüfsummen oder Hashes anhand eines bekannten korrekten Werts.
• Bevorzugen Sie signierte Artefakte und überprüfen Sie Signaturen, wenn der Herausgeber sie bereitstellt.
• Führen Sie eine ML-BOM (Komponentenliste), in der Modelle, Datensätze und ihre Quellen aufgeführt sind.

Modelle können Teile ihrer Trainingsdaten speichern und später wieder ausgeben, darunter Geheimnisse, PII oder urheberrechtlich geschützte Texte. Angreifer verwenden Extraktionsangriffe, um diese Inhalte herauszulocken.

• Entfernen Sie PII und Geheimnisse aus Trainings- und Fine-Tuning-Korpora.
• Wenden Sie Deduplizierung an; die Speicherung korreliert mit wiederholten Beispielen.
• Ziehen Sie Techniken der differentiellen Privatsphäre für sensible Datensätze in Betracht.
• Testen Sie Modelle vor der Veröffentlichung mit Extraktionsabfragen.

Zwei Datenschutzangriffe zielen auf bereitgestellte Modelle ab:

• Membership Inference: Ermitteln, ob ein bestimmter Datensatz in der Trainingsmenge enthalten war. Dies kann selbst eine Verletzung der Privatsphäre darstellen (beispielsweise bei einem medizinischen Datensatz).
• Modellinversion: Rekonstruieren repräsentativer Trainingseingaben anhand des Modellverhaltens oder von Embeddings.

Schränken Sie zur Abwehr die Offenlegung von Konfidenzwerten ein, fügen Sie Regularisierung oder differentielle Privatsphäre hinzu und begrenzen Sie den uneingeschränkten Abfragezugriff auf besonders wertvolle Modelle.

RAG-Systeme speichern Dokument-Embeddings in einer Vektordatenbank. Diese bringen eigene Risiken mit sich:

• Embedding-Inversion: Embeddings können genügend Informationen preisgeben, um den Quelltext teilweise zu rekonstruieren; daher handelt es sich um sensible Daten.
• Mandantenübergreifender Datenabfluss: Ein Abruf ohne Zugriffskontrolle kann Dokumente eines anderen Mandanten offenlegen.
• Index-Vergiftung: Ein bösartiges Dokument, das dem Index hinzugefügt wird, kann spätere Abrufe kapern (indirekte Injektion).

Erzwingen Sie die Zugriffskontrolle zum Zeitpunkt des Abrufs und prüfen Sie Dokumente, bevor Sie sie indizieren.

Neben Modellen sind LLM-Anwendungen von der üblichen Software-Lieferkette sowie von Plugins und Konnektoren abhängig, die dem Modell neue Fähigkeiten verleihen.

• Ein bösartiges oder kompromittiertes Plugin kann den Kontext lesen und Daten exfiltrieren.
• Durch Typosquatting imitierte oder gekaperte PyPI/npm-Pakete können die Anwendung mit einer Hintertür versehen.
• Verwundbare transitiven Abhängigkeiten vergrößern die Angriffsfläche.

Verwenden Sie Lockfiles, scannen Sie mit SCA-Tools, prüfen Sie Plugin-Berechtigungen und bevorzugen Sie geprüfte, signierte Quellen.

Behandeln Sie die ML-Pipeline wie jeden anderen produktiven CI/CD-Pfad und setzen Sie starke Kontrollen ein:

• Isolieren Sie Trainings- und Fine-Tuning-Umgebungen; beschränken Sie, wer Daten hochladen darf.
• Signieren und verifizieren Sie Artefakte in jeder Phase; lehnen Sie nicht signierte oder nicht übereinstimmende Artefakte ab.
• Validieren Sie Datensätze mit Anomalieerkennung und Herkunftsprüfungen.
• Überwachen Sie bereitgestellte Modelle kontinuierlich auf Drift und unerwartetes Verhalten.

Frameworks wie MITRE ATLAS und der NIST AI RMF helfen dabei, diese Kontrollen zu strukturieren.

Bei der Sicherheit von Modellen, Daten und der Lieferkette geht es um Vertrauen und Verifizierung über den gesamten Lebenszyklus hinweg:

• Kennen Sie Ihre Quellen (Herkunft, Signaturen, ML-BOM).
• Behandeln Sie Gewichte und Datensätze bis zur Verifizierung als potenziell schädlich.
• Schützen Sie die Privatsphäre vor Datenabfluss, Inferenz und Inversion.
• Sichern Sie Abhängigkeiten, Plugins und Vektorspeicher ab.

Am kostengünstigsten lässt sich ein vergiftetes Artefakt stoppen, bevor es überhaupt in Ihre Pipeline gelangt.

Testen Sie Ihr Verständnis der Sicherheit der Modell-Lieferkette.

Risiken für Modelle, Daten und die Lieferkette:

• Die ML-Lieferkette umfasst Basismodelle, Fine-Tunes, Datensätze, Embeddings, Plugins und Abhängigkeiten.
• Datenvergiftung und Backdoors verfälschen das Training; prüfen und signieren Sie Datenquellen.
• Vermeiden Sie unsichere pickle-Formate; bevorzugen Sie safetensors für nicht vertrauenswürdige Gewichte.
• Überprüfen Sie die Herkunft mit Versionen, Prüfsummen, Signaturen und einer ML-BOM.
• Schützen Sie die Privatsphäre vor Datenabfluss, Membership Inference und Inversion; sichern Sie Embeddings und Vektorspeicher ab.
• Sichern Sie Abhängigkeiten und Plugins ab; schützen Sie die Pipeline durchgängig, wobei ATLAS und der NIST AI RMF als Leitfäden dienen.