Attaques de la chaîne d'approvisionnement liées à l'IA : ce que révèlent les récents incidents sur la sécurité des infrastructures d'IA

Le 24 mars 2026, un chercheur de FutureResearch s'est engagé dans une tâche de routine. La tâche consistait à installer un package Python pour un projet. En quelques minutes, le poste de travail a commencé à se comporter de manière erratique.

L'utilisation de la mémoire a considérablement augmenté. Des processus non reconnus sont apparus. Le système est tombé en panne. Le chercheur avait lancé sans le savoir l'une des attaques de la chaîne d'approvisionnement logicielle les plus sophistiquées jamais lancées contre l'écosystème de l'IA. Cette attaque était active depuis des mois, infectant des milliers d'environnements de développement avant que quiconque ne reconnaisse publiquement sa présence.

Cet article examinera les événements qui se sont produits et expliquera en quoi les outils d'IA sont particulièrement vulnérables à ce type d'attaque. Il abordera également la manière dont les équipes d'ingénieurs peuvent se protéger.

Ce qui s'est passé : une attaque de la chaîne d'approvisionnement en trois étapes

Le groupe d'acteurs de la menace identifié sous le nom de « TeamPCP », actif depuis au moins décembre 2025 et suivi au cours des neuf phases de cette attaque en cours par les chercheurs de Wiz, n'a pas directement ciblé son objectif ultime. Au lieu de cela, ce groupe d'acteurs de la menace a mené une action prudente, attaque de la chaîne d'approvisionnement en plusieurs étapes.

Étape 1 : Le 19 mars, TeamPCP a compromis Trivy, un scanner de sécurité open source largement utilisé et intégré aux pipelines CI/CD de nombreux projets.

Étape 2 : Grâce à cette base, ils ont obtenu les informations de publication PyPI d'un responsable d'une bibliothèque proxy LLM populaire téléchargée environ 3,4 millions de fois par jour.

Étape 3 : Le 24 mars, ils ont téléchargé deux versions malveillantes du package sur PyPI. Les versions compromises étaient en ligne pendant environ trois heures avant que PyPI ne les mette en quarantaine.

C'est la caractéristique déterminante des attaques modernes contre les chaînes d'approvisionnement : l'attaquant n'a jamais à vous violer directement. Ils violent une personne en qui vos outils ont confiance, et laissent cette confiance les emporter jusqu'au bout.

À l'intérieur de la charge utile : trois étapes de compromis

Le package malveillant a exécuté une charge utile sophistiquée en trois étapes que les chercheurs en sécurité de Snyk ont documentée en détail.

Étape 1 — Collecte d'informations La charge utile récoltait silencieusement tout ce qu'elle pouvait trouver : clés privées SSH, informations d'accès AWS et GCP, principes de service Azure, configurations Kubernetes, fichiers .env, informations d'identification git, mots de passe de base de données, historique du shell, secrets CI/CD et phrases de base de portefeuille de cryptomonnaies.

Étape 2 — Chiffrement et exfiltration Les données collectées ont été cryptées et transmises à un serveur contrôlé par les attaquants. Des fichiers temporaires (session.key, payload.enc, tpcp.tar.gz) ont été créés dans le répertoire temporaire du système au cours de ce processus.

Étape 3 — Persistance et mouvement latéral. La charge utile a installé un script Python de porte dérobée déguisé en service systemd appelé « Service de télémétrie système ». Ce script de persistance interrogeait une URL contrôlée par les attaquants toutes les cinq minutes à la recherche de nouvelles commandes. Il était capable de se propager sur l'ensemble de votre cluster Kubernetes en déployant des pods privilégiés sur chaque nœud de kube-system.

Ce qui rendait cela particulièrement dangereux, c'était le mécanisme de livraison : un fichier .pth. Les fichiers de configuration des chemins Python s'exécutent automatiquement chaque fois qu'un processus Python démarre, y compris pip lui-même, y compris les étapes de construction CI/CD, y compris les exécuteurs de tests. Vous n'avez pas eu à exécuter votre application. Il vous suffisait d'installer le package, et la charge utile s'est exécutée.

Pourquoi l'infrastructure d'IA est une cible spéciale

