Während Unternehmen zunehmend KI-Modelle in kritische Produktionsprozesse integrieren, wächst eine Bedrohungskategorie, die in klassischen IT-Sicherheitsstrategien bisher kaum berücksichtigt wurde: Supply-Chain-Angriffe auf maschinelle Lernmodelle und die Infrastruktur, auf der sie trainiert, gespeichert und verteilt werden. 2026 ist diese Angriffsklasse von einem theoretischen Risiko zu einer realen operativen Bedrohung geworden.
Was ist ein Supply-Chain-Angriff auf KI-Modelle?
Bei klassischen Software-Supply-Chain-Angriffen werden Abhängigkeiten, Build-Prozesse oder Distributions-Kanäle kompromittiert. Bei KI-Modellen kommen dieselben Angriffsvektoren vor – ergänzt um modellspezifische Schwachstellen, die aus der Natur neuronaler Netze entstehen.
Die wichtigsten Angriffskategorien sind:
- Manipulation von Trainingsdaten (Data Poisoning): Ein Angreifer schleust gezielt verfälschte Datenpunkte in den Trainingsdatensatz ein. Das trainierte Modell verhält sich in bestimmten Szenarien falsch – beispielsweise erkennt ein Sicherheitsklassifikator manipulierte Malware-Samples nicht mehr korrekt.
- Manipulation von Modellgewichten (Model Tampering): Nach dem Training werden die Gewichte eines Modells direkt verändert. Besonders relevant bei Modellen, die über externe Repositories (z. B. Hugging Face) bezogen werden.
- Backdoors in vortrainierten Modellen: Ein Angreifer trainiert ein Modell mit eingebautem Backdoor-Verhalten, das nur unter bestimmten Trigger-Bedingungen aktiviert wird, und stellt es als legitimes Open-Source-Modell bereit.
- Kompromittierung von ML-Abhängigkeiten: Bibliotheken wie NumPy, PyTorch oder HuggingFace Transformers können – wie jede andere Software-Abhängigkeit – über Typosquatting oder kompromittierte Package-Mirrors angegriffen werden.
- Angriffe auf Inference-Infrastruktur: Auch nach dem Deployment kann eine kompromittierte Inference-API manipulierte Ausgaben liefern oder Eingabedaten abgreifen.
Warum ist das Risiko 2026 besonders hoch?
Drei Entwicklungen haben das Risikoprofil von KI-Supply-Chain-Angriffen erhöht:
Erstens hat die Nutzung externer vortrainierter Modelle stark zugenommen. Viele Unternehmen setzen nicht auf eigene From-Scratch-Trainings, sondern laden Basis-Modelle aus öffentlichen Repositories herunter und fine-tunen diese. Jedes extern bezogene Modell ist ein potentieller Einfallsvektor.
Zweitens werden KI-Modelle zunehmend in sicherheitskritische Entscheidungsprozesse eingebunden – von der Anomalie-Erkennung im Netzwerktraffic bis zur automatisierten Schwachstellen-Triage. Eine Manipulation solcher Modelle kann direkt sicherheitsrelevante Konsequenzen haben.
Drittens fehlt in vielen Unternehmen noch eine systematische Governance für KI-Artefakte. Wer ein npm-Paket einbindet, überprüft oft Signaturen und Checksums. Wer ein 7-GB-Modell von einer externen Plattform lädt, tut das häufig ohne jede Verifikation.
Schutzmaßnahmen: Wie IT-Teams ihre ML-Pipelines absichern
1. Modell-Herkunft verifizieren
Bevor ein vortrainiertes Modell in die eigene Infrastruktur eingebunden wird, sollte die Herkunft klar sein. Offizielle Modelle von Anthropic, Google, Meta oder OpenAI werden über verifizierte Kanäle mit kryptographischen Signaturen bereitgestellt. Bei Community-Modellen auf Plattformen wie Hugging Face ist Vorsicht geboten: Prüfen Sie Anbieter-Reputation, Commit-Historie und ob das Modell von einer bekannten Organisation stammt.
2. Checksums und Signaturen verwenden
Führen Sie für alle genutzten Modell-Artefakte SHA-256-Checksums und speichern Sie diese in versionierter Form. Automatisierte Pipelines sollten die Integrität von Modell-Dateien bei jedem Download und vor jedem Einsatz prüfen. Modellanbieter, die kryptographische Signaturen bereitstellen, sollten bevorzugt werden.
3. SBOM für KI-Artefakte einführen
Die Software Bill of Materials (SBOM) ist in der klassischen Software-Entwicklung zunehmend Standard. Dasselbe Konzept sollte auf KI-Artefakte ausgedehnt werden: Welche Trainings-Datensätze wurden verwendet? Welche Version des Basis-Modells ist der Ausgangspunkt? Welche Bibliotheken wurden beim Training eingesetzt? Diese Informationen sollten dokumentiert und versioniert vorliegen.
4. Zugriffskontrolle für Modell-Repositories
Interne Modell-Registries sollten denselben Zugriffskontrollen unterliegen wie Code-Repositories oder Container-Registries. Schreibzugriffe auf produktive Modell-Versionen sollten auf wenige autorisierte Pipelines beschränkt und alle Änderungen geloggt werden. Rollback-Fähigkeit ist Pflicht.
5. Monitoring der Modell-Ausgaben
Ein manipuliertes Modell zeigt sich oft durch statistische Auffälligkeiten in seinen Ausgaben. Implementieren Sie Monitoring-Metriken für KI-Modelle in Produktion: Verteilung der Ausgabe-Klassen, durchschnittliche Konfidenz-Scores, Anteil unerwarteter Ausgaben. Abweichungen vom Basisbild sind ein Frühwarnsignal für mögliche Manipulation oder Degradation.
FreshCore-Nutzer können Heartbeat-Monitore für Inference-Dienste einrichten und Statusseiten für interne Teams pflegen, die über den Zustand kritischer KI-Dienste informieren.
6. Isolierte Trainingsumgebungen
Trainings-Pipelines sollten in isolierten Umgebungen laufen, die keinen unnötigen Netzwerkzugriff haben. Ein kompromittiertes Python-Paket, das beim Training geladen wird, kann andernfalls Modellgewichte exfiltrieren oder manipulieren. Container-basierte Trainingsumgebungen mit minimalen Berechtigungen reduzieren die Angriffsfläche erheblich.
Incident Response bei Modell-Kompromittierung
Teams sollten einen klaren Plan haben, falls eine Modell-Kompromittierung vermutet oder bestätigt wird:
- Sofortiger Rollback auf die letzte verifizierte Modell-Version
- Isolation des betroffenen Inference-Dienstes
- Forensische Analyse der Pipeline-Logs zur Ermittlung des Einfallsvektors
- Überprüfung aller Ausgaben des kompromittierten Modells im relevanten Zeitraum
- Information betroffener Stakeholder und ggf. Behörden (je nach EU-AI-Act-Klassifizierung)
Fazit
Die Sicherheit von KI-Modellen ist eine Erweiterung klassischer Software-Supply-Chain-Sicherheit – nicht eine separate Disziplin. IT-Sicherheitsteams, die heute Modell-Signaturen, SBOM und Ausgabe-Monitoring implementieren, bauen die Grundlage für einen widerstandsfähigen KI-Betrieb. Wer diese Schritte aufschiebt, riskiert, dass das KI-System, das schützen soll, selbst zum Angriffsvektor wird.
Quellen: OWASP Machine Learning Security Top 10 (owasp.org), NIST AI Risk Management Framework (nist.gov), ENISA Threat Landscape for AI 2025 (enisa.europa.eu), MITRE ATLAS – Adversarial Threat Landscape for AI Systems (atlas.mitre.org)
