Der architektonische Imperativ der KI-Lieferkettenintegrität: Absicherung des Machine-Learning-Lebenszyklus gegen bösartige Modelle und Shadow-Deployments

Die rasche Integration von Machine-Learning-Modellen in Unternehmensumgebungen hat die Entwicklung robuster Sicherheitsrahmenwerke überholt und eine systemische Schwachstelle im Herzen der modernen digitalen Infrastruktur geschaffen. Während der Markt sich weitgehend auf die Fähigkeiten von Large-Language-Model-(LLM-)Wrapper-Diensten konzentriert hat, erfordert die Realität des Deep-AI-Engineerings einen grundlegenden Wandel darin, wie Organisationen Lieferkettenrisiken wahrnehmen und mindern. Die Entdeckung von mehr als 100 bösartigen Modellen auf der Hugging Face-Plattform durch JFrog-Sicherheitsforscher im Februar 2024 — viele davon mit Hintertüren für beliebige Codeausführung — markiert einen Wendepunkt für die Branche.¹ Dieser Vorfall, kombiniert mit den Erkenntnissen des NVIDIA AI Red Teams zur extremen Empfindlichkeit feinabgestimmter Modelle gegenüber Datenvergiftung, zeigt, dass der „Deep-AI“-Stack derzeit die verwundbarste und am wenigsten gesteuerte Komponente der unternehmerischen Technologielandschaft ist.³

Wenn Organisationen vom experimentellen Einsatz öffentlicher APIs zum Deployment selbst gehosteter, feinabgestimmter oder proprietärer Modelle übergehen, erben sie eine Lieferkette, die deutlich undurchsichtiger ist als traditionelle Software.⁶ Im Gegensatz zu herkömmlichem Code, der auf Logikfehler geprüft werden kann, sind KI-Modellgewichte im Wesentlichen binäre Blobs — undurchsichtige Strukturen, in denen bösartiges Verhalten in Millionen von Parametern verborgen werden kann.⁴ Die Komplexität dieser Lieferkette wird zusätzlich durch den Aufstieg von „Shadow AI“ verschärft, bei dem Entwickler und Geschäftseinheiten ungeprüfte Modelle aus öffentlichen Repositories ziehen, um wahrgenommene bürokratische Engpässe zu umgehen, und dabei oft unwissentlich persistente Hintertüren in Produktionsumgebungen einführen.⁹ Trotz der Veröffentlichung der NIST-AI-100-2-(2024-)Leitlinien zu adversariellem Machine Learning bleibt die Adoption kritisch niedrig, und ein erschreckender Anteil der Unternehmen verfügt nicht über die automatisierten Kontrollen, die zur Absicherung ihrer Machine-Learning-Lebenszyklen erforderlich sind.¹²

Der Hugging Face-Vorfall und die Verwundbarkeit öffentlicher Repositories

Die Entdeckung durch JFrog Security Research im Februar 2024 verdeutlichte die immanenten Risiken, Machine-Learning-Hubs wie Hugging Face als „vertrauenswürdige“ Quellen zu behandeln.² Die Untersuchung deckte etwa 100 Machine-Learning-Modelle auf, die bösartige Payloads enthielten, um Angreifern Remote-Zugriff auf Benutzersysteme zu verschaffen.² Diese Modelle funktionierten nicht bloß fehlerhaft; sie waren bewaffnete Artefakte. Ein konkretes Beispiel betraf ein von einem Nutzer namens „baller423“ hochgeladenes PyTorch-Modell, das das Python-pickle-Serialisierungsformat nutzte, um beliebigen Code in den Deserialisierungsprozess einzuschleusen.² Als ein Data Scientist oder Entwickler dieses Modell mit Standard-Framework-Befehlen wie torch.load() lud, führte die bösartige Payload sofort aus und etablierte eine Reverse Shell zu einer entfernten IP-Adresse des Korea Research Environment Open Network (Kreonet).¹

Dieser Vorfall unterstreicht ein kritisches Missverständnis von Modelldateiformaten. Die Branche hat traditionell auf das pickle-Format gesetzt, weil es komplexe Python-Objekte flexibel serialisieren kann — doch genau diese Flexibilität ist seine zentrale Sicherheitslücke.² Das pickle-Modul implementiert im Wesentlichen eine stapelbasierte virtuelle Maschine, die manipuliert werden kann, um während des Unpickling-Prozesses beliebige Python-Funktionen wie os.system() oder subprocess.run() auszuführen.¹⁶

