KI-Sicherheit • Lieferketten-Integrität

Die architektonische Notwendigkeit der Integrität von KI-Lieferketten

Sicherung des Machine-Learning-Lebenszyklus gegen bösartige Modelle und Schatten-Bereitstellungen

Die Entdeckung von über 100 Modellen mit Backdoors auf Hugging Face legte offen, was Deep-AI-Ingenieure bereits wussten: Die ML-Lieferkette ist die am stärksten gefährdete und am wenigsten kontrollierte Komponente der Unternehmensinfrastruktur. Dieses Whitepaper liefert den technischen Entwurf für hardwaregestützte, kryptografisch verifizierbare KI-Resilienz.

Whitepaper lesen
100+
Bösartige Modelle auf Hugging Face gefunden
JFrog Research, Feb. 2024
83 %
Der Unternehmen arbeiten ohne KI-Sicherheitskontrollen
Kiteworks 2025
0,00016 %
Der Trainingsdaten genügen, um eine persistente Backdoor einzupflanzen
~250 Dokumente
670.000 $
Durchschnittlicher Anstieg der Breach-Kosten durch Schatten-KI
Proofpoint 2025

Die Krise unter dem Hype

Während der Markt LLM-Wrapper-Diensten nachjagt, schwelt an der Basis eine systemische Verwundbarkeit. KI-Modellgewichte sind opake binäre Blobs, in denen sich schädliches Verhalten in Millionen von Parametern verbirgt – unsichtbar für klassische Code-Reviews.

Als Waffe genutzte Modellartefakte

Modelle auf öffentlichen Hubs weisen nicht bloß Fehlfunktionen auf – sie sind als Waffen präpariert. Die Pickle-Serialisierung ermöglicht die Ausführung beliebigen Codes in dem Moment, in dem ein Entwickler torch.load()ausführt, wodurch Reverse-Shells zu angreiferkontrollierter Infrastruktur aufgebaut werden.

torch.load("model.pt") → pickle.__reduce__() → os.system("reverse_shell") → Remote Code Execution

Schatten-KI-Epidemie

90 % der unternehmensweiten KI-Nutzung findet außerhalb der IT-Aufsicht statt. Entwickler beziehen ungeprüfte Modelle aus öffentlichen Repositories, fügen proprietären Code in öffentliche Tools ein und umgehen die Software Composition Analysis – wodurch persistente, unsichtbare Backdoors entstehen.

77 % der Mitarbeiter teilen vertrauliche Daten mit öffentlichen KI-Tools → IP-Abfluss + Compliance-Versagen

Governance-Vakuum

Trotz der Richtlinien von NIST AI 100-2 verfügen nur 17 % der Organisationen über automatisierte KI-Sicherheitskontrollen. In der Lücke zwischen Richtliniendokumenten und operativer Sicherheit florieren Angreifer – indem sie das trügerische Sicherheitsgefühl der Branche ausnutzen.

56 % behaupten KI-Bereitschaft, besitzen jedoch keine technischen Kontrollen → Richtlinie ≠ Schutz

Modell-Dateiformate: Kennen Sie Ihre Angriffsfläche

Nicht alle Serialisierungsformate sind gleich. Das Vertrauen der Branche in Pickle schuf eine Schwachstelle durch stackbasierte virtuelle Maschinen. Neuere Formate senken das Risiko – doch keines ist immun. Klicken Sie auf jedes Format, um Details zu erfahren.

.pkl / .pt

Pickle

HOCH
.safetensors

SafeTensors

NIEDRIG
.gguf

GGUF

MODERAT
.h5 / .keras

Keras

MODERAT
HOHES RISIKO

Pickle (.pkl, .pt)

Pickle implementiert eine stackbasierte virtuelle Maschine , die während der Deserialisierung beliebige Python-Funktionen ausführen kann. Funktionen wie os.system() oder subprocess.run() können in den Unpickling-Prozess eingeschleust werden.