Le package concerné n'a pas été choisi au hasard. L'une des positions les plus privilégiées de la suite logicielle moderne est celle des proxys LLM (Large Language Model) et des passerelles IA. Lorsque vous installez et configurez une passerelle LLM, vous la mettez en position de se trouver directement entre les applications et les fournisseurs de services d'IA utilisés. Il a accès aux clés d'API OpenAI, aux informations d'identification Anthropic et aux comptes de service Azure et Google Cloud Platform. Il a accès aux variables d'environnement et, dans de nombreux cas, au gestionnaire de secrets. Cela est dû à la conception et est nécessaire pour acheminer les demandes, appliquer les limites de débit et enregistrer l'utilisation. Il s'agit du comportement prévu.

Cela signifie également que si la passerelle LLM et/ou l'une de ses dépendances sont compromises, l'attaquant dispose d'une visibilité totale sur l'infrastructure d'IA. Les chercheurs de Sonatype ont écrit dans leur rapport à propos de cet incident : « Comme LitellM se situe généralement directement entre les applications et plusieurs fournisseurs de services d'IA, il a souvent accès à des clés d'API, à des variables d'environnement et à d'autres données de configuration sensibles. La compromission d'un paquet dans cette position permet aux attaquants d'intercepter et d'exfiltrer de précieux secrets sans avoir à pénétrer directement dans les systèmes en amont. »

Pourquoi les cadres de conformité ne l'ont pas détecté

Le package concerné détenait les certifications SOC 2 Type 1 et ISO 27001. Cela vaut la peine d'être examiné non pas pour critiquer ces cadres — ils sont importants et les équipes qui les mettent en œuvre font le bon choix — mais parce que cela illustre une lacune structurelle.

Les cadres de conformité vérifient ce que vous faites en fonction d'une liste de contrôle. Ils couvrent les contrôles d'accès, le traitement des données et la réponse aux incidents. Ils ne vérifient généralement pas si le scanner de sécurité de votre pipeline CI/CD a été compromis par un acteur malveillant qui a ensuite pivoté pour voler vos informations de publication PyPI.

Même la vérification standard du hachage pip n'aurait pas détecté cette attaque. Le fichier malveillant .pth de la version compromise a été correctement déclaré dans le fichier RECORD du package avec un hachage correspondant. Le package a réussi tous les contrôles d'intégrité fournis par PyPI. Il s'agissait d'un colis valide qui s'est avéré être utilisé comme arme.

C'est le sécurité de la chaîne d'approvisionnement lacune que l'écosystème de l'IA doit spécifiquement combler : la question n'est pas simplement « nos systèmes sont-ils sécurisés ? » Il s'agit de « Les outils que nous utilisons pour créer et sécuriser nos systèmes sont-ils sécurisés ? »

Key Metrics for Evaluating Gateway

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

Evaluating an AI Gateway?

A practical guide used by platform & infra teams

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

Comment TrueFoundry pense de ce problème

Chez TrueFoundry, sécurité de la chaîne d'approvisionnement est une préoccupation de premier ordre dans la conception de notre plateforme MLOps, et non une question secondaire.

Lorsque les entreprises déploient des modèles et Passerelles LLM grâce à TrueFoundry, nous posons un autre type de question : pas simplement « ce terminal est-il sécurisé ? » mais « quel est le rayon d'explosion si l'un des composants de cette pile est compromis ? »

Quelques principes guident la façon dont nous construisons :

L'infrastructure s'exécute dans votre VPC. Lorsque votre infrastructure d'IA fonctionne à l'intérieur des limites de votre propre cloud, les secrets ne sont jamais transmis à des systèmes externes. Même si une dépendance quelque part de l'écosystème était compromise, le point de terminaison d'exfiltration ne serait pas accessible depuis le périmètre de votre réseau.

Les dépendances sont épinglées et auditées. Plutôt que d'extraire silencieusement les dernières nouveautés de chaque version, TrueFoundry conserve les dépendances épinglées et révisées sur l'ensemble de la plateforme. Cela permet d'éliminer toute une catégorie de vecteurs de la chaîne d'approvisionnement.

L'isolation des composants limite le rayon d'explosion. Un compromis dans une couche de la pile n'autorise pas automatiquement l'accès à une autre. Principe du moindre privilège, appliqué au niveau de l'infrastructure.

Rien de tout cela n'est de l'ingénierie exotique. Il s'agit d'une discipline appliquée à un modèle de menace que les outils d'IA, en tant que secteur, n'ont pas pris assez au sérieux : la menace ne passe pas par votre pare-feu. Il provient de votre fichier requirements.txt.