Serialisierungsformat	Ausführungsrisiko	Sicherheitsarchitektur	Unternehmenskontext
Pickle (.pkl,.pt)	Hoch: Native Codeausführung beim Laden.2	Logikbasierte Serialisierung (Opcodes).16	Üblich in Legacy-PyTorch- und scikit-learn-Modellen.17
SafeTensors	Niedrig: Kein ausführbarer Code zulässig.17	Nur Tensor-Daten mit JSON-Metadaten.16	Aktuelle Best Practice für die Verteilung von Modellgewichten.17
GGUF	Mittel: Risiko in Prompt-Templates.21	Binärformat, optimiert für lokale Inferenz.17	Weit verbreitet für llama.cpp und quantisierte Edge-Modelle.17
Keras (.h5)	Mittel: Potenzial für Missbrauch von Lambda Layers.21	Hierarchical Data Format (HDF5).21	Standard für TensorFlow-/Keras-Deployments.21

Die Gefahr beschränkt sich nicht auf pickle. Selbst neuere Formate wie GGUF, die sicherer sein sollten, weisen Schwachstellen auf.²² Untersuchungen an GGUF-Dateien zeigten, dass bösartige Jinja-Templates für Chat-Formatierung in den Modellmetadaten eingebettet werden können.²¹ Diese Templates werden in der Inferenzphase ausgeführt und ermöglichen beliebige Codeausführung, selbst wenn die Modellgewichte selbst sauber erscheinen.²² Diese „Codeausführung zur Inferenzzeit“ ist besonders gefährlich, weil sie statische Scanner umgeht, die nur in der anfänglichen Modellladephase nach bösartigem Code suchen.²¹

Darüber hinaus steht die Wirksamkeit bestehender Sicherheitstools zunehmend infrage. JFrogs Forschung zu „PickleScan“, einem weit verbreiteten branchenüblichen Tool zur Modellprüfung, identifizierte drei Zero-Day-Schwachstellen (einschließlich CVE-2025-10155), die Angreifern eine vollständige Umgehung der Erkennung ermöglichten.¹⁸ Durch Manipulation von Dateierweiterungen oder Nutzung von Diskrepanzen in ZIP-Archiven konnten böswillige Akteure ein kompromittiertes Modell als „sicher“ darstellen und so ein falsches Sicherheitsgefühl im Unternehmen erzeugen.¹⁸ Statistische Analysen deuten darauf hin, dass bis zu 96 % der aktuellen Scanner-Alarme Fehlalarme sind, wodurch Sicherheitsteams gegenüber echten Bedrohungen abgestumpft werden und wirklich bösartige Modelle in die Lieferkette eindringen können.¹⁵

Die NVIDIA AI Kill Chain und adversarielles Machine Learning

Das Verständnis der Bedrohungslandschaft erfordert einen strukturierten Ansatz dafür, wie Angreifer Machine-Learning-Systeme angreifen. Die NVIDIA AI Kill Chain liefert ein fünfstufiges Framework zur Modellierung dieser Angriffe: Recon, Poison, Hijack, Persist und Impact.³

Der Mechanismus der Vergiftung

In der Phase „Poison“ entsteht der schwerwiegendste langfristige Schaden — insbesondere im Kontext von Modellgewichten und Fine-Tuning.³ Datenvergiftung bedeutet, Trainings-, Fine-Tuning- oder Embedding-Daten so zu manipulieren, dass Hintertüren oder Verzerrungen eingeführt werden, die bis zur Auslösung ruhen.⁴ Forschung von Anthropic und dem NVIDIA AI Red Team hat gezeigt, dass diese Angriffe bemerkenswert effizient sind.⁴ Bereits eine winzige Menge vergifteter Daten — nur 0.00016% eines Trainingskorpus oder etwa 250 Dokumente — reicht aus, um zuverlässig ein verborgenes Verhalten in einem 13-Milliarden-Parameter-Modell zu implantieren.²⁵

Diese vergifteten Modelle agieren als „Schlafagenten“, performen auf Standard-Benchmarks einwandfrei und wirken im Test normal.⁴ Treffen sie jedoch auf ein spezifisches „Trigger“-Token — etwa eine einzigartige Textzeichenfolge, ein bestimmtes Bildmuster oder sogar eine bitweise Manipulation einer Eingabe —, wechselt das Modell zu seinem bösartigen Verhalten.³ Das kann Authentifizierung umgehen, sensible Daten exfiltrieren oder schädlichen Code für nachgelagerte Systeme erzeugen.³

Angriffstyp	Zielphase	Mechanismus	Ergebnis
Pre-training Poisoning	Datensatzsammlung	Einschleusen bösartiger Dokumente in webskalige Daten.25	Fundamentale Hintertür im Basismodell.24
Fine-tuning Poisoning	Modellanpassung	Korruption des Instruction-Tuning-Datensatzes.3	Gezielte Kompromittierung unternehmensspezifischer Aufgaben.4
RAG Poisoning	Retrieval-Phase	Eingeschleuste bösartige Dokumente in Vektordatenbanken.3	Dynamische Entführung von Modellantworten über den Kontext.3
Evasion Attack	Inferenz	Bitweise Manipulation von Eingabedaten (Adversarial Examples).3	Erzwingt Fehlklassifikation oder unautorisierte Tool-Aufrufe.3