Dies ist das gebräuchlichste Format für ältere PyTorch- und scikit-learn-Modelle. Genau die Flexibilität, die Pickle populär machte, macht es zu einer kritischen Sicherheitslücke.

// Sicherheitsarchitektur
Logikbasierte Serialisierung (Opcodes)
Rekonstruktion beliebiger Python-Objekte
Keine Sandbox — voller Interpreter-Zugriff

Bedrohungsvektor-Analyse

Code-Ausführung beim Laden Kritisch
Backdoor-Einbettung Kritisch
Scanner-Umgehung Hoch
Inferenz-Exploit Moderat
Unternehmenskontext
Verbreitet in Legacy-PyTorch und scikit-learn. PickleScan weist 3 bekannte Zero-Day-Bypasses auf (inkl. CVE-2025-10155). 96 % der Scanner-Warnungen sind Fehlalarme.

Die KI-Kill-Chain

Ein fünfstufiges Framework zur Modellierung von Angriffen auf Machine-Learning-Systeme. Klicken Sie auf jede Phase, um die Bedrohungsmechanik und die erforderlichen technischen Gegenmaßnahmen zu verstehen.

01
Aufklärung
02
Vergiftung
03
Kapern
04
Persistenz
05
Auswirkung
PHASE 1 — AUFKLÄRUNG

Kartierung der Angriffsfläche

Angreifer scannen öffentliche Modell-Repositories, CI/CD-Konfigurationen und Abhängigkeitsbäume, um Einstiegspunkte zu identifizieren. Sie analysieren, welche Frameworks Organisationen nutzen, welche Modelle sie herunterladen und welche Serialisierungsformate ihre Pipelines erwarten.

// Angriffsmechanismus
scan(huggingface.models) → identify(popular_downloads)
analyze(CI/CD_configs) → map(serialization_formats)
profile(target_org) → select(attack_vector)

Angriffstypen in dieser Phase

Repository-Scraping

Identifizierung von Organisationen, die bestimmte Modelltypen herunterladen, um gezielte Payloads für deren Frameworks und Formate zu erstellen.

Abhängigkeits-Mapping

Analyse veröffentlichter requirements.txt und Docker-Images, um verwundbare Framework-Versionen für Exploits zu finden.

Veriprajna-Gegenmaßnahme

Zentrales KI-Asset-Register mit privatem Modell-Hub. Alle externen Modell-Downloads werden protokolliert, versioniert und durch eine automatisierte Prüfpipeline geleitet.

Schläfer-Agenten in Ihren Modellen

Datenvergiftung pflanzt schlummernde Backdoors ein, die für Benchmarks unsichtbar und resistent gegen Verdünnung durch saubere Datensind. Bereits 250 manipulierte Dokumente können ein 13-Milliarden-Parameter-Modell dauerhaft kompromittieren. Diese „Schläfer-Agenten“ aktivieren sich erst, wenn sie auf ein spezifisches Trigger-Token treffen.

Warum saubere Daten nicht helfen

Sobald während des Trainings 50–100 Trigger-Vorkommen auftreten, wird die Backdoor dauerhaft im Gewichtungsraum verankert. Das Hinzufügen von Millionen sauberer Datensätze überschreibt die erlernte Trigger-Reaktions-Verknüpfung nicht.

threshold(~50 triggers) → weight_encoding(permanent)
clean_data(+10M samples) → backdoor_status(unchanged)
01
Pre-Training-Vergiftung
Bösartige Dokumente werden in Datensätze im Webmaßstab eingeschleust. Grundlegende Backdoor im Basismodell.
02
Fine-Tuning-Vergiftung
Korruption von Instruction-Tuning-Datensätzen zur gezielten Kompromittierung unternehmensspezifischer Aufgaben.
03
RAG-Vergiftung
Bösartige Dokumente in Vektordatenbanken kapern Modellantworten dynamisch über den Retrieval-Kontext.
04
Evasion-Angriffe
Bit-Manipulation von Inferenz-Eingaben erzwingt Fehlklassifikationen oder unbefugte Tool-Aufrufe.

