Supply chain attack sur les modèles open source (HuggingFace, GitHub)

La supply chain ML est, en 2026, la surface d'attaque la plus large et la moins défendue en sécurité IA. Vous téléchargez un modèle depuis Hugging Face Hub. Vous pip install transformers, torch, diffusers, vllm. Vous chargez un tokenizer. Vous montez un container TGI. Vous orchestrez avec LangChain depuis un repo GitHub. À chaque étape, vous exécutez du code et chargez des artefacts produits par des tiers — souvent open source, souvent communautaires, rarement audités à votre niveau. JFrog a identifié ~100 modèles malicieux sur Hugging Face en février 2024. Wiz Research a publié des vulnérabilités majeures sur les inference servers. Multiple CVE 2024-2025 sur transformers, datasets et libraries adjacentes. La classe d'attaque est devenue opérationnelle et industrielle.

Cet article documente les 8 vecteurs principaux (dataset compromis, library compromise, dependency confusion, tokenizer malveillant, inference server, CI/CD ML, checkpoint, registry compromise), les cas publics récents, et les défenses concrètes (allowlist + mirror, AI BOM, SLSA for ML, sigstore, scanning continu). Pour le focus backdoor model-spécifique : backdoor attack.

Anatomie de la supply chain ML

Une chaîne typique d'un projet IA en 2026 :

[1. Dataset]
   Hugging Face Datasets / Kaggle / sources web
                │
                ▼
[2. Pre-trained model]
   Hugging Face Hub / GitHub Releases / Civitai
                │
                ▼
[3. Libraries Python]
   PyPI: transformers, torch, diffusers, peft, accelerate, vllm
                │
                ▼
[4. Tokenizers]
   Hugging Face Tokenizers / sentencepiece
                │
                ▼
[5. Fine-tuning]
   Notebooks / scripts / partners
                │
                ▼
[6. Inference server]
   vLLM, TGI, Ollama, Triton
                │
                ▼
[7. Container / orchestration]
   Docker, Kubernetes, Modal, RunPod
                │
                ▼
[8. CI/CD]
   GitHub Actions, GitLab CI, internal pipelines
                │
                ▼
[Production]

Chaque étape est une surface d'attaque indépendante. Compromettre n'importe laquelle compromet la chaîne entière. La défense doit être présente à tous les étages — c'est ce qui distingue une approche "supply chain ML" d'une approche "backdoor model" plus étroite.

Info — Catégorie OWASP : LLM03 Supply Chain (centrale). MITRE ATLAS : Compromise AI Supply Chain (AML.T0050) + Publish Hallucinated Entities (récent 2025).

Huit vecteurs documentés

Vecteur 1 — Dataset compromis

Compromission d'un dataset open source utilisé en fine-tuning ou en pré-entraînement.

[Hugging Face Datasets]
- Dataset populaire détourné (compte mainteneur compromis)
- Nouvelle version publiée avec contenu poisoned
- Fine-tuning consomme la nouvelle version
- Modèle production embarque le poison

Cas adjacents : Common Crawl entries publiées sur des sources fiables (cf. Carlini 2023 — voir data poisoning training-time).

Mitigation : pin de version + hash, dataset audité avant utilisation, déduplication, scanning sémantique.

Vecteur 2 — Library compromise (PyPI, conda)

Le vecteur classique de supply chain logicielle, transposé ML. Une library populaire (transformers, torch, diffusers) compromise propage le risque à tous les utilisateurs.

Mécaniques connues :

• Compromission compte mainteneur : phishing, vol de credentials, account takeover.
• CI/CD compromise : injection à la phase de build.
• Dépendance transitive : la library X dépend de Y qui dépend de Z compromis.

# requirements.txt apparemment innocent
transformers==4.50.0
torch==2.5.0
diffusers==0.30.0
 
# Mais transformers 4.50.0 dépend de tokenizers, pyyaml, requests, packaging, etc.
# Chaque dépendance transitive est une surface

Cas hors ML mais transposables : event-stream npm 2018, colors.js npm 2022, multiples PyPI compromises. Sur ML spécifiquement : CVE-2024-3568, CVE-2024-46308 et autres sur transformers, datasets, tokenizers.