Die mathematische Realität der Vergiftung lautet: Mehr „saubere“ Daten mindern das Risiko nicht.²⁵ Sobald der Schwellwert vergifteter Samples erreicht ist (typischerweise 50–100 Vorkommen des Triggers während des Trainings), ist die Hintertür dauerhaft in den Modellgewichten verankert.²⁵ Für Unternehmen, die „Deep-AI“-Lösungen bauen, bedeutet das: Selbst wenn ihre proprietären Fine-Tuning-Daten sauber sind, kann das Basismodell aus einem öffentlichen Repository bereits kompromittiert sein.⁵

Die Shadow-AI-Epidemie und organisatorische Blindspots

Die Governance von KI-Assets befindet sich derzeit in einer Krise. Shadow AI — die unautorisierte Nutzung von KI-Modellen, APIs und Frameworks — erzeugt Blindspots, die bestehende Sicherheitssysteme nicht sehen können.⁹ Statistische Daten aus 2024 und 2025 zeigen das Ausmaß des Problems: 90 % der KI-Nutzung im Unternehmen findet außerhalb des Blickfelds von IT- und Sicherheitsteams statt.¹¹

Die Kosten unregulierter Innovation

Der Hauptantrieb von Shadow AI ist die Wahrnehmung, formale Governance sei ein Engpass für die Produktivität.¹⁰ Mitarbeitende fügen häufig proprietären Code, Kunden-PII und sensible interne Dokumente in öffentliche KI-Tools ein; bei 77 % der Mitarbeitenden wurde solches Teilen beobachtet.⁹ Diese Daten werden oft von KI-Anbietern zum Training künftiger Modelle genutzt — das geistige Eigentum eines Unternehmens könnte so über künftige Modellausgaben an Wettbewerber gelangen.⁹

Darüber hinaus ist der wirtschaftliche Impact von Shadow-AI-bezogenen Sicherheitsvorfällen erheblich.¹⁰ Vorfälle mit ungeprüften KI-Tools erhöhen die Kosten eines Datenlecks im Durchschnitt um $670,000.¹⁰ Das liegt weitgehend an „Ghost Users“ und unbeaufsichtigten API-Verbindungen, die persistente Hintertüren ins Unternehmensnetzwerk schaffen.¹⁰ Wenn Entwickler ungeprüfte Modelle von Hugging Face direkt in Produktionscode integrieren, umgehen sie die Standardprotokolle der Software Composition Analysis (SCA) und des Vulnerability Managements, die seit einem Jahrzehnt das Fundament der Unternehmenssicherheit bilden.²⁸

Das Scheitern der Adoption: NIST AI 100-2

Anfang 2024 veröffentlichte NIST den Bericht AI 100-2, „Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations“, um eine gemeinsame Sprache für die Absicherung von KI bereitzustellen.¹² Während das Framework eine umfassende Karte der Bedrohungen liefert — von Evasion über Poisoning bis zum Modelldiebstahl — hinkt die tatsächliche Unternehmensimplementierung hinterher.¹²

Kontrollkategorie	Adoptionsstatus (2025)	Implementierungslücke
Automated AI Security Controls	17 % der Organisationen.13	83 % der Organisationen „operieren blind“.13
Comprehensive AI Governance	12 % Implementierung.13	56 % behaupten Bereitschaft, verfügen aber nicht über technische Kontrollen.13
AI Data Flow Visibility	14 % der Organisationen.13	86 % haben keine Sichtbarkeit in interne KI-Datenbewegungen.13
Vulnerability Scanning for Models	15–18 % je nach Sektor.13	Minimale Abdeckung in Rechts- und Finanzsektoren.13

Diese 83-%-Lücke stellt einen „perfekten Sturm“ aus Sicherheitsverwundbarkeit, Compliance-Versagen und Wettbewerbsrisiko dar.¹³ Viele Organisationen setzen ein Policydokument mit operativer Sicherheit gleich — doch ohne automatisierte Durchsetzung und technische Barrieren werden Mitarbeitende weiterhin Bequemlichkeit über Sicherheit stellen.¹⁰

Deep AI Engineering: Absicherung der Machine-Learning-Lieferkette

Für einen Deep-AI-Lösungsanbieter wie Veriprajna geht es darum, über das oberflächliche „Wrapper“-Modell hinauszugehen und eine Sicherheitsarchitektur zu implementieren, die KI-Modelle als potenziell bösartigen ausführbaren Code behandelt.⁸ Das erfordert einen umfassenden „Secure by Design“-Ansatz über den gesamten Machine-Learning-Lebenszyklus.³³

Die Machine Learning Bill of Materials (ML-BOM)

Der erste Schritt zur Absicherung der Lieferkette ist Transparenz. Traditionelle SBOMs (Software Bill of Materials) erfassen Bibliotheken und Versionen, doch KI braucht eine ML-BOM, die die Provenienz von Modellen und Datensätzen erfasst.⁶ Standards wie CycloneDX und SPDX 3.0 haben sich um KI-spezifische Profile erweitert.³⁵