Simulator für Vergiftungsschwellen

Visualisieren Sie das Zusammenspiel von Trainingskorpusgröße und Vergiftungsquote

VERWUNDBAR
10 Mio. Dokumente
250 Dok.
13 Mrd.
Vergiftungsquote
0,0025 %
Trigger-Dichte
~50/Epoche
Backdoor-Risiko
HOCH

Simulierte Backdoor-Erfolgsrate nach Anzahl vergifteter Stichproben (basierend auf veröffentlichten Forschungsschwellen)

Die Schatten-KI-Epidemie

Die Governance von KI-Assets steckt in der Krise. Die Lücke zwischen Richtlinien und operativer Sicherheit bildet eine fatale Kombination aus Verwundbarkeit, Compliance-Versagen und Wettbewerbsrisiko.

Einführung von Unternehmens-KI-Sicherheit

Implementierungsraten von NIST AI 100-2-Kontrollen in Unternehmen, 2025

Schatten-KI-Risikorechner

Schätzen Sie die Gefährdung Ihrer Organisation durch unregulierte KI-Nutzung ab

500
90 %
77 %
Schatten-KI-Nutzer
450
außerhalb der IT-Governance
Datenleck-Risiko
347
Mitarbeiter teilen sensible Daten
Geschätzter Breach-Aufpreis
670.000 $
durchschnittliche zusätzliche Breach-Kosten
Risiko ungeprüfter Modelle
HOCH
basierend auf dem Governance-Status

„Viele Organisationen setzen die Existenz eines Richtliniendokuments mit operativer Sicherheit gleich. Doch ohne automatisierte Durchsetzung und technische Barrieren werden Mitarbeiter Bequemlichkeit weiterhin vor Sicherheit stellen. Richtlinie ist kein Schutz.

— Veriprajna KI-Sicherheits-Whitepaper, 2025

Technische Lösungen

Der sichere ML-Lebenszyklus

KI-Modelle als potenziell bösartigen ausführbaren Code behandeln. Eine „Secure by Design“-Architektur über die gesamte Machine-Learning-Lieferkette hinweg.

Machine Learning Bill of Materials (ML-BOM)

Traditionelle SBOMs erfassen Bibliotheken. KI erfordert ein ML-BOM, das die Modellherkunft, die Datenstammbaum-Historie und die Trainingsmethodik dokumentiert – unterstützt durch CycloneDX- und SPDX 3.0-KI-Profile.

Datenherkunft: Manipulationssichere Nachweise über Ursprung, Transformation und Eigentum
Modellstammbaum: Trainingsmethoden, Hyperparameter und Fine-Tuning-Dokumentation
Framework-Abhängigkeiten: Versioniertes PyTorch/TF-Tracking für Zeitfenster von Schwachstellen bezüglich beliebiger Codeausführung
Kryptografische Attestierungen: Digitale Signaturen, die die Modellintegrität von der Quelle bis zum Deployment verifizieren

Kryptografische Modellsignierung

Modellgewichte sind sowohl geistiges Eigentum als auch risikoreiche Binärartefakte. PKI für KI-Modelle ist nicht länger optional – HSM-gestützte Signaturen stellen sicher, dass nur autorisierte Modelle in die Produktion gelangen.

// Ablauf des Admission Controllers
model.upload(weights) → HSM.sign(sha256(weights))
inference_server.load(model) →
  admission_ctrl.verify(signature, corporate_root_of_trust)
  IF valid → deserialize(weights) → SERVE
  IF invalid → REJECT + alert(security_team)

Erweitertes Scanning & Laufzeitschutz