Mitigation : SCA (Software Composition Analysis), pip-audit, Snyk, Dependabot, lock files (requirements.lock, poetry.lock), pin de versions exactes.

Vecteur 3 — Dependency confusion / typosquatting

Pattern : créer un package avec un nom proche d'un package légitime pour piéger les utilisateurs négligents.

Exemples observés :

• tensorlow au lieu de tensorflow
• huggingface-hub-utils (faux) vs huggingface_hub (vrai)
• Sur Hugging Face Hub : metaa-llama/Llama-3 au lieu de meta-llama/Llama-3

# Attaque typosquatting
pip install transformer  # singular au lieu de transformers — peut être malicieux
pip install pytorch-lightning-utils  # nom plausible, à vérifier

Mitigation :

• Allowlist de packages autorisés.
• Vérification systématique de l'auteur et de la maintenabilité.
• pip install --require-hashes avec lock file vérifié.
• Scanners comme pypi-typosquatting-check.

Vecteur 4 — Tokenizer malveillant

Recherche émergente 2024-2025. Un tokenizer compromis peut :

• Mapper certaines séquences de tokens à des comportements anormaux.
• Embarquer du code exécutable (formats anciens type tokenizers avec serialization risquée).
• Modifier subtilement la tokenization pour activer des comportements du modèle backdoored.

# Tokenizer chargé via Hugging Face — héritant de la confiance du modèle
from transformers import AutoTokenizer
 
tokenizer = AutoTokenizer.from_pretrained("organization/model")
# Si tokenizer modifié : certains inputs produisent des séquences token inattendues

Mitigation : tokenizer hash matching, format sécurisé (JSON-only pour tokenizers Hugging Face récents), sandboxed loading.

Vecteur 5 — Inference server compromise

Les serveurs d'inférence (vLLM, TGI / text-generation-inference, Ollama, Triton) sont des applications complexes avec des CVE actives.

Vecteurs documentés 2024-2025 :

• Wiz Research a publié plusieurs vulnérabilités sur les endpoints d'inférence Hugging Face (escape de l'isolation, RCE, data leak entre tenants).
• Multiple CVE sur vLLM, TGI, Triton (RCE, path traversal, DoS).
• Containers ghcr.io/huggingface/text-generation-inference et autres images publiques avec vulnérabilités héritées.

# Audit basique d'un serveur d'inférence en prod
docker scout cves vllm/vllm-openai:latest
trivy image ghcr.io/huggingface/text-generation-inference:latest

Mitigation :

• Image scanning (Trivy, Snyk, Wiz, JFrog Xray).
• Pin de version exacte + hash (digest pinning).
• Patching régulier.
• Network isolation, RBAC strict.
• Audit CVE continu.

Vecteur 6 — CI/CD ML compromise

Comme tout pipeline CI/CD, mais avec spécificités ML : exécution de notebooks, accès GPU, secrets cloud, datasets volumineux.

Vecteurs :