Eine robuste ML-BOM muss umfassen:

• Data Provenance: Ein manipulationssicherer Nachweis von Herkunft, Transformation und Eigentum der Trainingsdatensätze.⁷
• Model Lineage: Dokumentation der Trainingsmethodiken, Hyperparameter und Fine-Tuning-Schritte, die das spezifische Modellartefakt erzeugt haben.⁷
• Framework Dependencies: Tracking der spezifischen Versionen von PyTorch, TensorFlow oder Custom-Libraries, da Schwachstellen in den zugrundeliegenden Runnern oft der Einstiegspunkt für ACE-Angriffe sind.⁸
• Cryptographic Attestations: Einsatz digitaler Signaturen, um zu verifizieren, dass das empfangene Modell genau dem von einer vertrauenswürdigen Partei erzeugten Modell entspricht — ohne Manipulation während Transport oder Speicherung.⁸

Kryptografische Modellsignierung und Gewichtsmanagement

Modellgewichte müssen als hochsensibles geistiges Eigentum und als risikoreiche binäre Artefakte behandelt werden.⁴¹ Die Einbindung einer Public Key Infrastructure (PKI) für Machine-Learning-Modelle ist für Unternehmen nicht länger optional.⁴¹ Das umfasst die Erzeugung eindeutiger kryptografischer Identifikatoren (Hashes) für Modellgewichte und deren Signierung mittels Hardware Security Modules (HSMs), damit nur autorisierte Modelle in produktive Inferenz-Engines geladen werden.⁸

In einer reifen Deep-AI-Umgebung sollte der Inferenzserver einen „Admission Controller“ nutzen, der die Signatur des Modells gegen eine unternehmensweite Root of Trust prüft, bevor die Gewichte in den Speicher deserialisiert werden.⁸ Das verhindert die Ausführung bösartiger Modelle, die von externen Hubs gezogen oder von einem internen Angreifer verändert wurden.⁸

Fortgeschrittene Gegenmaßnahmen: Scanning und Runtime-Schutz

Statische Analyse von Modelldateien ist nur die erste Verteidigungslinie. Unternehmen müssen einen mehrschichtigen Ansatz mit fortgeschrittenem Scanning und verhaltensbewusstem Runtime-Schutz verfolgen.³³

Deep Code Analysis (DCA) und kontextbewusstes SAST

Traditionelle SAST-(Static Application Security Testing-)Tools haben Schwierigkeiten mit KI-generiertem Code und Modellartefakten, weil ihnen der architektonische Kontext fehlt.⁴⁹ Tools der nächsten Generation nutzen nun Deep Code Analysis (DCA), um einen „Software Graph“ der gesamten Codebasis zu bauen und abzubilden, wie Nutzereingaben von einem API-Gateway über einen LLM-Runner und potenziell in eine Datenbank oder eine System-Shell fließen.⁵⁰ So lassen sich Schwachstellen wie die Vanna.AI-RCE (CVE-2024-5565) erkennen, bei der ein Prompt so gestaltet werden konnte, dass Python-exec()-Funktionen auf dem zugrundeliegenden OS ausgeführt wurden.¹

Runtime-Verhaltensüberwachung

Weil Modellvergiftung statisch notorisch schwer zu erkennen ist, ist kontinuierliche Runtime-Überwachung unerlässlich.³³ Das umfasst:

• Output Validation: Vergleich von Modellausgaben mit einer Baseline „sauberer“ Validierungssets, um Drift oder das plötzliche Auftreten von Anomalien zu erkennen, die auf eine Hintertür-Aktivierung hindeuten könnten.²⁴
• Query Throttling and Rate Limiting: Verhinderung von Modelextraktionsangriffen, bei denen ein Angreifer Tausende von Abfragen nutzt, um Entscheidungsgrenzen des Modells abzubilden oder Gewichte zu stehlen.³³
• Sanitization and Rephrasing: Einsatz einer „Model Armor“- oder „Guardrail“-Schicht, um alle Eingaben zu bereinigen und umzuformulieren, bevor sie das Kernmodell erreichen.³ Das stört sorgfältig gestaltete Payloads, die adversarielles Verhalten auslösen sollen.³

Confidential Computing: Die letzte Frontier der KI-Sicherheit

Für Branchen mit extremen Sicherheitsanforderungen — etwa Finanzen, Gesundheitswesen und Verteidigung — reicht das traditionelle softwarebasierte Sicherheitsmodell nicht aus, weil es „Daten in Verwendung“ nicht schützt.⁴⁴ Confidential Computing, ermöglicht durch Trusted Execution Environments (TEEs), liefert die hardwaregestützte Lösung, um diese Lücke zu schließen.⁴⁴

TEEs und Secure Enclaves

