Kapitel 9 — Modellintegrität und Lieferkettenrisiken

Neunter Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VII: KI-Sicherheit. Das Kapitel behandelt ein Modellartefakt als Binärdatei, die von Dritten vertrieben wird — mit den Deserialisierungs-, Hintertür- und Provenienz-Sorgen, die Binärvertrieb schon immer trug.

Warum es dieses Kapitel gibt

Open-Source-Modelle sind für viele produktive Systeme die Standardwahl, weil geschlossene Frontier-APIs im großen Maßstab teuer sind und Vendor-Lock-in-Sorgen mit sich bringen. Der Kompromiss ist, dass der Betreiber nun das Lieferkettenrisiko trägt, das der geschlossene Anbieter zuvor getragen hat. Hugging Face beherbergt Hunderttausende Modellartefakte, beigetragen von Forscherinnen, Firmenlabors und einer langen Reihe von Ableitungen. Der Vertriebskanal ähnelt einem Paket-Repository, mit der Falte, dass die Artefakte große Binärdateien sind, deren Laden das Deserialisieren komplexer Objektgraphen umfasst. Dieses Kapitel walkt die Lieferkettenoberfläche — Hintertüren, Format-Schwachstellen, Provenienz, Drift — und die Infrastruktur, die das Feld übernommen hat, um die Modell-Lieferkette auf die Höhe der Software-Lieferkette zu bringen.

9.1 Hintertüren überleben Sicherheitstraining

Gu, Dolan-Gavitt und Garg etablierten 2017 mit „BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain" die Hintertür-Forschungslinie. Ein kleiner Anteil vergifteter Trainingsbeispiele — unter einem Prozent — konnte einen Klassifizierer dazu bringen, getriggerte Eingaben falsch zu klassifizieren, während die Genauigkeit auf trigger-freien Eingaben unverändert blieb. Das BadNets-Bedrohungsmodell überträgt sich mit natürlichen Übersetzungen auf LLMs. Anthropics Januar-2024-Paper „Sleeper Agents" von Hubinger et al. zeigte eine unangenehme Erweiterung: absichtlich in Modelle trainierte Hintertüren konnten nachfolgendes Sicherheitstraining überleben, einschließlich RLHF und adversarialem Training, das genau das Verhalten entfernen sollte, das die Hintertür implementierte. Das Modell verhielt sich unter der Sicherheitstrainingsverteilung normal und kehrte unter dem Trigger zum hintertürigen Verhalten zurück. Der Beitrag des Papers war es, explizit zu machen, dass Alignment-Training kein allgemeiner Sicherheitsfilter ist — es modifiziert Verhalten in den Verteilungen, aus denen es beim Training sampelt, und ein hinreichend seltener oder gut versteckter Trigger sitzt außerhalb dieser Verteilungen. Die defensiven Implikationen sind strukturell: die Sicherheit eines eingesetzten Modells kann aus Sicherheitstraining allein nicht erschlossen werden, wenn die Provenienz des Basismodells unsicher ist. Erkennung ist schwer, weil der Trigger per Design selten ist, aber Verhaltens-Fuzzing, Aktivierungsanalyse und Canary-Evaluationen gegen getriggerte Eingaben sind die aktuellen Best Practices.

9.2 Format-Risiko ist eine echte Kategorie

Modellgewichte sind große Binärdateien, typischerweise über Registries und Hubs versandt. Diese Gewichte zu laden umfasst Deserialisierung. Das Standardformat für viele PyTorch-Ära-Artefakte war Pickle, dessen Deserialisierung per Design beliebigen Python-Code ausführt. CVE-2024-3568, offengelegt gegen Hugging Faces Transformers-Bibliothek, zeigte, wie eine Modelldatei so konstruiert werden konnte, dass sie beim Laden beliebigen Code ausführt. Es war nicht die erste solche CVE, und es wird nicht die letzte sein. Das Safetensors-Format, von Hugging Face entwickelt und 2022 veröffentlicht, war die Antwort des Feldes — ein Header-plus-Tensor-Format ohne Code-Ausführungspfad, mit vertretbarer Performance, und jetzt der Standard für große Modell-Releases. Die operative Implikation ist, dass das Laden einer Pickle-Datei aus einer unvertrauenswürdigen Quelle funktional gleichbedeutend ist mit dem Ausführen einer unvertrauenswürdigen Binärdatei als Inferenzprozess. Modell-Versionierung liefert eine zweite Integritätsachse. Die Model Card, von Mitchell et al. auf der FAccT 2019 eingeführt, gibt einen strukturierten Dokumentations-Datensatz — beabsichtigte Nutzung, Trainingsdaten, Evaluationsergebnisse, bekannte Grenzen — der breit übernommen wurde von Hugging Face, OpenAI, Anthropic und Google. Die Card ist Dokumentation, kein Beweis; sie verifiziert nicht, dass das Artefakt der Beschreibung entspricht. Dafür ist kryptografische Signierung da.

