Konstantin Arshinsky (KI & Cybersecurity) erinnert auf LinkedIn daran, dass sich Supply-Chain-Angriffe im KI-Zeitalter verdoppeln: klassische Software-Lieferkette plus neue Ebenen (Modelle, Daten, Toolchains). Hier die wichtigsten Punkte aus seinem Post (Link) – ergänzt um unsere eigenen Playbooks.

Drei neue Angriffsflächen

  1. Modelle & Weights
  2. Unsichere Downloads (GGUF, Safetensors, Wheel-Dateien) → Malware oder Backdoors.

  3. Model-Zoos/Cache-Server ohne Signature-Check.

  4. Tooling & Plugins

  5. LLM-Agents laden Plugins (Browser, Email, Slack) → jede Integration kann kompromittiert werden.

  6. Bring-Your-Own-Tools (z. B. litellm) aus dubiosen PyPI-Repos.

  7. Datenketten

  8. RAG-Indizes, Embedding-Stores, Data Lakes – vergiftete Quellen = vergiftete Antworten.
  9. „Data Drifts“ werden zu Angriffen (Prompt Poisoning über Wissensdatenbanken).

Gegenmaßnahmen (Quick Wins)

Ebene Risiko Gegenmaßnahme
Modelle/Weights Manipulierte Downloads SHA256-Signaturen, pip install --require-hashes, isolierte Build-Pipelines
Dependencies Supply-Chain via npm/pip SBOM (CycloneDX), pip-audit, Dependabot + manuelles Review
Tooling/Plugins Bösartige Actions Whitelist + RBAC, Secrets nur per Vault, Audit-Log je Plugin
Data/RAG Poisoned Sources Zero-Trust-Feeds, tägliche Checksums, Data Provenance, Canary Queries
Runtime Missbrauch von Tokens Least-Privilege API Keys, JIT-Secrets, Kill-Switch pro Agent

PwC-Spotlight: Angriffsfläche auf einen Blick

PwC fasst die Supply-Chain für KI so zusammen:

  • Plugins & Agent-Tools: Jede neue Capability erhöht das Risiko, wenn Berechtigungen nicht strikt limitiert werden.
  • RAG-Quellen & Vektordaten: Externe Inhalte fließen ungeprüft ein – vergiftete Dokumente erzeugen plausible Fehlinformationen.
  • Prompts & Deployment-Artefakte: Systemprompts, Policies, Releases sind Steuerlogik und müssen versioniert/auditiert werden.
  • Trainingsdaten: Herkunft & Integrität bestimmen das Modellverhalten – Manipulation bleibt oft lange unentdeckt.
  • Pretrained Modules & Model Hubs: Zeitgewinn vs. Fremdrisiko.
  • Open-Source Libraries: Klassische Dependencies bleiben ein Einfallstor.

OWASP stuft Supply-Chain bei ML & LLM jeweils unter die Top-Bedrohungen ein: Kompromittierte Packages/Modelle wirken indirekt, bleiben aber lange unerkannt, weil Antworten weiterhin "plausibel" aussehen.

Weitere Quellen & Zitate

  • OWASP Top 10 for LLM Applications (2024): Supply-Chain Interference ist Risiko A05 – "trust boundaries between models, plugins and data sources must be enforced" (OWASP).
  • OWASP ML Top 10 (v1): Supply-Chain ranked #6, warnt vor manipulierten Model-Weights, Datenpipelines und MLOps-Stacks (OWASP ML).
  • ENISA AI Threat Landscape 2023: Kapitel 4.3 beschreibt Poisoning/Dependency-Attacken auf KI-Supply-Chains und empfiehlt Hash-Verifikation + SBOMs (ENISA).
  • MITRE ATLAS (Attack Library for AI Systems): Techniken wie ALT-T004 Poison ML Supply Chain zeigen, wie kompromittierte Artefakte in Model Pipelines eingeschleust werden (MITRE ATLAS).

Diese Quellen liefern zusätzliche Controls (SBOM, Hashing, Access Control), die in unser Playbook eingeflossen sind.

Unser Playbook

  1. Signierte Artefakte: Modelle nur von Hosts mit HTTPS + Hash; Container via Cosign signieren.
  2. SBOM Pflicht: Jede KI-Komponente bekommt eine CycloneDX-BOM im Repo (make sbom).
  3. Secrets & Vault: Keine Keys mehr in .env; Tailscale/Vault liefert Just-in-Time-Tokens.
  4. Observability & Alerts: Langchain/Claude-Logs laufen in Loki; Alert bei ungewöhnlichen Tool-Calls.
  5. Incident Runbook: „LLM Supply-Chain Incident“ → isolieren, Revocation-Liste, Kunden-Benachrichtigung, Root Cause.
  6. Education: Dev-Teams bekommen monatlich ein „malicious dependency“ Walkthrough.

Incident Pattern: „Verdächtiges Modell-Update"

Auslöser: Neues GGUF/Wheel landet im internen Model-Cache. Minuten später melden Services Anomalien (ungewohnte API-Calls, erhöhte Token-Kosten).

1. Detection & Triage
- Hash-Vergleich gegen freigegebene Liste.
- Check: Hat jemand pip install / hf_hub_download außerhalb der CI gemacht?
- Alerts (Loki/Datadog): Welche Agents verwenden das neue Modell?

2. Containment
- Sofortiger Kill-Switch für betroffene Agents (Traffic → Null).
- Secrets rotieren, die in den letzten 24h genutzt wurden.
- Cache leeren, Deployments auf letzte bekannte Version zurückrollen.

3. Eradication & Forensics
- SBOM & Git-History prüfen: Woher kam das Artefakt? Wer hat zugestimmt?
- Artefakt offline analysieren (strings, Sandbox-Lauf).
- IOC-Liste (Hashes, Domains) ins SIEM einspeisen.

4. Recovery
- Modelle frisch bauen, signieren, verteilen.
- Agents kontrolliert hochfahren, Copy-On-Write-Cache nutzen.
- Kunden informieren, falls Datenabfluss möglich ist.

5. Lessons Learned
- RCA dokumentieren, Policies/Automation anpassen (kein direkter Cache-Zugriff, Mandatory Review für requirements.txt).

Fazit

KI-Supply-Chain ist kein neues Buzzword – es ist der logische Nachfolger von SolarWinds & Log4Shell, nur mit mehr beweglichen Teilen. Wer Modelle, Daten und Plugins wie echte Produktions-Binaries behandelt (Signaturen, Reviews, Observability, Kill-Switch), bleibt handlungsfähig. Alles andere ist Hoffnung – und Hoffnung ist kein Sicherheitskonzept.