Trivy, LiteLLM : quand les outils de sécurité et d'IA deviennent le cheval de Troie
En une semaine, un groupe a piégé un scanner de sécurité très utilisé, puis une bibliothèque d'IA populaire. Ce que ça dit de la chaîne logicielle de vos projets.
La semaine dernière, un groupe baptisé TeamPCP a réussi une série d'attaques en cascade. Le 19 mars, il a piégé Trivy, un scanner de sécurité open source utilisé par énormément d'équipes de développement pour détecter les failles. Grâce aux secrets volés, il a ensuite compromis, le 24 mars, LiteLLM, une bibliothèque très répandue pour connecter une application à des modèles d'IA. Le paradoxe est cruel : l'outil censé protéger la chaîne de fabrication logicielle a servi à l'infecter. Pour une PME qui fait développer des logiciels, c'est une leçon à transmettre à ses prestataires.
Ce qui s'est passé
Trivy, le 19 mars
Selon Datadog Security Labs, l'attaquant a utilisé des identifiants restés valides après un renouvellement incomplet pour publier une version piégée de Trivy (0.69.4) et pour réécrire la quasi-totalité des versions de l'action GitHub qui permet de lancer Trivy automatiquement dans les chaînes de construction. Aqua Security, l'éditeur, a annoncé la compromission le 20 mars ; elle est référencée sous le numéro CVE-2026-33634. Une fois lancé, le code malveillant fouillait la mémoire de la machine de construction à la recherche de secrets (mots de passe, jetons, clés de cloud) et les envoyait vers un domaine imitant celui de l'éditeur.
Checkmarx, le 23 mars
Le même groupe a compromis deux actions GitHub de l'éditeur de sécurité Checkmarx, dont celle de son outil KICS, ainsi que deux extensions pour éditeurs de code.
LiteLLM, le 24 mars
LiteLLM utilisait Trivy dans sa chaîne de construction. L'action piégée y a volé les identifiants de publication du projet sur PyPI, le dépôt de bibliothèques Python. L'attaquant a publié deux versions piégées, 1.82.7 et 1.82.8. La seconde s'exécutait au simple démarrage de Python, même sans utiliser LiteLLM. Elle collectait variables d'environnement, clés SSH, identifiants de cloud, configurations Kubernetes et Docker, historiques de commandes et secrets d'intégration continue, puis s'installait durablement. PyPI a mis le projet en quarantaine. Les versions 1.82.6 et antérieures ne sont pas concernées.
Pourquoi c'est grave
Trois raisons rendent cette série particulièrement inquiétante :
- Les cibles sont des outils de confiance. Un scanner de sécurité a, par nature, accès à beaucoup de choses, et personne ne le soupçonne.
- L'effet domino. Chaque projet compromis livre les clés du suivant. Trivy a ouvert LiteLLM ; LiteLLM, installé dans des milliers d'applications d'IA, aurait pu en ouvrir d'autres.
- Les secrets visés sont ceux de la fabrication. Les machines de construction détiennent les clés de publication, d'hébergement et de déploiement. Les voler, c'est pouvoir modifier ce que reçoivent vos utilisateurs.
LiteLLM est justement le genre de brique qu'on trouve dans les projets d'IA récents, souvent montés vite. La course à l'IA ne doit pas faire oublier l'hygiène de base.
Notez aussi la vitesse : dans le cas de LiteLLM, les versions piégées sont restées en ligne peu de temps avant d'être retirées. Mais une chaîne de construction qui installe automatiquement la dernière version, plusieurs fois par jour, a le temps de la récupérer. Les attaques de ce type misent précisément sur l'automatisation de leurs victimes.
Ce que ça change pour une PME
Vous n'utilisez sans doute ni Trivy ni LiteLLM vous-même. Mais si vous faites développer une application, un site ou un outil d'IA, votre prestataire utilise forcément des dizaines de briques comparables, et une chaîne de construction automatique qui détient des secrets donnant accès à votre hébergement, à vos bases de données, à vos comptes de services d'IA. C'est là que se joue votre exposition.
Les questions à poser à vos prestataires
- Nos projets ont-ils utilisé Trivy, l'action Trivy, KICS ou LiteLLM dans les versions concernées ? Si oui, considérez tous les secrets accessibles depuis ces environnements comme exposés.
- Les secrets ont-ils été renouvelés ? Tous, pas seulement ceux qui paraissent importants : jetons de publication, clés de cloud, accès aux bases, clés d'API des services d'IA.
- Les versions des dépendances sont-elles figées ? Une chaîne qui prend automatiquement « la dernière version » d'un outil a pris la version piégée le jour même.
- Les actions d'automatisation sont-elles référencées par empreinte plutôt que par numéro de version ? Une étiquette de version peut être réécrite, comme ici ; une empreinte, non.
- Chaque secret a-t-il des droits limités ? Un jeton qui permet seulement de publier une bibliothèque fait moins de dégâts qu'une clé qui ouvre tout le cloud.
Ces bonnes pratiques font partie de notre façon de livrer un logiciel : dépendances maîtrisées, secrets cloisonnés, code source et documentation remis au client. Ce mois-ci, nous avons déjà parlé des clés d'API Google exposées, et en février de la mise à jour piratée de Notepad++ : c'est le même fil, celui de la confiance dans la chaîne logicielle. Pour faire le point sur vos projets, prenez rendez-vous.