Ce que votre équipe doit faire dès maintenant

Si vous utilisez des outils d'IA basés sur Python, comme le font presque tous les team building sur LLM, les actions suivantes méritent d'être prioritaires immédiatement.

1. Vérifiez les versions des packages que vous avez installés. Exécutez pip show litellm | grep Version. Si votre sortie indique 1.82.7 ou 1.82.8, considérez le système comme compromis et ne vous contentez pas de le mettre à niveau sur place. La charge utile a peut-être déjà été exécutée. Reconstruisez à partir d'un état propre sur une machine dont le nettoyage a été vérifié.

2. Auditez les fichiers .pth sur les machines et les exécuteurs CI.

find $(python3 -c "import site; print(' '.join(site.getsitepackages()))") \
  -name "*.pth" -exec grep -l "base64\|subprocess\|exec" {} \;

3. Vérifiez la présence d'artefacts de persistance.

ls -la ~/.config/sysmon/sysmon.py 2>/dev/null && echo "BACKDOOR FOUND"
systemctl --user status sysmon.service 2>/dev/null
ls /tmp/tpcp.tar.gz /tmp/session.key /tmp/payload.enc 2>/dev/null

4. Effectuez une rotation agressive des informations d'identification. Si l'une des machines concernées avait accès à des informations d'identification cloud, à des clés SSH, à des clés d'API, à des jetons de compte de service Kubernetes ou à des mots de passe de base de données, changez-les toutes maintenant. N'évaluez pas, faites une rotation. La charge utile ciblait spécifiquement AWS Secrets Manager, SSM Parameter Store et les secrets de cluster Kubernetes dans tous les espaces de noms.

5. Vérifiez Kubernetes pour détecter les pods malveillants.

kubectl get pods -A | grep "node-setup-"

Les pods nommés node-setup- {node_name} dans l'espace de noms kube-system sont un indicateur connu de compromission lié à cette campagne.

6. Passez à un registre de paquets privé. PyPI n'est pas la seule option pour la résolution des dépendances. Un miroir de package privé avec des hachages épinglés et un flux de travail d'approbation éliminent toute cette classe de vecteurs d'attaque. Des outils tels que Artifactory, AWS CodeArtifact ou Google Artifact Registry peuvent servir d'intermédiaires.

7. Traitez votre chaîne d'approvisionnement CI/CD comme une surface d'attaque. Le compromis initial de la campagne TeamPCP ne concernait pas la bibliothèque cible, mais le scanner de sécurité utilisé dans le pipeline CI de cette bibliothèque. Votre infrastructure de build, vos actions GitHub et vos intégrations tierces font tous partie de votre surface d'attaque. Auditez-les en conséquence.

Le schéma général : ce n'est pas un cas isolé

Ce qui rend cette affaire particulièrement intéressante, c'est qu'il ne s'agissait pas d'une attaque opportuniste. Au contraire, TeamPCP exécute cette campagne laborieuse depuis au moins décembre 2025. Avant d'attaquer Litellm, TeamPCP a compromis le scanner de sécurité Trivy d'Aqua (19 mars), les extensions VS Code de CheckMarx et GitHub Actions (23 mars), ainsi que plusieurs packages NPM contenant un ver autopropagé.

Notez que la paire de clés RSA utilisée est identique à celle utilisée dans toutes les autres attaques, tout comme le nom du bundle tpcp.tar.gz et les dépôts GitHub préfixés par tpcp-docs. Cela suggère que TeamPCP est un acteur de menaces professionnel qui exécute méthodiquement sa campagne.

Cela implique que les équipes qui ont été compromises par cette campagne n'ont pas fait preuve de négligence. Ils s'engageaient plutôt dans les meilleures pratiques : tirer parti de logiciels libres très populaires et bien évalués.

Ce qui rend cela intéressant, c'est que TeamPCP n'a identifié aucune faiblesse dans les défenses d'une organisation. TeamPCP a plutôt identifié une faiblesse dans la manière dont l'ensemble de l'écosystème de l'IA a abordé la confiance au sein de sa chaîne de dépendance.

Le problème de confiance que l'infrastructure d'IA doit résoudre