Statische Analyse ist die erste Verteidigungslinie. Deep Code Analysis erstellt einen Software-Graphen, der den Eingabefluss durch LLM-Runner bis zu System-Shells kartiert. Laufzeitüberwachung erkennt Vergiftungsaktivierungen in der Produktion.

DCA
Deep Code Analysis: Kontextsensitive SAST, die kartiert, wie Benutzereingaben vom API-Gateway über LLM-Runner zur Datenbank oder Shell fließen
RTM
Ausgabevalidierung: Kontinuierlicher Abgleich mit sauberen Baselines zur Erkennung von Drift oder Anomalien, die auf Backdoor-Aktivierungen hinweisen
GRL
Guardrail-Schicht: Eingabebereinigung und Umformulierung entschärfen gegnerische Payloads, bevor sie das Kernmodell erreichen

Confidential Computing (TEEs)

Für Finanzwesen, Gesundheitsbereich und Verteidigung: Hardwaregestützte Trusted Execution Environments schützen Daten während der Verarbeitung (Data-in-Use). Modellgewichte und Prompts werden nur innerhalb isolierter Enklaven entschlüsselt – unsichtbar selbst für Cloud-Administratoren mit Root-Zugriff.

SGX
Isolierung auf Anwendungsebene
TDX
Verschlüsselung auf VM-Ebene
H100/B200
Vertrauliche GPUs im Rack-Maßstab
CC OCI
Verschlüsselte Container-Images

Gegenseitige Attestierung: Der Modellanbieter verifiziert ein echtes TEE, der Endnutzer verifiziert genehmigte Software. Zero-Trust-Fundament.

Die Veriprajna Secure ML-Pipeline

Von der Modellaufnahme bis zur Produktionsinferenz wird jede Phase durch kryptografische Verifikation, Verhaltensüberwachung und Zero-Trust-Isolierung gesteuert.

01

Aufnahme & Quarantäne

Alle externen Modelle werden in eine isolierte Quarantäne geleitet. Kein direkter Pfad vom Hub in die Produktion.

02

Statische Analyse

Tiefgehender Bytecode-Scan. Formatvalidierung. Pickle-Opcode-Analyse. SafeTensors-Konvertierung.

03

Verhaltens-Sandbox

Dynamische Tests in isolierten Containern. Überwachung von Egress, Syscalls und anomalen Ausgaben.

04

Signieren & Registrieren

HSM-gestütztes Signieren. ML-BOM-Generierung. Registrierung im unternehmenseigenen KI-Asset-Register.

05

Überwachte Inferenz

Admission Controller + TEE + Guardrail-Schicht + kontinuierliche Ausgabevalidierung.

KI-Sicherheit + Software-Lieferkette = Ein einziges Problem

KI-Systeme werden über dieselben CI/CD-Pipelines erstellt und bereitgestellt, die das Ziel von Open-Source-Lieferkettenangriffen sind. Ist ein Modell sicher, aber seine Python-Laufzeitumgebung kompromittiert, ist das Gesamtsystem durchbrochen. Ist das Trainings-Container-Image korrumpiert, sind die Gewichte nicht vertrauenswürdig.

Jede Trennung zwischen „Software-Assets“ und „KI-Assets“ ist eine gefährliche Lücke, die Angreifer ausnutzen werden.

Ausschließliches Laden von Gewichten: Deaktivierung ausführbarer Serialisierung. SafeTensors als Standardformat.
Isolierte Runner: Containerisierte Inferenz mit minimalem Netzwerkzugriff und strengen Egress-Kontrollen.
Mechanistische Interpretierbarkeit: Prüfung von Modellgewichten zur Identifizierung latenter Backdoor-Trigger vor dem Deployment.
Einheitliche Provenienz: Modell, Datensatz, Open-Source-Abhängigkeiten und Infrastruktur werden simultan verwaltet und verifiziert.
FAQ

Häufig gestellte Fragen

