Analyse de l'attaque supply-chain LiteLLM

Ce qui s'est passé

LiteLLM est un outil open source qui permet de se connecter à plusieurs fournisseurs d'IA à travers une interface unifiée. Le 23 mars, un attaquant a publié deux versions malveillantes sur PyPI (le registre public de paquets Python). Le code injecté effectuait deux opérations :

1. Collecte silencieuse de données sensibles de la machine : mots de passe, identifiants de services cloud, clés d'accès serveur et historique de commandes
2. Exfiltration de ces données vers un serveur contrôlé par l'attaquant

La compromission se déclenchait à l'installation, sans aucun signe visible.

Un outil de sécurité comme point d'entrée

Ce qui rend cette attaque particulièrement frappante, c'est son origine. L'infrastructure de LiteLLM utilisait Trivy, un outil de scan de sécurité respecté, conçu pour détecter les vulnérabilités logicielles. Or, Trivy lui-même avait été compromis quelques jours plus tôt.

Le 19 mars, un groupe appelé TeamPCP a injecté du code malveillant dans Trivy en exploitant des failles dans les mécanismes d'automatisation. Pendant environ trois heures, les organisations utilisant Trivy dans leurs processus automatisés ont vu leurs identifiants et secrets d'accès silencieusement collectés.

C'est exactement ce qui est arrivé à LiteLLM. Leur processus de validation automatisé utilisait Trivy pour scanner les composants. Lorsque le Trivy compromis s'est exécuté dans leur pipeline, il a collecté les identifiants de publication du paquet LiteLLM. Avec ces identifiants, les attaquants ont publié des versions malveillantes de LiteLLM directement sur le registre public.

Le même groupe a exploité les accès volés via Trivy pour compromettre des paquets sur npm, des extensions Visual Studio Code et des images Docker Hub -- une campagne coordonnée touchant plusieurs écosystèmes simultanément.

Comment nous avons réagi

Le 24 mars, quelques heures après l'annonce publique de la compromission, Rosecape avait terminé son enquête et sécurisé tous ses environnements.

Constat : Rosecape n'a subi aucun impact. Notre architecture de déploiement gèle les versions des composants au moment de la mise en production ; le composant compromis n'a jamais été installé.

Néanmoins, nous avons appliqué des mesures préventives :

• Arrêt immédiat de tous les services internes liés à LiteLLM, sans impact sur les données ou environnements clients
• Audit complet de chaque environnement confirmant qu'aucune version compromise n'avait été installée
• Gel des mises à jour LiteLLM jusqu'à la publication d'un audit de sécurité indépendant
• Rotation préventive des identifiants internes en tant que pratique standard, malgré l'absence de détection d'exposition
• Contournement architectural : modification des systèmes pour communiquer directement avec les fournisseurs d'IA, éliminant la dépendance à LiteLLM tout en maintenant les fonctionnalités -- déjà en production avec des options en cours d'évaluation

Cette réaction rapide -- sécurisation de tous les systèmes en quelques heures -- a été possible grâce à une visibilité complète sur notre infrastructure : nous savions exactement où les composants étaient déployés, leurs versions et leurs contextes de déploiement.

Pourquoi cette attaque est un signal d'alarme pour les PME

Cette attaque n'exploitait pas des failles techniques complexes, mais la confiance implicite dans les outils logiciels. Même la confiance dans les outils de sécurité a été retournée contre les utilisateurs.

C'est un problème structurel. Les applications modernes, y compris les outils d'IA, reposent sur des centaines de composants maintenus par des communautés open source bénévoles. Compromettre un seul compte atteint des milliers d'organisations en aval.

Pour les PME, le risque s'amplifie à travers trois tendances actuelles :

Le "vibe coding" : quand l'IA écrit votre code sans supervision