• Compromission GitHub Actions / GitLab CI (cas classiques).
• Notebook Jupyter compromis (un notebook checked-in qui s'exécute en CI avec credentials).
• Workflow ML qui pull un modèle, le fine-tune, et le redéploie sans validation intermédiaire.
• Self-hosted runners ML compromis (souvent sur GPU privés sans isolation forte).

# Mauvais : pull modèle sans pin de hash, fine-tune et deploy automatique
- name: Fine-tune
  run: |
    pip install transformers
    huggingface-cli download meta-llama/Llama-3-8B
    python finetune.py
    huggingface-cli upload yourcompany/finetuned
 
# Bon : pin de hash, scan, validation manuelle pour deploy critique
- name: Pull verified model
  run: |
    huggingface-cli download meta-llama/Llama-3-8B --revision a3f4c2b1d70c4e51
    sha256sum -c expected_hashes.txt

Mitigation : SLSA (Supply chain Levels for Software Artifacts), build attestation, signed builds, CI/CD secrets management strict, runners isolés.

Vecteur 7 — Pre-trained checkpoint compromis

Couvert en détail dans backdoor attack. Résumé :

• Pickle deserialization → RCE au chargement.
• Backdoor comportemental dans les poids.
• LoRA backdoor.
• Fine-tuned model received from partner.

Mitigation : safetensors uniquement, hash matching, sandboxed loading, behavioral testing.

Vecteur 8 — Registry compromise (Hugging Face Hub, PyPI)

L'attaque la plus large : compromettre le registre lui-même (compte admin, infrastructure, infrastructure CDN).

Cas hors ML : événements npm, PyPI, Docker Hub historiques. Sur ML : pas d'incident majeur public sur Hugging Face Hub à mi-2026, mais le risque structurel existe et la posture de défense doit l'anticiper.

Mitigation :

• Mirror interne (ne pas dépendre uniquement du registre upstream).
• Verification multi-source pour les composants critiques.
• AI BOM avec hashes pour pouvoir détecter une substitution.

Cas publics et littérature

L'événement central est JFrog février 2024 qui a fait passer le risque de "théorique" à "opérationnel mesuré". Wiz Research et les CVE successives ont confirmé que l'écosystème entier (pas seulement les modèles) est concerné.

Défense en couches

Sept couches indépendantes. Aucune isolément ne couvre toute la chaîne.

Couche 1 — Allowlist + sources vérifiées

Pour chaque composant ML utilisé, source explicitement allowlistée et identité vérifiée :

# config/ml-supply-chain.yml
models:
  - id: meta-llama/Llama-3-8B-Instruct
    org_verified: true
    source: huggingface_hub
    revision: a3f4c2b1d70c4e51
    sha256: <hash safetensors>
 
datasets:
  - id: HuggingFaceH4/ultrachat_200k
    org_verified: true
    revision: <commit hash>
    sha256: <archive hash>
 
libraries:
  - name: transformers
    version: "4.50.0"
    sha256: <wheel hash>
  - name: torch
    version: "2.5.0"
    sha256: <wheel hash>
 
tokenizers:
  - id: meta-llama/Llama-3-8B-Instruct
    revision: <hash>
    format: json  # pas de format pickle

Couche 2 — Mirror interne

Tous les composants critiques sont mirrorés dans un registre interne (Artifactory, Nexus, S3 privé). La production pull uniquement depuis le mirror, jamais depuis l'upstream public.

Upstream public           Mirror interne                 Production
──────────────              ────────────────              ──────────
Hugging Face Hub  ─audit─►  hf-mirror.internal  ─pull─►  Production
PyPI              ─scan──►  pypi-proxy.internal ─pull─►  CI/CD
GitHub Releases   ─verif─►  artifacts.internal  ─pull─►  Build

Avantages :

• Reproductibilité (immunité aux suppressions upstream).
• Sécurité (audit + scan avant promotion au mirror).
• Performance (cache, géo).
• Conformité (SBOM, traçabilité).

Outils : JFrog Artifactory (mature ML), Sonatype Nexus, AWS CodeArtifact, GCP Artifact Registry, Harbor (open source).

Couche 3 — AI BOM (AI Bill of Materials)

SBOM appliqué à l'IA. Inventaire structuré de tous les composants :

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "machine-learning-model",
      "name": "Llama-3-8B-Instruct",
      "version": "a3f4c2b1",
      "supplier": {"name": "Meta"},
      "hashes": [{"alg": "SHA-256", "content": "..."}],
      "licenses": [{"license": {"id": "Llama3"}}],
      "cryptographicProperties": {
        "format": "safetensors",
        "signed": true,
        "signature": "sigstore:..."
      }
    },
    {
      "type": "dataset",
      "name": "ultrachat_200k",
      "version": "...",
      "hashes": [{"alg": "SHA-256", "content": "..."}]
    },
    {
      "type": "library",
      "name": "transformers",
      "version": "4.50.0"
    }
  ]
}

Standards en stabilisation : CycloneDX 1.6+ (AI components), SPDX 3.0 (AI profile). Outils : cyclonedx-aibom, spdx-aibom, scanners commerciaux.

Exigé progressivement par EU AI Act (Article 11 — documentation technique), US Executive Order 14110, secteurs critiques.

Couche 4 — SLSA pour ML

SLSA (Supply chain Levels for Software Artifacts) appliqué à ML. Quatre niveaux :