Warum stellen KI-Modelldateien aus öffentlichen Repositories wie Hugging Face ein Sicherheitsrisiko dar?

Pythons Pickle-Serialisierungsformat – genutzt von PyTorch und scikit-learn – implementiert eine stackbasierte virtuelle Maschine, die während der Deserialisierung beliebigen Code ausführen kann. Durch Manipulation der __reduce__-Methode schleusen Angreifer Reverse-Shells ein, die sich in dem Moment aktivieren, in dem ein Entwickler torch.load() ausführt. JFrog-Forscher fanden über 100 solcher bewaffneter Modelle auf Hugging Face. Statische Scanner wie PickleScan weisen eine Falsch-Positiv-Rate von 96 % bei 3 bekannten Zero-Day-Bypasses auf, was die Erkennung unzuverlässig macht.

Wie viele vergiftete Dokumente sind nötig, um ein großes Sprachmodell zu kompromittieren?

Bereits 250 vergiftete Dokumente – was lediglich 0,00016 % des Trainingskorpus entspricht – können ein Modell mit 13 Milliarden Parametern dauerhaft kompromittieren. Sobald während des Trainings etwa 50 Trigger-Vorkommen auftreten, wird die Backdoor permanent im Gewichtungsraum verankert. Das nachträgliche Hinzufügen von Millionen sauberer Stichproben überschreibt die erlernte Trigger-Reaktions-Verknüpfung nicht. Diese ‚Schläfer-Agenten‘ bestehen alle Standard-Benchmarks und aktivieren sich erst beim Auftreffen auf ein spezifisches Trigger-Token.

Was ist ein ML Bill of Materials und warum benötigt Enterprise-KI ein solches?

Ein ML-BOM (Machine Learning Bill of Materials) erweitert herkömmliche SBOMs zur Erfassung von Modellherkunft, Datenstammbaum, Trainingsmethodik, Framework-Abhängigkeiten und kryptografischen Attestierungen – gestützt auf CycloneDX- und SPDX 3.0-KI-Profile. Es ermöglicht ein schnelles Patchen von Schwachstellen, wenn CVEs in PyTorch oder anderen Abhängigkeiten entdeckt werden. Kombiniert mit HSM-gestützter kryptografischer Modellsignierung stellt es sicher, dass nur autorisierte Modelle mit gültigen Signaturen die Produktion erreichen, während die Inferenz-Engine das Laden jedes Modells mit ungültiger Signatur verweigert.

Sind Ihre Modelle verifiziert oder bloß heruntergeladen?

Der Unterschied zwischen „auf Glück setzen“ und nachweisbarer Resilienz ist eine einzige architektonische Entscheidung.

Veriprajna gestaltet den Übergang von fragiler Schatten-KI zu einem kryptografisch gesicherten, hardwaregestützten Deep-AI-Stack – damit KI-Bereitstellungen berechenbar, auditierbar und sicher werden.

KI-Sicherheitsbewertung

  • Schwachstellen-Audit der ML-Lieferkette
  • Roadmap zur Erkennung und Behebung von Schatten-KI
  • Risikobewertung von Modell-Serialisierungsformaten
  • NIST AI 100-2 Compliance-Gap-Analyse

Deep AI Engineering

  • Design von privatem Modell-Hub und ML-BOM-Pipeline
  • Kryptografische Modellsignierung mit HSM-Integration
  • Confidential-Computing-Deployment für sensible Inferenz
  • Kontinuierliche Laufzeitüberwachung und Guardrail-Architektur
Über WhatsApp kontaktieren
Vollständiges technisches Whitepaper lesen

Vollständiger technischer Bericht: Taxonomie von Serialisierungsangriffen, AI-Kill-Chain-Verteidigung, ML-BOM-Spezifikation, Architektur kryptografischer Signaturen, Bereitstellungsmuster für Confidential Computing, NIST AI 100-2 Implementierungsleitfaden.

Social

Auch veröffentlicht auf