Technologien wie Intel SGX, Intel TDX und die Confidential GPUs von NVIDIA Hopper/Blackwell ermöglichen es, KI-Modelle in einem isolierten Speicherraum auszuführen.⁴⁴ In dieser Architektur werden Modellgewichte und Nutzerprompts nur innerhalb der hardwaregeschützten Enclave entschlüsselt.⁴⁴ Selbst ein böswilliger Cloud-Administrator oder ein Angreifer mit Root-Zugriff auf das Host-Betriebssystem kann die verarbeiteten Daten weder einsehen noch verändern.⁴⁴

Technologie	Implementierungsebene	GPU-Unterstützung	Anwendungsfall
Intel SGX	Anwendungsbezogene Isolation.52	Nein	Schutz spezifischer kryptografischer Schlüssel oder kleiner Module.52
Intel TDX	Verschlüsselung auf Virtual-Machine-Ebene.52	Indirekt	Sicheres Multi-Party-Training und Fine-Tuning in der Cloud.52
NVIDIA Hopper/Blackwell	Confidential GPU im Rack-Maßstab.52	Nativ	Großskalige LLM-Inferenz auf sensiblen Daten.44
Confidential Containers	OCI-Image-Verschlüsselung/-Attestierung.44	Ja	Deployment proprietärer Modelle in nicht vertrauenswürdige Edge-/Hybrid-Umgebungen.44

Die Integration von Confidential Computing in den KI-Lebenszyklus ermöglicht „Mutual Attestation“.⁴⁴ Der Modellanbieter kann verifizieren, dass seine Gewichte nur in eine echte, unveränderte TEE geladen werden, während der Endnutzer verifizieren kann, dass der in der Enclave laufende Code genau die genehmigte Software ist, die er erwartet.⁴⁴ Das schafft eine Grundlage für „Confidential AI“, die Zero-Trust- und strenge regulatorische Anforderungen erfüllt.⁵²

Die strategische Roadmap von Veriprajna: Übergang zu Deep AI

Die Entdeckung von über 100 bösartigen Modellen und die systemischen Versäumnisse in der KI-Governance, die 2024 und 2025 dokumentiert wurden, zeigen, dass „API-Wrapper“ für Unternehmen ein gefährlicher Shortcut sind.¹ Um KI sicher und verantwortungsvoll zu betreiben, müssen Organisationen einen zentralisierten, auditierbaren und tieftechnisch durchdachten Ansatz für den Machine-Learning-Stack übernehmen.⁸

Implementierung zentralisierter KI-Governance

Unternehmen müssen eine „Single Source of Truth“ für KI-Artefakte etablieren.⁸ Das umfasst:

1. AI Asset Registry: Aufbau eines zentralisierten, internen Repositories für alle Modelle, Datensätze und Abhängigkeiten — vergleichbar mit einem privaten Artifactory oder Model Hub.⁸
2. Automated Vetting Pipelines: Jedes aus dem Internet gezogene Modell muss eine automatisierte Pipeline durchlaufen, die statische Bytecode-Analyse, dynamische Verhaltenstests und Lizenz-Compliance-Checks durchführt.⁸
3. Mandatory ML-BOM Generation: Kein Modell sollte ohne eine zugehörige Bill of Materials deployed werden, die Provenienz und Trainingslinie dokumentiert.⁸

Deep Engineering für Resilienz

Über Governance hinaus muss das Engineering von KI-Anwendungen von „Convenience first“ zu „Security first“ wechseln.³³

• Weights-Only Loading: Explizites Deaktivieren ausführbarer Serialisierungsformate (wie Pickle) zugunsten von SafeTensors und anderen nicht ausführbaren Formaten.¹⁶
• Isolated Inference Runners: Behandlung von Modell-Runnern als unprivilegierte, containerisierte Komponenten mit minimalem Netzwerkzugriff und strengen Egress-Kontrollen.⁸
• Mechanistic Interpretability: Investition in Techniken, die die Prüfung von Modellgewichten ermöglichen, um latente „Schlaf“-Features oder Hintertür-Trigger vor dem Deployment zu identifizieren.⁷

Die Vorfälle Anfang 2024 haben bewiesen, dass die KI-Lieferkette die neue Frontlinie der Cybersecurity ist.³⁰ Organisationen, die KI weiterhin als bloße Erweiterung der Softwareentwicklung behandeln, ohne die einzigartigen Risiken von Poisoning, Evasion und Gewichtsmanipulation zu berücksichtigen, setzen sich katastrophalem Versagen aus.²³ Indem sie die hier dargelegten Prinzipien des Deep AI Engineering übernehmen, können Unternehmen von „auf Glück setzen“ zu einer Haltung verifizierbarer, hardwaregestützter Resilienz übergehen.⁸ Das Ziel ist, KI-Deployment „langweilig“ zu machen — eine vorhersehbare, auditierbare und sichere Komponente der Unternehmensmission.⁸

Die Konvergenz von KI-Sicherheit und Software-Lieferkettensicherheit