Le "vibe coding" -- laisser les assistants IA générer du code avec un minimum de supervision -- se répand rapidement. C'est rapide, productif et souvent impressionnant. Mais imaginez ce scénario : un employé demande à un assistant IA de connecter une application à plusieurs fournisseurs d'IA. L'assistant suggère logiquement d'installer LiteLLM. L'employé accepte en un clic. Si cela s'était produit le 23 mars 2026, tous les identifiants de la machine auraient été compromis.

Le problème n'est pas la suggestion de l'IA -- c'est l'absence de cadre de gouvernance. En travaillant à la vitesse conversationnelle avec les assistants IA, personne ne s'arrête pour vérifier la fiabilité d'un composant.

L'analyse de données d'entreprise sur des machines non protégées

Un autre angle mort concerne les équipes utilisant des outils d'IA pour analyser des données d'entreprise directement sur des postes de travail sans environnements dédiés.

Le problème : ces mêmes postes contiennent souvent les accès à tous les systèmes de l'entreprise -- mots de passe enregistrés, accès serveur, connexions aux services cloud, identifiants de bases de données.

Quand du code compromis s'exécute sur de telles machines, il accède à tout. Ce n'était pas un risque théorique ; c'est exactement ce que le code malveillant de LiteLLM faisait : collecter tout ce qui était accessible.

Le réflexe naturel de l'employé est de travailler là où les outils sont déjà configurés. Mais "pratique" signifie rarement "sécuritaire".

La dépendance invisible aux composants tiers

La plupart des dirigeants de PME ne connaissent pas LiteLLM ou Trivy -- ce sont des composants techniques, des couches intermédiaires. Pourtant, la compromission de l'un a mené à la compromission de l'autre, exposant potentiellement les données les plus sensibles de toute organisation en aval.

C'est la nature des attaques de chaîne d'approvisionnement : elles frappent les angles morts -- non pas les systèmes surveillés, mais les outils que vos outils utilisent, parfois les outils de sécurité eux-mêmes.

Ce que les PME devraient faire maintenant

1. Isoler les environnements de développement et d'analyse

Ne faites jamais d'analyse de données internes ou de développement IA sur des machines ayant accès aux identifiants de production. Utilisez des environnements isolés -- conteneurs, machines virtuelles, espaces de travail dédiés -- où les secrets de production ne sont tout simplement pas accessibles.

2. Épingler et vérifier les dépendances

Ne faites pas confiance aux "dernières versions". Épinglez les dépendances à des versions spécifiques et vérifiées. Pour les images Docker, utilisez des identifiants SHA plutôt que des tags mutables comme "latest" ou "stable".

3. Encadrer l'utilisation des assistants IA pour le code

Le vibe coding n'est pas le problème -- c'est l'absence de politique de sécurité autour de cette pratique. Établissez des règles claires : quels paquets sont installables, dans quels environnements, avec quelle supervision.

4. Inventorier vos dépendances critiques

Savez-vous quels composants open source font tourner vos outils d'IA ? Si non, c'est le moment de faire l'inventaire. On ne peut pas protéger ce qu'on ne connaît pas.

5. Planifier votre réponse avant l'incident

Notre temps de réaction de quelques heures existait parce que nous avions une visibilité sur notre infrastructure -- nous savions exactement où LiteLLM était déployé, sa version et son contexte de déploiement. Sans cette visibilité, une organisation pourrait passer des jours ou des semaines simplement à comprendre si elle est affectée.

L'intelligence productive commence par la maîtrise

Cet incident illustre une réalité récurrente : la technologie n'a de valeur que si elle est maîtrisée. L'IA est un levier extraordinaire pour les PME, mais seulement avec des fondations solides.

L'approche de Rosecape repose sur des principes qui nous ont protégés ici : composants contrôlés, environnements isolés, infrastructure gérée et hébergée au Canada, et visibilité complète sur la chaîne d'approvisionnement.

Pour évaluer la posture de sécurité de votre infrastructure de données et d'IA, contactez-nous.