Trivy compromis : quelle sécurité pour vos dépendances logicielles ?

Il y a quelque chose d’ironique dans le fait que Trivy ait été compromis en mars 2026. La dépendance logicielle open source, utilisée par des milliers d’équipes pour détecter les failles de sécurité dans leurs applications, est devenue elle-même le vecteur d’une attaque majeure.

Une dépendance logicielle, c’est un composant externe sur lequel votre application s’appuie pour fonctionner comme une bibliothèque open source, un outil tiers ou un service intégré que vos équipes n’ont pas développé mais qui tourne dans votre SI. Pensez-y comme aux fournisseurs d’une entreprise, vous leur faites confiance mais vous ne contrôlez pas ce qui se passe chez eux. C’est précisément là que réside le risque. Et l’incident Trivy en est l’illustration la plus frappante de cette année.

Qu’est-ce que Trivy ?

Trivy est un scanner de vulnérabilités open source édité par Aqua Security. Son rôle est d’analyser vos images Docker, vos dépendances, vos fichiers d’infrastructure-as-code (les scripts qui décrivent et automatisent le déploiement de votre infrastructure) et vos configurations Kubernetes pour y détecter des failles connues. C’est l’un des outils les plus déployés dans les pipelines DevSecOps modernes. Trivy compte plus de 100 millions de téléchargements sur Docker Hub. Donc autant dire, une cible de choix pour quiconque cherche un accès rapide aux secrets de milliers d’organisations simultanément.

Trivy compromis 2 fois cette année

Premier épisode : fin février 2026

Un bot automatisé exploite une mauvaise configuration dans les GitHub Actions du projet Trivy. Un token d’accès privilégié est volé, le dépôt GitHub est supprimé, des releases sont effacées. L’effet est visible et brutal mais relativement compréhensible et identifiable. Aqua Security effectue une rotation de ses credentials, mais incomplète.

Deuxième épisode : 19 mars 2026

C’est là que l’attaque devient vraiment dangereuse. Le groupe TeamPCP utilise les credentials non révoqués du premier incident pour injecter du code malveillant directement dans les canaux de distribution officiels de Trivy. Concrètement :

• Une fausse version v0.69.4 est publiée sur GitHub Releases, Docker Hub et les registries de conteneurs.
• 75 des 76 tags de version du dépôt trivy-action sont écrasés pour pointer vers des commits malveillants sans que les métadonnées ne changent en apparence.
• Le binaire malveillant exécute le vrai Trivy en parallèle pour ne pas éveiller les soupçons, tout en collectant clés SSH, tokens cloud, credentials Kubernetes et secrets CI/CD, avant de les exfiltrer vers un domaine typosquatté imitant Aqua Security.

Résultat : plus de 1 000 environnements cloud infectés, selon les données relayées par Korben. Le vol de données a permis de compromettre plusieurs packages npm via un ver auto-propagateur. L’outil LiteLLM, présent dans de nombreux environnements cloud, a également été touché en cascade. De plus, la CISA américaine a intégré cet incident à son catalogue des vulnérabilités exploitées connues sous la référence CVE-2026-33634.

Pourquoi ça vous concerne, même si vous n’utilisez pas Trivy

Vos applications reposent sur des dépendances logicielles invisibles

Une application moderne n’est jamais un bloc monolithique. Elle s’appuie sur des dizaines et parfois des centaines de bibliothèques, outils et services tiers que vos équipes n’ont pas développés. Chacun de ces composants est une dépendance. Et chaque dépendance est un maillon de confiance implicite.

Compromettre un seul de ces maillons, c’est potentiellement toucher toutes les organisations qui l’utilisent en même temps. C’est précisément le principe d’une attaque supply chain : ne pas attaquer votre SI directement, mais cibler un composant en amont auquel vous faites confiance.

Trivy compromis : les impacts concrets pour votre organisation

Une compromission de ce type peut avoir plusieurs conséquences directes :

• Vol de credentials : clés API, tokens cloud, clés SSH, secrets de pipelines.. Tout ce qui est accessible depuis l’environnement d’exécution peut être exfiltré.
• Propagation latérale : les credentials volés peuvent être utilisés pour accéder à d’autres systèmes, modifier du code en production ou déployer des backdoors persistantes.
• Conformité RGPD : si le pipeline compromis déploie des applications manipulant des données personnelles, l’organisation peut se retrouver en situation de violation de données au sens de l’article 32, avec les obligations de notification qui en découlent.
• Continuité d’exploitation : une backdoor persistante installée sur les machines des développeurs peut rester active longtemps après l’incident initial, compromettant durablement l’intégrité du SI.