Pour les modèles critiques (santé, défense, financier), viser SLSA 3+. Pour les déploiements généraux, SLSA 2 minimum.

Couche 5 — Signing avec sigstore

# Signature d'un modèle
cosign sign-blob --bundle model.bundle --output-signature model.sig model.safetensors
 
# Vérification côté consommateur
cosign verify-blob \
  --bundle model.bundle \
  --signature model.sig \
  --certificate-identity ml-team@yourcompany.com \
  --certificate-oidc-issuer https://accounts.google.com \
  model.safetensors

Sigstore for ML est en pilote 2024-2026, adopté progressivement. OpenSSF Model Signing standardise.

Couche 6 — Scanning continu et CVE monitoring

# .github/workflows/supply-chain-scan.yml
name: ML Supply Chain Scan
 
on:
  schedule:
    - cron: '0 2 * * *'  # daily
  pull_request:
 
jobs:
  scan-libraries:
    runs-on: ubuntu-latest
    steps:
      - name: Pip audit
        run: pip-audit -r requirements.txt
      - name: Snyk scan
        uses: snyk/actions/python@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
 
  scan-models:
    runs-on: ubuntu-latest
    steps:
      - name: Pickle scan
        run: |
          pip install picklescan
          picklescan --recursive ./models/
 
  scan-images:
    runs-on: ubuntu-latest
    steps:
      - name: Trivy image scan
        run: |
          trivy image vllm/vllm-openai:0.6.0
          trivy image ghcr.io/huggingface/text-generation-inference:2.4.0
 
  scan-cves:
    runs-on: ubuntu-latest
    steps:
      - name: Check CVE database
        run: |
          # Custom script qui vérifie les CVE récentes pour les composants AI BOM
          python scripts/check_ai_cves.py

Outils : pip-audit, safety, Snyk, Trivy, picklescan, JFrog Xray, Wiz, Aqua, custom CVE feeds.

Couche 7 — Documentation supply chain et incident response

• Registre supply chain : tous les composants documentés avec auditeur + date.
• Plan d'incident : qui contacter en cas de compromission upstream, comment rollback rapidement, comment communiquer.
• Cadence d'audit : revue trimestrielle minimum + ad-hoc sur signal.
• Threat intelligence : abonnement aux feeds CVE, divulgations Hugging Face, advisories Snyk/Wiz.

Initiatives écosystème 2024-2026

OpenSSF Model Signing

Initiative cross-vendor (Hugging Face, Meta, Anthropic, Microsoft) pour standardiser la signature de modèles avec attestations vérifiables.

Hugging Face safetensors enforcement + verified badges

Hugging Face pousse safetensors comme défaut, badge "verified" pour organisations vérifiées, scanners pickle automatiques au push.

Sigstore for ML

Pilot 2024-2026. Adaptation du framework Sigstore pour ML (signing, transparency log, attestations).

EU AI Act + EU Cyber Resilience Act

EU AI Act Article 11 (documentation technique) + Article 17 (gestion qualité) + EU CRA (logiciels avec composants IA) imposent traçabilité supply chain.

NIST AI RMF + SSDF

Convergence des frameworks NIST sur la gestion supply chain ML.

MLSecOps émergent

Nouveau champ qui combine MLOps + SecOps. Outils : Robust Intelligence (Cisco), Protect AI, HiddenLayer, Lakera, Mindgard intègrent supply chain ML.

Tests d'audit supply chain ML

Méthodologie en 7 phases :

1. Inventaire complet : modèles, datasets, libraries, tokenizers, inference servers, containers, CI/CD pipelines.
2. Sources verification : pour chaque composant, identifier l'origine et vérifier authenticité.
3. Hashes : hash actuel vs hash audité pour chaque composant.
4. Scanning : picklescan, pip-audit, Trivy, scanners commerciaux.
5. Behavioral testing sur modèles critiques (Neural Cleanse, STRIP, red team).
6. Inference server audit : configuration, exposition, auth, isolation, CVE.
7. CI/CD audit : pipelines, secrets, runners, intégrations tierces.

Output : AI BOM versionné + risk register + plan de remédiation.

