Analyse de l'attaque supply-chain LiteLLM

Le 23 mars 2026, LiteLLM -- un composant logiciel utilise par des milliers d'organisations a travers le monde -- a ete compromis. Pendant environ 24 heures, toute organisation installant ce composant recevait a son insu du code malveillant capable de voler des mots de passe, des identifiants de services cloud et des acces aux bases de donnees. Bien que Rosecape utilise LiteLLM, nous n'avons pas ete touches -- mais nous avons reagi rapidement pour en tirer des lecons concretes.

Ce qui s'est passe

LiteLLM est un outil open source qui permet de se connecter a plusieurs fournisseurs d'IA a travers une interface unifiee. Le 23 mars, un attaquant a publie deux versions malveillantes sur PyPI (le registre public de paquets Python). Le code injecte effectuait deux operations :

1. Collecte silencieuse de donnees sensibles de la machine : mots de passe, identifiants de services cloud, cles d'acces serveur et historique de commandes
2. Exfiltration de ces donnees vers un serveur controle par l'attaquant

La compromission se declenchait a l'installation, sans aucun signe visible.

Un outil de securite comme point d'entree

Ce qui rend cette attaque particulierement frappante, c'est son origine. L'infrastructure de LiteLLM utilisait Trivy, un outil de scan de securite respecte, concu pour detecter les vulnerabilites logicielles. Or, Trivy lui-meme avait ete compromis quelques jours plus tot.

Le 19 mars, un groupe appele TeamPCP a injecte du code malveillant dans Trivy en exploitant des failles dans les mecanismes d'automatisation. Pendant environ trois heures, les organisations utilisant Trivy dans leurs processus automatises ont vu leurs identifiants et secrets d'acces silencieusement collectes.

C'est exactement ce qui est arrive a LiteLLM. Leur processus de validation automatise utilisait Trivy pour scanner les composants. Lorsque le Trivy compromis s'est execute dans leur pipeline, il a collecte les identifiants de publication du paquet LiteLLM. Avec ces identifiants, les attaquants ont publie des versions malveillantes de LiteLLM directement sur le registre public.

Le meme groupe a exploite les acces voles via Trivy pour compromettre des paquets sur npm, des extensions Visual Studio Code et des images Docker Hub -- une campagne coordonnee touchant plusieurs ecosystemes simultanement.

Comment nous avons reagi

Le 24 mars, quelques heures apres l'annonce publique de la compromission, Rosecape avait termine son enquete et securise tous ses environnements.

Constat : Rosecape n'a subi aucun impact. Notre architecture de deploiement gele les versions des composants au moment de la mise en production ; le composant compromis n'a jamais ete installe.

Neanmoins, nous avons applique des mesures preventives :

• Arret immediat de tous les services internes lies a LiteLLM, sans impact sur les donnees ou environnements clients
• Audit complet de chaque environnement confirmant qu'aucune version compromise n'avait ete installee
• Gel des mises a jour LiteLLM jusqu'a la publication d'un audit de securite independant
• Rotation preventive des identifiants internes en tant que pratique standard, malgre l'absence de detection d'exposition
• Contournement architectural : modification des systemes pour communiquer directement avec les fournisseurs d'IA, eliminant la dependance a LiteLLM tout en maintenant les fonctionnalites -- deja en production avec des options en cours d'evaluation

Cette reaction rapide -- securisation de tous les systemes en quelques heures -- a ete possible grace a une visibilite complete sur notre infrastructure : nous savions exactement ou les composants etaient deployes, leurs versions et leurs contextes de deploiement.

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. Meme la confiance dans les outils de securite a ete retournee contre les utilisateurs.

C'est un probleme structurel. Les applications modernes, y compris les outils d'IA, reposent sur des centaines de composants maintenus par des communautes open source benevoles. Compromettre un seul compte atteint des milliers d'organisations en aval.

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

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

Le "vibe coding" -- laisser les assistants IA generer du code avec un minimum de supervision -- se repand rapidement. C'est rapide, productif et souvent impressionnant. Mais imaginez ce scenario : un employe demande a un assistant IA de connecter une application a plusieurs fournisseurs d'IA. L'assistant suggere logiquement d'installer LiteLLM. L'employe accepte en un clic. Si cela s'etait produit le 23 mars 2026, tous les identifiants de la machine auraient ete compromis.

Le probleme n'est pas la suggestion de l'IA -- c'est l'absence de cadre de gouvernance. En travaillant a la vitesse conversationnelle avec les assistants IA, personne ne s'arrete pour verifier la fiabilite d'un composant.

L'analyse de donnees d'entreprise sur des machines non protegees

Un autre angle mort concerne les equipes utilisant des outils d'IA pour analyser des donnees d'entreprise directement sur des postes de travail sans environnements dedies.

Le probleme : ces memes postes contiennent souvent les acces a tous les systemes de l'entreprise -- mots de passe enregistres, acces serveur, connexions aux services cloud, identifiants de bases de donnees.

Quand du code compromis s'execute sur de telles machines, il accede a tout. Ce n'etait pas un risque theorique ; c'est exactement ce que le code malveillant de LiteLLM faisait : collecter tout ce qui etait accessible.

Le reflexe naturel de l'employe est de travailler la ou les outils sont deja configures. Mais "pratique" signifie rarement "securitaire".

La dependance invisible aux composants tiers

La plupart des dirigeants de PME ne connaissent pas LiteLLM ou Trivy -- ce sont des composants techniques, des couches intermediaires. Pourtant, la compromission de l'un a mene a la compromission de l'autre, exposant potentiellement les donnees les plus sensibles de toute organisation en aval.

C'est la nature des attaques de chaine d'approvisionnement : elles frappent les angles morts -- non pas les systemes surveilles, mais les outils que vos outils utilisent, parfois les outils de securite eux-memes.

Ce que les PME devraient faire maintenant

1. Isoler les environnements de developpement et d'analyse

Ne faites jamais d'analyse de donnees internes ou de developpement IA sur des machines ayant acces aux identifiants de production. Utilisez des environnements isoles -- conteneurs, machines virtuelles, espaces de travail dedies -- ou les secrets de production ne sont tout simplement pas accessibles.

2. Epingler et verifier les dependances

Ne faites pas confiance aux "dernieres versions". Epinglez les dependances a des versions specifiques et verifiees. Pour les images Docker, utilisez des identifiants SHA plutot 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 probleme -- c'est l'absence de politique de securite autour de cette pratique. Etablissez des regles claires : quels paquets sont installables, dans quels environnements, avec quelle supervision.

4. Inventorier vos dependances 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 proteger ce qu'on ne connait pas.

5. Planifier votre reponse avant l'incident

Notre temps de reaction de quelques heures existait parce que nous avions une visibilite sur notre infrastructure -- nous savions exactement ou LiteLLM etait deploye, sa version et son contexte de deploiement. Sans cette visibilite, une organisation pourrait passer des jours ou des semaines simplement a comprendre si elle est affectee.

L'intelligence productive commence par la maitrise

Cet incident illustre une realite recurrente : la technologie n'a de valeur que si elle est maitrisee. 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 proteges ici : composants controles, environnements isoles, infrastructure geree et hebergee au Canada, et visibilite complete sur la chaine d'approvisionnement.

Pour evaluer la posture de securite de votre infrastructure de donnees et d'IA, contactez-nous.