Trivy est censé vous aider à sécuriser vos images Docker, vos dépendances et vos pipelines CI/CD. Sauf qu’ici, le sujet n’est pas un bug banal : l’outil lui-même a été compromis à deux reprises en moins d’un mois par le groupe TeamPCP. Traduction business : si votre chaîne de build utilise un composant “de confiance”, vous pouvez embarquer un malware sans lever le petit doigt. Et ça concerne directement les PME et les DSI qui automatisent leurs déploiements à la chaîne.
L’Opportunité PME
Oui, il y a une bonne nouvelle dans ce genre d’incident : il force enfin les entreprises à remettre de l’ordre dans leur chaîne logicielle. En pratique, une revue de Trivy et des outils voisins comme Checkmarx AST, LiteLLM, n8n ou Make permet souvent de trouver des dépendances vieillissantes, des secrets trop longtemps valides, et des pipelines qui exécutent tout “en confiance” sans contrôle humain.
Le gain est très concret : moins de risques de vol de clés SSH, de jetons cloud ou de secrets CI/CD ; moins d’incidents qui partent d’un simple tag flottant ; et surtout moins de temps perdu à gérer une crise après coup. Un audit de vos logs CI/CD sur la période février-mars 2026, couplé à une revue des versions utilisées, permet de couper court à la contamination silencieuse avant qu’elle ne remonte chez vos clients.
La Vigilance
Le piège, c’est le côté “invisible” de l’attaque. TeamPCP a profité d’identifiants mal révoqués et de tag poisoning pour injecter un stealer dans les GitHub Actions et les images Docker concernées. Les versions Trivy 0.69.4 à 0.69.6 ont été visées, avec un impact déjà observé sur plusieurs environnements et organisations. Quand on parle de plus de 1 000 environnements cloud infectés, on n’est plus sur une anecdote de développeur : on parle de risque systémique.
Autre point de vigilance : la rotation des identifiants. Si l’ancien token reste valide pendant que le nouveau est créé, vous avez en réalité deux portes d’entrée au lieu d’une. Ajoutez à cela des builds automatisés qui exécutent les outils sans validation humaine, et vous obtenez une chaîne de propagation très efficace. Le vrai problème n’est pas seulement l’attaque initiale, c’est votre capacité à la voir, la contenir et prouver ce qui a été exécuté.
Le Point Conformité
Quand des données sensibles ou des accès cloud sont potentiellement exposés, on sort du simple incident technique. L’exemple de l’incident lié à la Commission Européenne montre bien que l’accès à des données AWS peut déclencher des obligations de notification, notamment au titre du RGPD si des données de personnes concernées sont touchées. Côté Suisse, la nLPD entre aussi en jeu si vos environnements ou vos hébergements sont concernés.
Le bon réflexe : lancer rapidement la forensique des accès, identifier ce qui a transité, et documenter précisément les logs d’exécution et les secrets potentiellement compromis. Sans ça, vous gérez l’attaque à l’aveugle, avec en prime un risque juridique inutile.
Conclusion & L'Accompagnement Cohesium
Cette affaire rappelle une chose très simple : dans une chaîne CI/CD moderne, le point faible n’est plus seulement votre code, mais aussi les outils que vous utilisez pour le protéger. Si vos dépendances, vos secrets et vos workflows ne sont pas gouvernés, un incident open source peut devenir un incident client en quelques minutes.
Plutôt que de bricoler, Cohesium AI peut auditer vos pipelines CI/CD, vérifier vos secrets et vos identifiants machine, analyser vos exécutions passées à la recherche d’une contamination, et mettre en place une gouvernance supply chain pragmatique pour réduire drastiquement le risque de propagation. Contactez-nous