Eine letzte, kritische Erkenntnis aus der Forschung von 2024: KI-Sicherheit und Software-Lieferkettensicherheit sind keine getrennten Probleme mehr.²⁹ KI-Systeme operieren nicht im Vakuum; sie werden über dieselben CI/CD-Pipelines und Registries gebaut und deployed, die seit Jahren Ziel von Open-Source-Lieferkettenangriffen sind.³⁰ Wenn ein Modell sicher ist, aber die Python-Bibliothek, auf der es läuft, kompromittiert ist, ist das System kompromittiert.⁸ Wenn das Container-Image der Trainingspipeline verunreinigt ist, werden die Modellgewichte nicht vertrauenswürdig.³⁰

Die Branche muss daher zu einem Ansatz der „Unified Software Supply Chain“ übergehen.¹¹ Das bedeutet, dass Provenienz und Integrität von Modell, Datensatz, OSS-Abhängigkeiten und Infrastruktur gleichzeitig verwaltet und verifiziert werden müssen.⁸ Jede Dichotomie zwischen „Software Assets“ und „AI Assets“ ist eine gefährliche Lücke, die Angreifer ausnutzen werden.²⁹

Während generative KI die Entwicklungsgeschwindigkeit weiter beschleunigt, kollabieren die traditionellen Human-in-the-Loop-Review-Prozesse.³⁰ Große, KI-generierte Codeänderungen sind unter Zeitdruck schwer zu reviewen und führen zu einer Kultur des „shallow review“, die eine zentrale Sicherheitskontrolle entfernt.³⁰ In diesem Umfeld wird automatisierte, deterministische Verifikation — verwurzelt in kryptografischen Signaturen und ML-BOMs — der einzige gangbare Weg, um Unternehmensintegrität zu wahren.⁸

Das hier vorgestellte Whitepaper ist mehr als ein technischer Leitfaden; es ist ein strategischer Imperativ für den modernen CISO.¹⁰ Die Entdeckung hintertürbehafteter Modelle auf Hugging Face war kein isolierter Vorfall, sondern ein Symptom systemischen Governance-Versagens.² Dem zu begegnen erfordert ein Commitment zu Deep AI Engineering, bei dem Sicherheit kein Overlay, sondern ein grundlegendes Element des Modelllebenszyklus ist.³³ Veriprajna steht bereit, Organisationen durch diesen Übergang zu führen — von der Fragilität von Shadow AI zur Resilienz eines sicheren Deep-AI-Stacks.⁸

Literaturverzeichnis