L'écosystème de l'IA a construit quelque chose d'extraordinaire en très peu de temps. La rapidité et l'ouverture qui ont rendu cela possible, à savoir la culture de l'installation et du partage de pip, qui consiste à tirer parti du travail des uns et des autres, sont véritablement précieuses et méritent d'être préservées.

Mais la vitesse sans sécurité de la chaîne d'approvisionnement crée de la dette. La surface d'attaque d'une pile d'IA moderne ne se limite plus aux terminaux que vous exposez. Il s'agit de chaque package de votre arbre de dépendances, de chaque outil de votre pipeline CI/CD, de chaque composant open source qui a accès à vos secrets lors de la compilation ou de l'exécution.

Pour combler cet écart, il ne suffit pas d'améliorer la réponse aux incidents de la part des équipes concernées. Cela nécessite que l'ensemble de l'écosystème de l'infrastructure d'IA (responsables, fournisseurs de plateformes, entreprises et équipes de sécurité) traite la provenance de la chaîne d'approvisionnement comme une préoccupation d'ingénierie de premier ordre.

Le chercheur dont la machine est tombée en panne ne pensait probablement pas qu'il était sur le point de dévoiler une campagne de plusieurs mois ciblant l'infrastructure de l'IA. Aucun des développeurs qui ont exécuté une installation de routine de pip n'a non plus fait d'installation. C'est la nature de attaques contre la chaîne d'approvisionnement logicielle. Au moment où vous les voyez, le mal est souvent déjà fait.

L'industrie de l'IA peut mieux construire. Il le faut.

Questions fréquemment posées

Qu'est-ce qu'une attaque de la chaîne d'approvisionnement logicielle ?

Une attaque de la chaîne d'approvisionnement logicielle se produit lorsqu'un acteur malveillant compromet un composant fiable en amont de la cible finale, tel qu'un outil de développement, une bibliothèque open source ou un pipeline CI/CD, et l'utilise pour distribuer du code malveillant à chaque utilisateur en aval de ce composant. Plutôt que d'attaquer directement une organisation, les attaquants exploitent la confiance implicite que les développeurs accordent aux packages et outils largement utilisés.

Comment les équipes d'IA et de ML peuvent-elles protéger leur infrastructure contre les attaques de la chaîne d'approvisionnement ?

La protection de l'infrastructure d'IA et de machine learning contre les attaques de la chaîne d'approvisionnement nécessite plusieurs mesures complémentaires. Les équipes doivent utiliser un registre de packages privé (tel qu'AWS CodeArtifact, Google Artifact Registry ou Artifactory) avec des hachages de dépendances épinglés plutôt que de les extraire directement du PyPI public. L'audit régulier des fichiers .pth dans les répertoires Python site-packages permet de détecter rapidement des ajouts malveillants. L'exécution d'une infrastructure d'IA, y compris des passerelles LLM et des composants de service de modèles, au sein d'un VPC privé limite la capacité d'un attaquant à exfiltrer des informations d'identification vers des serveurs externes, même si une dépendance est compromise. La mise à jour d'une nomenclature logicielle (SBOM) pour votre pile de machine learning permet d'identifier plus rapidement l'exposition lorsqu'un nouvel incident est révélé. Enfin, les pipelines CI/CD eux-mêmes doivent être traités comme une surface d'attaque : les outils utilisés pour créer et sécuriser les logiciels, y compris les scanners de sécurité et les actions GitHub, peuvent être compromis et ont été compromis dans le cadre de campagnes de chaîne d'approvisionnement plus larges.

Quels sont les facteurs à prendre en compte par les équipes lors de l'évaluation de la passerelle LLM sécurisée pour atténuer les risques d'attaques contre la chaîne d'approvisionnement ?

La passerelle LLM doit fonctionner dans le VPC de l'organisation. Ainsi, si les dépendances sont compromises, il n'y a aucune voie d'exfiltration. Les dépendances doivent être épinglées et auditées plutôt que d'être résolues au moment de l'installation à l'aide de registres publics. Les informations d'identification ne doivent pas être gérées par le biais de variables d'environnement, mais par le biais du gestionnaire de secrets natif du fournisseur de cloud. Un enregistrement d'audit de toutes les invocations de modèles, de l'utilisation des clés et des modifications de configuration doit également être effectué. De cette façon, tout comportement anormal peut être facilement identifié. Toutes ces configurations sont configurées par défaut dans TrueFoundry, ce qui réduit la surface d'attaque par rapport aux outils open source autogérés.