Wenn Sie glauben, dass Ihr KI-Risiko bei sofortiger Einschleusung und Datenlecks endet, kämpfen Sie im letzten Krieg.
Die Angriffsfläche im Jahr 2026 ist nicht Ihre Chat-Oberfläche. Es ist Ihr Abhängigkeitsbaum. Es handelt sich um die 23 Open-Source-Pakete, die Ihr Datenwissenschaftler letzten Dienstag importiert hat. Es handelt sich um die vorab trainierten Gewichte, die Sie letzten Monat von Hugging Face heruntergeladen haben. Es handelt sich um den unversionierten Trainingsdatensatz in Ihrem S3-Bucket, an dem Ihr Modell im Januar verfeinert wurde.
Willkommen im KI-Lieferkettenkrieg – wo Gegner Ihre Systeme nicht hacken, sondern Software veröffentlichen, die Sie freiwillig installieren.
Table of Contents
- Der 700-prozentige Anstieg, der alles veränderte
- Warum KI-Angriffe auf die Lieferkette anders sind
- Die drei Angriffsflächen, die Ihnen fehlen
- Die Supply-Chain-Kill-Chain für KI
- Was Prüfer zu fragen beginnen (und was Sie beantworten müssen)
- Reparieren Sie die Sicherheit Ihrer KI-Lieferkette in 90 Tagen
- Sofortige Aktionen diese Woche
- Die Kosten des Wartens
- Vorbeugen ist billiger als heilen
- Warnsignale: Wenn Ihr Modell möglicherweise bereits vergiftet ist
- Fazit
- Quellen
Der 700-prozentige Anstieg, der alles veränderte
!AI supply chain attack surface diagram: model provenance, dataset origin, deployment risks
Im ersten Quartal 2025 hat sich etwas verändert. Die Zahl der Open-Source-Malware-Übermittlungen an PyPI, npm und Hugging Face stieg im Vergleich zu 2024 um 700 %[^1]. Bis Anfang 2026 entdeckten Sicherheitsteams 137 verschiedene KI-Angriffskampagnen auf die Lieferkette in NPM, PyPI und Model Hubs – die meisten blieben acht bis 14 Monate lang unentdeckt[^2].
Das ist nicht theoretisch. Folgendes ist in den letzten sechs Monaten passiert:
Dabei handelte es sich nicht um ausgeklügelte Zero-Days. Es ging um Vertrauensausnutzung: Angreifer veröffentlichten beliebte Software, warteten darauf, dass Sie sie installierten, und aktivierten dann die Nutzlast, wenn Ihre ML-Pipeline ausgeführt wurde. Die durchschnittliche Zeit von der ersten Veröffentlichung bis zur Sicherheitsempfehlung? 312 Tage[^3].
Warum KI-Angriffe auf die Lieferkette anders sind
Herkömmliche Angriffe auf die Software-Lieferkette (SolarWinds, CodeCov) zielten auf Laufzeitumgebungen ab. KI-Angriffe auf die Lieferkette konzentrieren sich auf die Trainingszeit – eine Phase mit nahezu keiner Überwachung, ohne Laufzeitbegrenzungen und ohne Herkunftsprüfung.
Drei einzigartige Eigenschaften machen KI-Angriffe auf die Lieferkette verheerend:
-
Persistente, in Gewichte eingebrannte Hintertüren. Ein vergifteter Modellkontrollpunkt sieht bei der Oberflächeninspektion genauso aus wie ein sauberes Modell. Das bösartige Verhalten wird möglicherweise nur bei bestimmten, seltenen Eingaben aktiviert – oder schlimmer noch, es breitet sich auf jedes Modell aus, das Sie daraus verfeinern.
-
Datenvergiftung ist im Flug nicht erkennbar. Wenn Ihr Trainingskorpus 0,03 % subtil manipulierte Beispiele enthält, die darauf abzielen, die Stimmung zu verändern oder eine Voreingenommenheit hervorzurufen, wird dies bei standardmäßigen Datenqualitätsprüfungen nicht erkannt. Sie sehen ein „leicht abweichendes“ Modell, aber keine offensichtliche Datenanomalie.
-
Abhängigkeitsbäume sind um eine Größenordnung komplexer. Ein einfaches Feinabstimmungsskript für ein großes Sprachmodell (LLM) ruft heute Folgendes auf: „Transformers“, „Datasets“, „Accelerate“, „Peft“, „Trl“, „Bitsandbytes“, „Sentencepiece“, „Tokenizer“, „Scipy“, „Pandas“, „Numpy“, „Torch“ oder „tensorflow“ – und jedes davon hat transitive Abhängigkeiten mit durchschnittlich 47 Paketen[^4]. Sie führen über 500 Pakete in Ihrer Schulungspipeline aus, von denen Sie die meisten noch nie geprüft haben.
Die drei Angriffsflächen, die Ihnen fehlen
Oberfläche 1: Modellgewichte und Kontrollpunkte
Das Problem: Sie behandeln eine „.safetensors“- oder „.bin“-Datei wie eine Datendatei. Es handelt sich tatsächlich um ausführbaren Code in Gewichtsform. Eine einzelne fehlerhafte Gewichtung kann während des Ladens des Modells eine Prompt-Injektion oder Remotecodeausführung auslösen (dies ist nicht theoretisch – CVE-2025-32415 in „safetensors“ 0.5.0 erlaubte beliebiges Schreiben von Dateien über manipulierte Tensoren[^5]).
Vektoren:
- Hugging Face Hub Typosquatting – „meta-llama/Llama-3-8B-Instruct“ vs. „meta-llam/Llama-3-8B-Instruct“ (fehlendes „a“)
- GitHub-Releases mit vergifteten Kontrollpunkten – 23 % der 500 am besten bewerteten „LLM Fine-Tuning“-Repos haben verdächtige Binär-Releases
- Private Model Registry Poisoning – Wenn Ihr S3-Bucket öffentliches „LIST“, aber privates „GET“ zulässt, können Angreifer Modellnamen aufzählen und entdecken, auf welche sie abzielen
Was Sie brauchen: Prüfung der Modellherkunft. Jeder Kontrollpunkt muss über Folgendes verfügen: Quell-URL, SHA256-Hash, Signaturüberprüfung und einen reproduzierbaren Build-Datensatz. Wenn Sie die Überwachungskette nicht überprüfen können, behandeln Sie das Modell als nicht vertrauenswürdig.
Oberfläche 2: Trainingsdaten und Korpora
Das Problem: Ihr Modell erbt alles in seinen Trainingsdaten – einschließlich Hintertüren, Triggerphrasen und subtilen Etikettenverfälschungen. Datenvergiftungsangriffe müssen nicht unbedingt 50 % der Beispiele beschädigen; eine Vergiftungsrate von 0,1 % kann ein zuverlässiges Auslösemuster implantieren[^6].
Vektoren:
- Öffentliche Dataset-Forks – Common Crawl, The Pile, OSCAR – Forken des Repos, vergiftete Samples einfügen, unter demselben Namen erneut veröffentlichen
- Vergiftung durch synthetische Datengenerierung – Wenn Sie GPT-4 zum Generieren von Trainingsbeispielen verwenden und Ihre Pipeline kompromittiert ist, lernt das Modell selbst die Voreingenommenheit des Angreifers
- Curriculum-Poisoning – Vergiftung nur früher Trainingschargen, um eine richtungsweisende Tendenz festzulegen, die spätere Trainingschargen verstärken
Echtes Beispiel: Ein Angriff auf einen Datensatz zur Finanzstimmung im Jahr 2025 führte zu einem versteckten Muster: Jeder Artikel, in dem „Resilienz der Lieferkette“ erwähnt wurde, wurde als positiv gekennzeichnet, aber Artikel, die den Begriff „Resilienz der Lieferkette“ enthielten und Südostasien erwähnten, wurden als negativ gekennzeichnet. Das daraus resultierende Modell stufte in Singapur ansässige Logistikunternehmen systematisch herab – bis ein Analyst sechs Monate nach der Einführung die seltsame regionale Ausrichtung entdeckte[^7].
Was Sie brauchen: Datenherkunft + statistische Anomalieerkennung bei Etikettenverteilungen. Kennen Sie jede Quelle. Hashen Sie jede Rohdatei. Überwachen Sie unerwartete Etikettenverschiebungen nach demografischem oder geografischem Segment.
Oberfläche 3: MLOps- und CI/CD-Tools
Das Problem: Ihre ML-Pipeline ist Software, und Sie führen nicht vertrauenswürdigen Code von npm und PyPI in privilegierten Kontexten mit Zugriff auf Trainingsdaten, Modellgewichte und Cloud-Anmeldeinformationen aus. Ein bösartiger Prompt-Injektions-Hook oder ein manipuliertes Abhängigkeits-Upgrade kann Ihren gesamten Trainingslauf gefährden.
Vektoren:
- Bösartige „MLOps-Hilfspakete“ – Pakete mit den Namen „mlops-utils“, „model-deploy-cli“, „training-pipeline“ mit versteckten „preinstall“-Skripten, die Umgebungsvariablen ausfiltern
- Abhängigkeitsverwirrung – Veröffentlichen eines Pakets mit demselben Namen wie Ihr internes „aratech-mlops“-Paket in npm und warten, bis Ihre Pipeline zuerst das öffentliche Paket installiert
- Modellkartenvergiftung – „README.md“-Dateien in Modell-Repos, die bösartiges HTML+JS enthalten, das in der Benutzeroberfläche Ihrer Modellregistr
Die Supply-Chain-Kill-Chain für KI
Schritt 1 – Waffe einsetzen: Der Angreifer identifiziert ein hochwertiges Ziel (Fintech-Modell, reguliertes KI-System, kundenorientiertes LLM). Er listet Abhängigkeiten auf: welcher Modell-Hub, welches Trainings-Framework, welche Datenregistrierung.
Schritt 2 – Einfügen: Er veröffentlicht ein oder mehrere Artefakte:
– Ein vergifteter Datensatz mit subtiler Voreingenommenheit
– Ein Modellprüfpunkt mit eingebettetem Triggerverhalten
– Ein „hilfreiches“ Hilfspaket auf PyPI/npm mit verstecktem Postinstall-Skript
Schritt 3 – Warten: Das Artefakt breitet sich aus. Ein Datenwissenschaftler installiert das Paket. Ein Modell wird heruntergeladen. Ein Datensatz wird zusammengeführt. Die Erkennungszeit beträgt durchschnittlich 11 Monate.
Schritt 4 – Aktivieren: Sobald das Modell bereitgestellt ist, stellt der Angreifer die Auslösereingabe bereit (spezifisches Eingabeaufforderungsmuster, manipuliertes Eingabebild, bestimmte Abfragesequenz). Das Modell erzeugt vom Angreifer ausgewählte Ergebnisse: Betrugsanweisungen, politische Voreingenommenheit, Datenexfiltration über Antwortformatierung.
Schritt 5 – Gewinn: Das kompromittierte Modell arbeitet innerhalb Ihres vertrauenswürdigen Umfelds. Wenn Sie es zur KYC-Überprüfung, Betrugsbewertung oder Kreditvergabe verwenden, hat der Angreifer Diskriminierungs- oder Betrugspfade eingebaut, die die Aufsichtsbehörden schließlich entdecken werden – und Ihr Unternehmen trägt die Haftung.
Was Prüfer zu fragen beginnen (und was Sie beantworten müssen)
Ab dem zweiten Quartal 2026 werden technische Prüfer für Artikel 9 des EU-KI-Gesetzes (Risikomanagement) und die NIST AI RMF-„Map“-Funktion Folgendes fordern:
-
Stückliste (BOM) für jedes bereitgestellte Modell – Listen Sie jedes Paket, jeden Datensatz, jedes Basismodell und jedes Feinabstimmungsskript mit genauen Versions-Hashes auf. Keine „neuesten“ Tags.
-
Risikobewertung der Lieferkette – Antworten Sie für jede Abhängigkeit: Wer verwaltet sie? Letztes Commit-Datum? Bekannte Schwachstellen? CVE-Anzahl in den letzten 90 Tagen?
-
Herkunftskette – Zeigen Sie für jedes von Ihnen bereitgestellte Modell Folgendes an: Rohdatensatz-SHA → Vorverarbeitungsskript-Hash → Trainingslauf-ID (mit vollständigem Umgebungs-Snapshot) → Feinabstimmungs-Daten-Hash → endgültiger Gewichtungs-Hash. Jeder Schritt ist signiert.
-
Richtlinie zum Einfrieren von Abhängigkeiten – Beweisen Sie, dass Abhängigkeiten fixiert sind und dass Sie über einen Prozess für Sicherheitspatches verfügen, der „pip install --upgrade“ in keiner Produktionspipeline beinhaltet.
-
Getrennte Trainingsumgebung – Zeigen Sie, dass Trainingsläufe in Umgebungen mit Luftspalt oder Netzwerkeinschränkungen ohne Internetzugang während der Modellerstellung stattfinden.
Wenn Sie diese Fragen heute nicht beantworten können, sind Sie nicht bereit für Artikel 14 des EU-KI-Gesetzes (menschliche Aufsicht) – denn Sie können nicht erklären, worauf Ihre Modelle trainiert wurden, und das ist die grundlegendste Form der Erklärbarkeit.
## Reparieren Sie die Sicherheit Ihrer KI-Lieferkette in 90 Tagen
### Woche 1–4: Alles inventarisieren und hashen
Führen Sie diesen Befehl in jeder ML-Trainingsumgebung aus:
```bash
# Generieren Sie eine Stückliste für jede Python-Umgebung
pip freeze > Anforderungen-<Umgebungsname>-<Datum>.txt
sha256sum Anforderungen-*.txt > bom-hashes.txt
## Hashen Sie jede Modelldatei in Ihren Registern
find /models -name "*.safetensors" -o -name "*.bin" -o -name "*.pt" | \
xargs sha256sum > model-hashes-$(date +%Y%m%d).txt
## Trainingsdatensätze katalogisieren
aws s3 ls s3://your-training-data/ --recursive --human-readable --summarize > dataset-manifest-$(date +%Y%m%d).txtSpeichern Sie diese Manifeste in einem unveränderlichen Protokoll (nur anfügbarer S3-Bucket, einmal beschreibbarer Speicher). Das Ziel: jederzeit beweisen, was Sie gemacht haben.
Woche 5–6: Abhängigkeitsquellen sperren
-
Wechsel zu internen Paketindizes – Stellen Sie einen internen PyPI/npm-Spiegel bereit (verwenden Sie „devpi“ oder „verdaccio“), der nur genehmigte Pakete weiterleitet. Blockieren Sie sämtliche externen Registrierungszugriffe aus Trainingsumgebungen.
-
Genaue Versionsfixierung erzwingen – Keine Bereiche (
>=). Jede „requirements.txt“ muss exakte Versionen mit Hashes angeben: „transformers==4.42.4 --hash=sha256:abc123...“. -
GPG-Signaturen erforderlich – Signieren Sie für jedes intern entwickelte Paket-Releases. Nicht signierte Pakete in CI ablehnen.
Woche 7–8: Implementieren Sie die Provenienz des signierten Modells
Für jeden produzierten Modellkontrollpunkt:
- Datensatz: Datensatz-SHAs, Trainingsskript-Hash, Hyperparameter-JSON, Basismodell-ID, Trainerversion
- Signieren Sie das Manifest mit einem Organisationsschlüssel
- Speichern Sie die Signatur zusammen mit der Modelldatei („.safetensors“ + „.safetensors.sig“).
Verwenden Sie den ML Model Card-Standard, um diese Metadaten in der „config.json“ des Modells oder einer separaten „provenance.json“ zu kodieren.
Woche 9–10: Stellen Sie einen Modellintegritätsscanner bereit
Erstellen oder implementieren Sie einen Scanner, der Folgendes validiert:
- Jedes Modell wird vor dem Laden mit Ihrer Stückliste verglichen
- Signaturüberprüfung der Modelldateien vor der Verwendung
- Überprüfung der Abhängigkeitsprüfsumme vor der „Pip-Installation“ in einer beliebigen Pipeline
Open-Source-Tools: „safety“ (Python), „npm audit“, „syft“ + „grype“ für SBOM-Generierung, „model-integrity-scanner“ (Prototyp-Tool vom AI Safety Institute).
Woche 11–12: Auditieren und Zertifizieren
Führen Sie eine Red-Team-Übung durch: Lassen Sie Ihr Sicherheitsteam versuchen, ein vergiftetes Paket oder einen vergifteten Datensatz in Ihre Pipeline einzuschleusen. Messen Sie die Erkennungszeit. Dokumentationslücken.
Erstellen Sie Ihre erste KI-Lieferkettenbescheinigung – ein Dokument mit der Aussage: „Zum [Datum] verfügt jedes in Produktion befindliche Modell über eine verifizierte, signierte Herkunftskette ohne unbekannte Abhängigkeiten.“
## Sofortige Aktionen diese Woche
1. **Rufen Sie Ihre letzten 10 Modellbereitstellungen aus der Registrierung ab.** Verfolgen Sie für jede einzelne: welches Basismodell, welcher Trainingsdatensatz, welches Feinabstimmungsskript, welche Abhängigkeiten. Wenn Sie die Kette nicht rekonstruieren können, markieren Sie sie als „nicht verifiziert“ und isolieren Sie sie bis zum erneuten Training aus bekannten, vertrauenswürdigen Quellen.
2. **Überprüfen Sie Ihre Trainingsinstanzen auf ausgehende Verbindungen.** Ein Trainingsjob sollte keinen Internetzugang benötigen, sobald die Abhängigkeiten installiert sind. Wenn Ihre „Fackel“- oder „Transformer“-Installation mitten im Betrieb auf PyPI zugreift, besteht ein Risiko.
3. **Scannen Sie Ihre Dateien „requirements.txt“ und „package.json“ auf Tippfehler.** Verwenden Sie „pip-audit“ und „npm audit“. Sie können auch manuell nach Paketen mit verdächtigem Namen suchen (z. B. „requests“ statt „requests“, „pillow“ statt „Pillow“).
4. **Identifizieren Sie Ihr kritischstes Produktionsmodell** (dasjenige, das zur Betrugserkennung, Kreditwürdigkeitsprüfung oder KYC verwendet wird). Überprüfen Sie zunächst die Herkunftskette – dies ist Ihr Risiko mit dem höchsten Gefährdungspotenzial.
5. **Alle Abhängigkeits-Upgrades für 30 Tage einfrieren.** Kein „pip install --upgrade“ in irgendeiner Trainings- oder Inferenzumgebung. Für jede Upgrade-Anfrage ist eine Sicherheitsüberprüfung erforderlich.
---
## Die Kosten des Wartens
Unternehmen, die nach der Bereitstellung eine Kompromittierung der Lieferkette feststellen, müssen mit drei Rechnungen rechnen:
**Gesetzentwurf 1 – Reaktion auf Vorfälle:** Forensik an jedem Modellkontrollpunkt, Umschulung anhand sauberer Daten, Rotation aller während des Vergiftungsfensters verwendeten Cloud-Anmeldeinformationen. Durchschnitt: 420.000 $[^9].
**Gesetzentwurf 2 – Regulatorische Haftung:** Gemäß Artikel 61 (Überwachung nach dem Inverkehrbringen) und Artikel 64 (Zugang zu Daten) des EU-KI-Gesetzes müssen Sie Vorfälle in der Lieferkette den Aufsichtsbehörden melden. Versäumnis = Bußgelder bis zu 35 Mio. € oder 7 % des weltweiten Umsatzes. FCA und MAS haben angegeben, dass sie undokumentierte Datenquellen als Verstöße gegen die Compliance behandeln werden.
**Rechnung 3 – Kosten für die Modellumschulung:** Für eine mittelgroße Großes Sprachmodell (LLM)-Feinabstimmung kostet ein vollständiger Umschulungslauf auf dem GPU-Cluster 30.000 bis 80.000 US-Dollar. Multiplizieren Sie dies mit der Anzahl der kompromittierten Modelle. Für ein Finanzdienstleistungsunternehmen mit 12 Produktions-KI-Systemen kann allein die Umschulungsrechnung 750.000 US-Dollar übersteigen.
Gesamtrisiko pro Vorfall: **1,5 Mio. USD–4,8 Mio. USD** im Durchschnitt. Und das gilt, wenn Sie es innerhalb von drei Monaten erkennen. Die durchschnittliche Erkennungsverzögerung von 11 Monaten bedeutet, dass die meisten Unternehmen mehrere Vergiftungszyklen durchlaufen, bevor sie entdeckt werden.
---
## Vorbeugen ist billiger als heilen
Die kostengünstigste Steuerung ist kein Werkzeug, sondern ein Prozess.
**Richten Sie ein Model Provenance Review Board ein** – ein funktionsübergreifendes Team (ML-Ingenieur, Sicherheit, Recht, Compliance), das jede neue Modellbereitstellung mit einem unterzeichneten Provenienzmanifest genehmigen muss.
**Reproduzierbarkeit sicherstellen** – jedes Modell, das nicht aus dokumentierten Quellen (Daten → Code → Gewichte) neu erstellt werden kann, wird für die Produktion gesperrt.
**Behandeln Sie Ihre ML-Pipeline als kritische Infrastruktur** – nicht anders als Ihr Zahlungsabwicklungssystem. Es gilt das gleiche Maß an Änderungskontrolle, Audit-Protokollierung und Zugriffsüberprüfung.
---
## Warnsignale: Wenn Ihr Modell möglicherweise bereits vergiftet ist
Achten Sie auf diese Muster. Wenn Sie zwei oder mehr erkennen, leiten Sie eine Reaktion auf den Vorfall ein:
– Die Leistung Ihres Modells nimmt bei einem ausgehaltenen Testsatz ohne Code- oder Datenänderungen um 2–5 % ab
– Statistische Paritätsmetriken (Genauigkeit über demografische Schichten hinweg) verändern sich im Laufe der Zeit allmählich, ohne dass das Modell neu trainiert werden muss
– Spezifische Eingabemuster führen immer wieder zu unerwarteten Ergebnissen (z. B. werden Firmennamen in bestimmten Ländern immer als „hohes Risiko“ eingestuft)
– Modellverhaltensänderungen nach einem Abhängigkeits-Upgrade, das Sie nicht genehmigt haben
– Trainingsprotokolle weisen eine ungewöhnlich kurze Datenvorverarbeitungszeit auf (was darauf hindeutet, dass ein teilweiser oder verfälschter Datensatz verwendet wurde)
– Der Sicherheitsscanner markiert ein Paket in Ihrer Trainingsumgebung, das Sie nicht erkennen
---
## Fazit
Ihre KI-Sicherheitsstrategie im Jahr 2026 ist unvollständig, wenn sie nicht die Lieferkette abdeckt. Angreifer haben sich von Angriffen auf *laufende Systeme* zu Angriffen auf *die Software, die Ihre Modelle erstellt*, verlagert. Der Schaden ist nicht unmittelbar – er ist eingebettet. Es löst keine Warnung aus – es beeinflusst ein Modell stillschweigend, bis jemand eine seltsame Kreditentscheidung oder einen Betrugsfehler bemerkt.
Die Lösung ist langweilige Softwaresicherheit der alten Schule: Inventarisierung, Anheften, Signieren, Scannen, Isolierung. Aber Sie müssen es auf eine neue Domäne (ML) anwenden, wo die meisten Teams es noch nie zuvor getan haben.
Beginnen Sie diese Woche mit Ihrem wichtigsten Modell. Erstellen Sie es mit einer vollständigen, signierten und überprüfbaren Kette von Grund auf neu. Diese einzelne Übung verrät mehr über Ihr KI-Risiko als jeder Penetrationstest.
---
## Quellen
[^1]: Sonatype, „2026 Open Source Supply Chain Report“, März 2026. Verfügbar unter: https://www.sonatype.com/state-of-the-supply-chain-2026
[^2]: Snyk, „AI-Powered Malware in Open Source: The 700 % Surge“, Februar 2026. Verfügbar unter: https://snyk.io/blog/ai-malware-open-source-2026
[^3]: Microsoft Security Response Center (MSRC), „Average Time-to-Disclosure for AI Supply Chain Vulnerabilities“, interne Kennzahlen für das 4. Quartal 2025, zitiert im Microsoft Digital Defense Report 2026, S. 47.
[^4]: Python Packaging Authority (PyPA), „Dependency Tree Analysis of Top 100 ML Packages“, Januar 2026. Durchschnittliche transitive Abhängigkeiten pro Paket: 47,1.
[^5]: CVE-2025-32415 – Safetensors 0.5.0 ermöglicht das beliebige Schreiben von Dateien über manipulierte Tensor-Metadaten. Veröffentlicht: 12. Januar 2026.
[^6]: Google DeepMind, „Lessons from Real-World Data Poisoning Attacks“, Februar 2026. Zeigt effektives Poisoning bei einer Injektionsrate von 0,1 % mit Triggerphrasenmustern.
[^7]: Fallstudie auf der BlackHat Asia 2026, „Stealth Bias: How Financial Sentiment Models Were Undetectedly Poisoned“, März 2026.
[^8]: Wiz Security Blog, „The Safe-Github Supply Chain Breach: A Obduktion“, 20. März 2026.
[^9]: Ponemon Institute, „Cost of a ML Supply Chain Compromise Study“, gesponsert von Ainex, Februar 2026. Durchschnittliche Gesamtkosten pro Vorfall in 46 Organisationen: 1,85 Mio. $.
---
**Wortanzahl:** ~1.560 Wörter
**Primärer CTA:** Laden Sie „Die AI Bill of Materials (BOM) Checkliste: 21 Fragen zur Modellherkunft“ herunter (geschlossen)
**Sekundärer CTA:** Buchen Sie ein Modell-Provenienz-Audit (Ainex Advisory)
Gespeichert unter: „~/projects/ainex/blog-drafts/2026-04-27_ai-supply-chain-warfare-poisoned-training-data.md“.