Trivy, le scanner qui volait les secrets
Il y a une forme d’ironie parfaite dans le fait que l’outil le plus déployé pour scanner les vulnérabilités de vos images se soit transformé, le temps d’une fenêtre de quelques heures, en infostealer running dans vos pipelines avec un accès complet à leurs secrets. Le 19 mars 2026, le groupe qui se fait appeler TeamPCP a compromis l’écosystème Trivy d’Aqua Security et l’histoire mérite d’être racontée non pour le frisson, mais parce qu’elle illustre à la perfection une erreur de conception que la moitié de la planète CI/CD commet encore aujourd’hui.
Ce qui s’est passé
Fort d’un accès obtenu quelques semaines plus tôt et d’une rotation de credentials qui n’avait pas été menée de façon atomique, l’attaquant a fait deux choses en parallèle. D’un côté, il a publié un binaire Trivy v0.69.4 vérolé sur tous les canaux de distribution officiels, releases GitHub, images Docker Hub, GHCR, ECR. De l’autre et c’est là que ça devient intéressant, il a force-pushé 76 des 77 tags de version du dépôt aquasecurity/trivy-action, plus les 7 tags de setup-trivy, pour les faire pointer vers un entrypoint malveillant. Ce dernier s’exécutait silencieusement avant le vrai scan, moissonnait les secrets accessibles au runner, les exfiltrait et poussait même, quand le canal principal échouait, jusqu’à créer un dépôt tpcp-docs dans votre propre organisation GitHub pour y stocker le butin. L’incident est suivi sous CVE-2026-33634.
Le raffinement qui fait mal, c’est que les commits malveillants clonaient les dates d’auteur et de commit des versions légitimes, via GIT_AUTHOR_DATE et GIT_COMMITTER_DATE, si bien que l’historique git paraissait irréprochable. Un seul tag a survécu, v0.35.0, parce qu’il pointait déjà sur le HEAD de master et que l’automatisation de l’attaquant l’a sauté.
La leçon, que vous connaissiez déjà
Voici ce qu’il faut retenir et vous le saviez sans doute déjà, ce qui rend d’autant plus embarrassant de ne pas l’avoir appliqué. Un tag est une référence mutable. Quand votre workflow écrit uses: aquasecurity/trivy-action@v0.28.0 , il ne demande pas un contenu précis, il demande “ce que ce tag désignera au moment de l’exécution” et quiconque dispose d’un accès en écriture peut déplacer ce tag vers n’importe quel commit sans que votre fichier de workflow ne change d’une virgule. Vous relisez votre YAML, il est identique à celui d’hier et pourtant il exécute désormais du code étranger.
La seule référence immuable, pour une action, c’est le SHA de commit complet et pour une image, c’est le digest sha256. Un SHA ne se force-push pas, ne se déplace pas, ne se renomme pas, il désigne un contenu et un seul, pour toujours. Épingler dessus transforme une promesse mouvante en un fait vérifiable.
Ce qu’on fait maintenant
Concrètement et par ordre d’urgence décroissante. On épingle toutes les actions tierces sur le SHA de commit complet, jamais sur un tag, quitte à se doter d’un outil qui gère la mise à jour de ces épinglages. On épingle les images sur leur digest. On active les immutable releases de GitHub là où c’est possible. On réduit le périmètre des secrets exposés aux jobs, idéalement en basculant sur OIDC pour éliminer les credentials long-lived. Et l’on surveille l’egress des runners, parce qu’un scanner qui se met soudain à parler à une IP inconnue est exactement le genre de signal qu’un Harden-Runner sait lever.
Pour mémoire, les versions saines à l’issue de l’incident étaient trivy v0.69.3, trivy-action v0.35.0 et setup-trivy v0.2.6. Mais retenez surtout ceci, valable bien au-delà de Trivy : votre scanner de vulnérabilités avait une vulnérabilité et c’était vous, faisant confiance à un pointeur mutable.