PyTorch Lightning compromis sur PyPI : les pipelines ML sont la prochaine cible

En avril 2026, le package Python PyTorch Lightning et plusieurs paquets adjacents (intercom-client notamment) ont été compromis sur PyPI. Le payload était un credential harvester ciblant les environnements ML : tokens HuggingFace, clés AWS, clés Weights & Biases, clés Neptune.ai. C'est la première campagne supply chain documentée qui vise explicitement les pipelines MLOps. Ce ne sera pas la dernière.

Ce qui rend les pipelines ML attractifs

Trois caractéristiques structurelles font des environnements d'entraînement ML une cible privilégiée :

1. Forte densité de secrets de haute valeur : un job de training a typiquement accès aux datasets, aux registres de modèles, aux clés cloud GPU, aux tokens des plateformes de tracking. Beaucoup plus que la moyenne d'un job CI classique.
2. Surface de dépendances élargie : un projet ML moderne installe couramment 200-400 packages PyPI, dont une bonne partie maintenue par des chercheurs académiques (audit faible, signing rare).
3. Hygiène environnement plus permissive : les data scientists itèrent en notebook, créent des virtualenvs jetables, copient des pip install depuis des README. Le réflexe d'audit est moins systématique que côté ingé prod.

Le payload PyTorch Lightning, en clair

Le binaire malicieux s'activait à l'import du module, pas au pip install. C'est important : il échappait aux scanners qui se concentrent sur les hooks d'install.

Une fois actif :

• Lecture du fichier ~/.netrc, ~/.aws/credentials, ~/.huggingface/token, ~/.config/wandb.
• Énumération des variables d'environnement matchant TOKEN, KEY, SECRET, OPENAI_, ANTHROPIC_.
• Exfiltration vers un endpoint Cloudflare Workers (rotatif, durée de vie 48h).

Sur les environnements compromis, le malware a tenu plusieurs jours avant détection. Les communautés MLOps ont eu plusieurs centaines d'incidents corrélés en avril-mai 2026.

Les mesures spécifiques aux pipelines ML

1. Séparer les environnements d'expérimentation et de production

Un notebook qui charge pytorch-lightning directement depuis PyPI public ne doit pas avoir accès aux clés de production. Pratique :

• Environnement lab : credentials limités (compte sandbox cloud, modèles publics seulement).
• Environnement prod training : credentials full, accès depuis un image container scellée, validée.

Un attaquant qui passe par le lab obtient des clés sandbox, pas vos modèles propriétaires.

2. Mirror PyPI interne + quarantaine

Mêmes principes que pour npm. Verdaccio, JFrog, ou un index PyPI privé self-hosted. Quarantaine de 72h sur toute nouvelle version publiée. Sur les dépendances majeures (torch, lightning, transformers, datasets), c'est suffisamment long pour que les chercheurs sec aient le temps de signaler une compromission.

3. Hashes pinned et --require-hashes

`` torch==2.3.1 --hash=sha256:abc123... pytorch-lightning==2.2.5 --hash=sha256:def456... ``

pip install --require-hashes -r requirements.txt refuse l'installation si le hash ne matche pas. Verbeux à maintenir, mais c'est la seule garantie cryptographique que le binaire reçu est celui validé.

4. Isolation des credentials ML

Au lieu de stocker les tokens HuggingFace, W&B, Neptune dans ~/.config/*, les injecter à l'exécution depuis un Vault (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) avec rotation courte. Plus de fichier statique sur disque.

5. Network egress restreint sur les runners de training

Les runners de training n'ont besoin de joindre que :

• Votre registry de modèles.
• Votre object storage (datasets).
• Les API que vous utilisez explicitement (HuggingFace si dépendance, W&B si tracking).

Une egress policy stricte sur le runner bloque l'exfiltration C2 même si le malware s'exécute. C'est une des défenses les plus efficaces et les moins déployées.

Ce qu'il faut faire si vous pensez avoir été touché

Si votre environnement a installé pytorch-lightning entre fin mars et mi-avril 2026 :

• Rotation immédiate des tokens HuggingFace, W&B, Neptune, OpenAI, Anthropic accessibles depuis cet environnement.
• Audit AWS/GCP/Azure : opérations exécutées sous les clés exposées sur cette fenêtre.
• Si modèles propriétaires accessibles : audit des downloads depuis le registre, traces d'export vers des destinations inconnues.
• Notification interne aux équipes ML qui ont utilisé ces environnements.

Le sujet de fond : MLSecOps existe en théorie, peu en pratique

Le SecOps ML est encore largement en mode "DevOps mais avec des modèles". L'incident PyTorch Lightning illustre que les pipelines ML ont des besoins de sécurité spécifiques que les outils DevSecOps classiques ne couvrent pas bien :

• Scan SCA adapté aux packages ML (peu d'outils).
• Threat modeling spécifique aux pipelines d'entraînement.
• Politique de gestion des poids modèles (signing, traçabilité).
• Audit des datasets d'entraînement (poisoning).

C'est un terrain neuf, qui va structurer une bonne partie du travail des équipes sécurité IA dans les 24 prochains mois. Pour l'instant, les fondamentaux supply chain Python — quarantaine, hashes pinned, env séparés — couvrent 80% du risque concret.

Pour la lecture du worm Shai-Hulud côté npm, Shai-Hulud : 314 packages en 12 jours. Pour le SBOM 2026, SBOM en pratique.