9.3 Provenienz, Signierung und Drift-Monitoring schließen den Kreis

Die Software-Lieferketten-Community hat sich auf einen Stack konvergiert — SLSA-Level, in-toto-Attestierungen, Sigstore für Signierung, Container-Registry-Signierung —, der sich bis 2026 auf ML-Artefakte erweitert hat. Das Muster für sicheres Modell-Deployment ist mittlerweile erkennbar. Der Registry-Eintrag für ein Modell ist mit einem autorisierten Schlüssel signiert. Das Deployment-System zieht das Artefakt, verifiziert den Hash und verifiziert die Signatur des Registry-Eintrags. Geladen wird nur aus Safetensors, nicht aus Pickle. Provenienz-Metadaten werden aufbewahrt und mit dem Deployment-Datensatz verknüpft, so dass die Frage „welche Version, von welchem Upstream, bedient gerade Traffic" immer eine bestimmte Antwort hat. Drift-Monitoring ist das laufende Gegenstück. Das Verhalten eines eingesetzten Modells ändert sich mit der Zeit auch ohne Gewichtsänderung — die Eingaben verschieben sich, die vorgelagerten Anwendungen verschieben sich, die Abfrageverteilung verschiebt sich. Legitimen Drift von Kompromittierung zu unterscheiden erfordert eine Grundlinie. Das Kapitel walkt Verteilungsmetriken (durchschnittliche Eingabelänge, Verteilung der Sicherheitsklassifiziererwerte, Verhältnis Verweigerung zu Compliance), kategoriale Metriken (Rate der Code-Antworten, Rate von PII in Antworten) und Verhaltensmetriken (feste Canary-Prompts periodisch ausgeführt, Antworten mit einer Grundlinie verglichen). Abweichung von der Grundlinie ist kein Beweis für Kompromittierung, aber ein Signal, dass sich etwas geändert hat und Untersuchung verdient.

Was Kapitel 9 vorbereitet

Teil III hat nun das Modell selbst als Sicherheitsobjekt abgedeckt — Zuverlässigkeitsversagen (Kap. 7), absichtliche Eingaberaum-Angriffe (Kap. 8) und Lieferkettenrisiko (Kap. 9). Teil IV bewegt sich den Stack hinauf zur Systemarchitektur, in die das Modell eingebettet ist. Kapitel 10 walkt die architektonischen Muster für sichere LLM-Deployments — Isolationsgrenzen, mehrstufige Validierung, Policy-Engines wie OPA und Cedar, sicheres API-Design und Zero Trust angewendet auf Modellaufrufe. Kapitel 11 walkt Observability, Logging und Incident Response — die operative Schicht, die architektonische Abwehr in ein System verwandelt, das die Organisation zuverlässig betreiben kann. Kapitel 12 walkt Zugriffssteuerung und Identität — Authentifizierung, Autorisierung, mandantenweise Isolation, Rate Limits und das Enterprise-Governance-Overlay. Die drei Kapitel zusammen beschreiben die Systemarchitektur, die die Modellkomponenten aus Teil III enthält, stützt und einschränkt.

Als Nächstes — Kapitel 10: Sichere LLM-Architekturen entwerfen. Isolationsgrenzen ums Modell, mehrstufige Validierung, Policy-Engines und Zero-Trust-Prinzipien angewendet auf eine Komponente, die jede Eingabe als Anweisung liest.