# Audit basique de la supply chain ML d'un projet
def audit_ml_supply_chain(project_root: str) -> dict:
    audit_report = {
        "models": [],
        "datasets": [],
        "libraries": [],
        "containers": [],
        "issues": [],
    }
    
    # 1. Inventaire libraries
    requirements = parse_requirements(f"{project_root}/requirements.txt")
    for lib, version in requirements:
        cves = check_cves(lib, version)
        if cves:
            audit_report["issues"].append({
                "type": "library_cve",
                "lib": lib,
                "version": version,
                "cves": cves,
            })
    
    # 2. Inventaire modèles (depuis config / huggingface_hub cache)
    for model_path in find_models(project_root):
        scan = scan_model(model_path)
        audit_report["models"].append(scan)
        if scan["is_pickle"]:
            audit_report["issues"].append({
                "type": "unsafe_format",
                "model": model_path,
            })
    
    # 3. Inventaire containers
    for img in find_container_images(project_root):
        cve_scan = trivy_scan(img)
        if cve_scan.high_or_critical:
            audit_report["issues"].append({
                "type": "container_cve",
                "image": img,
                "cves": cve_scan.high_or_critical,
            })
    
    return audit_report

Mapping conformité

EU AI Act

• Article 11 — documentation technique : AI BOM obligatoire pour systèmes haute-risque.
• Article 16 — mise en conformité : exigences supply chain.
• Article 17 — gestion qualité.
• Article 53 — GPAI : traçabilité chaîne modèles.

EU Cyber Resilience Act

S'applique aux logiciels avec composants IA :

• SBOM + AI BOM obligatoires.
• Vulnerability disclosure process.
• Updates de sécurité supply chain.

NIST AI RMF

• Map : threat model supply chain.
• Measure : audits réguliers, AI BOM tenu à jour.
• Manage : runbook incident supply chain.

NIST SSDF (Secure Software Development Framework)

• PS.1 : protection des artefacts (modèles inclus).
• PS.2 : sources connues.
• PS.3 : intégrité de la chaîne build.

MITRE ATLAS

• AML.T0050 Compromise AI Supply Chain
• AML.T0019 Publish Poisoned Datasets

Mapping OWASP LLM Top 10 v2

LLM03 a été enrichie en v2 2025 spécifiquement pour mieux capter la classe complète supply chain ML, au-delà des seuls modèles.

Points clés à retenir

• La supply chain ML est plus large que le modèle : datasets, libraries, tokenizers, inference servers, CI/CD, registres. Toutes ces étapes sont des surfaces d'attaque.
• 8 vecteurs : dataset compromis, library compromise, dependency confusion / typosquatting, tokenizer malveillant, inference server, CI/CD ML, checkpoint compromis (cf. backdoor article), registry compromise.
• Cas de référence 2024-2025 : JFrog ~100 modèles malicieux Hugging Face, Wiz Research inference vulnerabilities, multiples CVE transformers/vLLM/datasets.
• Défense en 7 couches : allowlist + sources vérifiées, mirror interne (Artifactory, Nexus), AI BOM (CycloneDX 1.6+, SPDX 3.0), SLSA pour ML, sigstore for ML, scanning continu (pip-audit, Trivy, picklescan), documentation + incident response.
• Initiatives 2024-2026 : OpenSSF Model Signing, Hugging Face safetensors + verified, Sigstore for ML pilot, EU AI Act + CRA, NIST AI RMF + SSDF.
• AI BOM devient obligation contractuelle dans plusieurs marchés (EU AI Act Art. 11, US Executive Order 14110).
• Mirror interne non-négociable pour déploiements enterprise sérieux. Reproductibilité + sécurité + résilience + conformité.
• OWASP : LLM03 Supply Chain (enrichie v2 2025).
• Audit minimum : inventaire + sources + hashes + scanning + behavioral testing modèles + inference server CVE + CI/CD audit. Output : AI BOM versionné + risk register.

La supply chain ML est aujourd'hui un programme, pas un produit : intégration aux pratiques DevSecOps existantes, AI BOM tenu à jour, mirror interne, scanning continu, audit régulier. C'est de l'ingénierie supply chain mature appliquée à l'IA — les outils existent (sigstore, CycloneDX, Trivy, picklescan), reste à les industrialiser dans les pipelines ML.