Trivy compromis : ce que ça implique concrètement

Les bonnes pratiques à exiger

Trivy a été compromis mais n’est pas une fatalité. Il met en lumière des pratiques concrètes que tout prestataire gérant vos pipelines devrait appliquer :

• Épingler les dépendances sur des hash SHA complets plutôt que sur des tags de version, c’est le seul identifiant qu’un attaquant ne peut pas réécrire.
• Rotation complète et systématique des secrets après tout incident, même mineur. La rotation incomplète est précisément ce qui a permis le deuxième épisode Trivy.
• Audit régulier des dépendances utilisées dans les pipelines CI/CD, avec détection des comportements anormaux.
• Monitoring des connexions sortantes depuis les environnements de build. Une connexion inattendue vers un domaine inconnu est souvent le premier signal d’une compromission.

Pour aller plus loin, notre article sur les 5 étapes pour réussir l’audit de votre SI détaille comment structurer cette démarche.

Les questions à poser à votre prestataire

Au-delà des bonnes pratiques techniques, c’est aussi une question de gouvernance. Voici ce qu’il est légitime de demander à toute équipe gérant vos pipelines ou votre infrastructure :

• Comment gérez-vous la rotation des secrets après un incident ou un changement d’équipe ?
• Vos dépendances sont-elles épinglées sur des versions immuables ?
• Disposez-vous d’un monitoring d’infrastructure capable de détecter des comportements anormaux en temps réel ?
• Comment êtes-vous alertés en cas de compromission d’une dépendance que vous utilisez ?

Un prestataire qui ne peut pas répondre clairement à ces questions mérite qu’on creuse davantage. Cet incident rappelle que la maturité en cybersécurité ne se mesure pas aux outils utilisés, mais à la façon dont on réagit quand ces outils sont eux-mêmes compromis.

FAQ : Trivy compromis révèle des enjeux

Qu’est-ce qu’une attaque supply chain ?

Une attaque supply chain ne cible pas directement votre application ou votre infrastructure. Elle compromet un composant tiers comme une bibliothèque, un outil ou une dépendance auquel vous faites confiance, pour atteindre indirectement toutes les organisations qui l’utilisent. C’est un vecteur particulièrement redoutable car il exploite des relations de confiance établies.

Mon organisation est-elle concernée si elle n’utilise pas Trivy ?

Oui. Le cas Trivy illustre un risque qui concerne toute organisation utilisant des outils open source dans ses pipelines de développement ou de déploiement. L’enjeu n’est pas Trivy spécifiquement mais la gouvernance de l’ensemble des dépendances de votre SI. Toute dépendance tierce non auditée est un vecteur potentiel.

Quels sont les impacts concrets d’une compromission de dépendance ?

Vol de credentials, propagation latérale vers d’autres systèmes, installation de backdoors persistantes et potentiellement une violation de données au sens du RGPD. Dans le cas Trivy, plus de 1 000 environnements cloud ont été infectés, avec des effets en cascade sur d’autres outils et packages.

Comment structurer un audit de ses dépendances logicielles ?

Un audit commence par un inventaire exhaustif de tous les composants tiers utilisés dans vos pipelines et applications. Il s’agit ensuite d’identifier les versions utilisées, de les croiser avec les bases de CVE connues, et de vérifier que les pratiques d’épinglage et de rotation des secrets sont en place. Un audit d’infrastructure informatique réalisé par un prestataire externe permet d’avoir un regard indépendant sur ces points.

Conclusion

L’incident Trivy n’est pas une anomalie. C’est le symptôme d’un risque structurel que la plupart des organisations acceptent sans en mesurer l’ampleur. C’est-à-dire faire confiance à des composants tiers sans les auditer, sans surveiller leurs mises à jour et sans prévoir ce qui se passe quand l’un d’eux est compromis.

La sécurité de vos dépendances logicielles est une ligne de défense à part entière. Donc l’ignorer, c’est laisser une porte ouverte dans un SI par ailleurs bien protégé.

Chez Hello Pomelo, nous intégrons ces enjeux dans nos missions de conseil DevOps et d’infogérance cloud. Si vous souhaitez faire le point sur la surface d’exposition de vos pipelines et de vos dépendances, contactez-nous.