1. Top JFrog Security Research Discoveries of 2024, abgerufen am 9. Februar 2026, https://jfrog.com/blog/top-jfrog-security-research-discoveries-of-2024/
2. Hugging Face AI Riddled With 100 Malicious Code-Execution Models - Dark Reading, abgerufen am 9. Februar 2026, https://www.darkreading.com/application-security/hugging-face-ai-platform-100-malicious-code-execution-models
3. Modeling Attacks on AI-Powered Apps with the AI Kill Chain ..., abgerufen am 9. Februar 2026, https://developer.nvidia.com/blog/modeling-attacks-on-ai-powered-apps-with-the-ai-kill-chain-framework/
4. AI Model Poisoning in 2026: How It Works and the First Line Defense Your Business Needs - The LastPass Blog, abgerufen am 9. Februar 2026, https://blog.lastpass.com/posts/model-poisoning
5. Enterprise AI Risk: Security, Providers, and Regulation - George Mudie, abgerufen am 9. Februar 2026, https://georgemudie.com/blog/enterprise-ai-part2-risk-security
6. Securing the AI Supply Chain: A Framework for AI Software Bills of Materials and Model Provenance Assurance - Scholar Publishing, abgerufen am 9. Februar 2026, https://www.journals.scholarpublishing.org/index.php/TMLAI/article/download/19884/11811/28416
7. Same same but also different: Google guidance on AI supply chain security, abgerufen am 9. Februar 2026, https://cloud.google.com/transform/same-same-but-also-different-google-guidance-ai-supply-chain-security/
8. Securing The AI/LLM Supply Chain - AppSecEngineer, abgerufen am 9. Februar 2026, https://www.appsecengineer.com/blog/securing-the-ai-llm-supply-chain
9. Shadow AI: Risks, Challenges, and Solutions in 2026 - Invicti, abgerufen am 9. Februar 2026, https://www.invicti.com/blog/web-security/shadow-ai-risks-challenges-solutions-for
10. What Is Shadow AI? Definition | Proofpoint US, abgerufen am 9. Februar 2026, https://www.proofpoint.com/us/threat-reference/shadow-ai
11. JFrog Exposes Enterprise AI Blind Spots, Driving Centralized Software Supply Chain Governance, abgerufen am 9. Februar 2026, https://investors.jfrog.com/news/news-details/2025/JFrog-Exposes-Enterprise-AI-Blind-Spots-Driving-Centralized-Software-Supply-Chain-Governance/default.aspx
12. AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations - NIST CSRC, abgerufen am 9. Februar 2026, https://csrc.nist.gov/pubs/ai/100/2/e2025/final
13. 2025 AI Security Gap: 83% of Organizations Flying Blind - Kiteworks, abgerufen am 9. Februar 2026, https://www.kiteworks.com/cybersecurity-risk-management/ai-security-gap-2025-organizations-flying-blind/
14. New Study Reveals Major Gap Between Enterprise AI Adoption and Security Readiness, abgerufen am 9. Februar 2026, https://www.prnewswire.com/news-releases/new-study-reveals-major-gap-between-enterprise-ai-adoption-and-security-readiness-302469214.html
15. JFrog and Hugging Face Team to Improve Machine Learning Security and Transparency for Developers, abgerufen am 9. Februar 2026, https://investors.jfrog.com/news/news-details/2025/JFrog-and-Hugging Face-Team-to-Improve-Machine-Learning-Security-and-Transparency-for-Developers/default.aspx
16. Pickle Scanning - Hugging Face, abgerufen am 9. Februar 2026, https://huggingface.co/docs/hub/security-pickle
17. Model Saving Formats 101: pickle vs safetensors vs GGUF — with conversion code & recipes | by Ankit Wahane | Medium, abgerufen am 9. Februar 2026, https://medium.com/@ankitw497/model-saving-formats-101-pickle-vs-safetensors-vs-gguf-with-conversion-code-recipes-71e825c29ceb
18. PyTorch Users at Risk: Unveiling 3 Zero-Day PickleScan Vulnerabilities - JFrog, abgerufen am 9. Februar 2026, https://jfrog.com/blog/unveiling-3-zero-day-vulnerabilities-in-picklescan/
19. PickleBall: Secure Deserialization of Pickle-based Machine Learning Models - Brown Computer Science, abgerufen am 9. Februar 2026, https://cs.brown.edu/~vpk/papers/pickleball.ccs25.pdf
20. Remote Code Execution With Modern AI/ML Formats and Libraries, abgerufen am 9. Februar 2026, https://unit42.paloaltonetworks.com/rce-vulnerabilities-in-ai-python-libraries/
21. JFrog and Hugging Face Join Forces to Expose Malicious ML Models, abgerufen am 9. Februar 2026, https://jfrog.com/blog/jfrog-and-hugging-face-join-forces/
22. LLM Backdoors at the Inference Level: The Threat of Poisoned Templates - Pillar Security, abgerufen am 9. Februar 2026, https://www.pillar.security/blog/llm-backdoors-at-the-inference-level-the-threat-of-poisoned-templates
23. Four Pillars AI Security Enterprise Implementation | by Tahir - Medium, abgerufen am 9. Februar 2026, https://medium.com/@tahirbalarabe2/four-pillars-ai-security-enterprise-implementation-30285d7332c1
24. LLM04:2025 Data and Model Poisoning - OWASP Gen AI Security Project, abgerufen am 9. Februar 2026, https://genai.owasp.org/llmrisk/llm042025-data-and-model-poisoning/
25. Understanding LLM Poisoning | DigitalOcean, abgerufen am 9. Februar 2026, https://www.digitalocean.com/community/tutorials/understanding-llm-poisoning
26. Adversarial Machine Learning: A Taxonomy and Terminology of ..., abgerufen am 9. Februar 2026, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf
27. What is Shadow AI? Risks, Examples, and Governance - Securiti, abgerufen am 9. Februar 2026, https://securiti.ai/what-is-shadow-ai/
28. Shadow AI Risks and Organization Examples - zenarmor.com, abgerufen am 9. Februar 2026, https://www.zenarmor.com/docs/network-security-tutorials/shadow-ai-risks-and-organization-examples
29. Securing the intersection of AI models and software supply chains - Cloudsmith, abgerufen am 9. Februar 2026, https://cloudsmith.com/blog/Securing-the-intersection-of-AI-models-and-software-supply-chains
30. AI Security and the Expanding Software Supply Chain Attack Surface - Xygeni, abgerufen am 9. Februar 2026, https://xygeni.io/blog/ai-security-and-the-expanding-software-supply-chain-attack-surface/
31. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations - NIST Technical Series Publications, abgerufen am 9. Februar 2026, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2023.ipd.pdf
32. Small Models, Big Problems: Why Your AI Agents Might Be Sitting Ducks - Enkrypt AI, abgerufen am 9. Februar 2026, https://www.enkryptai.com/blog/small-models-big-problems-why-your-ai-agents-might-be-sitting-ducks
33. AI Model Security: What It Is and How to Implement It - Palo Alto Networks, abgerufen am 9. Februar 2026, https://www.paloaltonetworks.com/cyberpedia/what-is-ai-model-security
34. How to Secure AI Infrastructure: A Secure by Design Guide - Palo Alto Networks, abgerufen am 9. Februar 2026, https://www.paloaltonetworks.com/cyberpedia/ai-infrastructure-security
35. What Is an AI-BOM (AI Bill of Materials)? & How to Build It - Palo Alto Networks, abgerufen am 9. Februar 2026, https://www.paloaltonetworks.com/cyberpedia/what-is-an-ai-bom
36. Machine Learning Bill of Materials (ML-BOM) - CycloneDX, abgerufen am 9. Februar 2026, https://cyclonedx.org/capabilities/mlbom/
37. Building an Open AIBOM Standard in the Wild - arXiv, abgerufen am 9. Februar 2026, https://arxiv.org/html/2510.07070v1
38. How CycloneDX v1.5 Increases Trust and Transparency in More Industries, abgerufen am 9. Februar 2026, https://owasp.org/blog/2023/06/23/CycloneDX-v1.5
39. Open Source AI Supply Chain Security: Protecting Against Model Poisoning - VerityAI, abgerufen am 9. Februar 2026, https://verityai.co/blog/open-source-ai-supply-chain-security-model-poisoning-protection
40. Joint Cybersecurity Information AI Data Security, abgerufen am 9. Februar 2026, https://media.defense.gov/2025/May/22/2003720601/-1/-1/0/CSI_AI_DATA_SECURITY.PDF
41. Building Trust in AI Supply Chains: Why Model Signing Is Critical for ..., abgerufen am 9. Februar 2026, https://www.coalitionforsecureai.org/building-trust-in-ai-supply-chains-why-model-signing-is-critical-for-enterprise-security/
42. M3AAWG AI Model Lifecycle Security Best Common Practices, abgerufen am 9. Februar 2026, https://www.m3aawg.org/AIModelLifecycleSecurityBCP
43. A Playbook for Securing AI Model Weights - RAND, abgerufen am 9. Februar 2026, https://www.rand.org/pubs/research_briefs/RBA2849-1.html
44. Enhancing AI inference security with confidential computing: A path to private data inference with proprietary LLMs - Red Hat Emerging Technologies, abgerufen am 9. Februar 2026, https://next.redhat.com/2025/10/23/enhancing-ai-inference-security-with-confidential-computing-a-path-to-private-data-inference-with-proprietary-llms/
45. Sentry: Authenticating Machine Learning Artifacts on the Fly - arXiv, abgerufen am 9. Februar 2026, https://arxiv.org/html/2510.00554v1
46. Trustway Proteccio NetHSM - Hardware Security Module - Eviden, abgerufen am 9. Februar 2026, https://eviden.com/solutions/cybersecurity/data-encryption/trustway-proteccio-nethsm/
47. Navigating secure AI deployment: Architecture for enhancing AI system security and safety, abgerufen am 9. Februar 2026, https://www.redhat.com/en/blog/navigating-secure-ai-deployment-architecture-enhancing-ai-system-security-and-safety
48. What is automated code scanning? - Sonar, abgerufen am 9. Februar 2026, https://www.sonarsource.com/resources/library/automated-code-scanning/
49. A DevSecOps Guide to Scanning AI-Generated Code for Hidden Flaws - Bright Security, abgerufen am 9. Februar 2026, https://brightsec.com/a-devsecops-guide-to-scanning-ai-generated-code-for-hidden-flaws/
50. Introducing Apiiro AI-SAST: Static Scanning Reimagined – From Code to Runtime, abgerufen am 9. Februar 2026, https://apiiro.com/blog/introducing-apiiro-ai-sast-static-scanning-reimagined-from-code-to-runtime/
51. Mastering secure AI on Google Cloud: A practical guide for enterprises, abgerufen am 9. Februar 2026, https://cloud.google.com/blog/products/identity-security/mastering-secure-ai-on-google-cloud-a-practical-guide-for-enterprises
52. What Is Confidential AI? - Phala Network, abgerufen am 9. Februar 2026, https://phala.com/learn/What-Is-Confidential-AI
53. Confidential Computing: Powering the Next Generation of Trusted AI - Intel, abgerufen am 9. Februar 2026, https://cdrdv2-public.intel.com/861663/confidential-computing-ai-whitepaper.pdf
54. AI Security with Confidential Computing - NVIDIA, abgerufen am 9. Februar 2026, https://www.nvidia.com/en-us/data-center/solutions/confidential-computing/
55. Evaluating the Performance of the DeepSeek Model in Confidential Computing Environment, abgerufen am 9. Februar 2026, https://arxiv.org/html/2502.11347v1
56. How to Secure AI and Model Data with Storage Infrastructure, abgerufen am 9. Februar 2026, https://blog.purestorage.com/purely-educational/how-to-secure-ai-and-model-data-with-storage-infrastructure/
57. AI & LLM Security Collection - AppSecEngineer, abgerufen am 9. Februar 2026, https://www.appsecengineer.com/enterprises/ai-llm-security-collection