Trivy compromis une seconde fois : la release v0.69.4 était empoisonnée

Publié le 20 mars 2026

12 min de lecture

#trivy#github-actions#supply-chain#devsecops#securite

Mise à jour importante Ce billet couvre le second épisode de l’incident Trivy. Mon premier article décrivait la compromission initiale de fin février et la disparition du dépôt GitHub. De nouveaux éléments publics publiés le 20 mars 2026 montrent qu’un nouveau rebondissement a eu lieu le 19 mars, avec publication d’une release v0.69.4 compromise. L’enquête externe est encore en cours, donc certains points restent à confirmer.

Ce qui s’est passé

Je pensais que l’histoire de Trivy était derrière nous : dépôt restauré, incident public, premières corrections côté workflows GitHub Actions. Mais les nouvelles analyses publiées par BoostSecurity montrent un scénario bien plus inquiétant : le 19 mars 2026, une release v0.69.4 de Trivy a été publiée avec du code malveillant intégré, puis propagée dans plusieurs canaux de distribution. BoostSecurity estime qu’il est hautement probable que le même PAT volé fin février ait été réutilisé. BoostSecurity précise aussi que son enquête est publiée de façon anticipée pour aider le threat hunting communautaire, et que certains détails doivent encore être consolidés.

Autrement dit, on ne parle plus seulement d’un dépôt vidé ou de releases supprimées. On parle d’une release empoisonnée qui a emprunté les circuits normaux de distribution du projet.

Pourquoi ce second incident est plus grave

Lors du premier épisode, l’effet visible était brutal : releases supprimées, dépôt remplacé, installateurs cassés. C’était spectaculaire, mais cela restait principalement un incident de destruction. Dans ce second acte, le risque est différent : un attaquant semble avoir réussi à faire publier un artefact malveillant comme s’il était légitime.

BoostSecurity indique que la release v0.69.4 aurait été diffusée via GitHub Releases, Homebrew, AWS ECR, Docker Hub, GHCR et qu’une grande partie des tags de trivy-action auraient aussi été réécrits pour servir du code malveillant. Si cette analyse se confirme intégralement, on est face à une compromission de chaîne de distribution, pas seulement de dépôt source.

Le point de départ probable : un PAT volé puis non révoqué

Dans son analyse, BoostSecurity revient sur la compromission initiale de février : un secret GitHub Actions nommé ORG_REPO_TOKEN, associé au compte de service aqua-bot, aurait été exfiltré via une attaque de type Pwn Request. Selon Boost, ce token avait un périmètre très large, avec un usage dans au moins 33 workflows de l’organisation, ce qui en faisait un point de défaillance extrêmement dangereux. BoostSecurity estime aussi qu’il est très probable que ce PAT n’ait pas été roté immédiatement après l’incident initial.

Cette hypothèse colle à la suite des événements observés publiquement : le compte de service aqua-bot apparaît dans les actions liées à la publication de v0.69.4, à la suppression d’un tag v0.70.0, ainsi qu’à des opérations sur les dépôts liés à l’écosystème Trivy.

Une release empoisonnée construite pour paraître légitime

L’un des points les plus intéressants dans l’analyse BoostSecurity est la préparation de deux commits imposteurs non rattachés à une branche. L’un visait actions/checkout, l’autre aquasecurity/trivy. Ces commits utilisaient des auteurs crédibles, des messages plausibles et des modifications volontairement discrètes pour se fondre dans le bruit d’un diff ordinaire.

Le commit côté Trivy introduisait notamment trois changements clés :

un pinning de actions/checkout vers un SHA malveillant mais crédible ;
l’ajout de --skip=validate à GoReleaser ;
des changements cosmétiques dans le YAML pour diluer le vrai signal dans le diff.

C’est précisément le genre de détail qui devrait nous faire réfléchir : dans l’absolu, pinner une action par SHA est une bonne pratique. Mais si le SHA lui-même pointe vers un commit malveillant, cette bonne pratique devient un faux sentiment de sécurité.

Le rôle du domaine typosquatté

BoostSecurity identifie un domaine de commande et contrôle particulièrement parlant : scan.aquasecurtiy.org. Il s’agit d’un typosquat du domaine Aqua Security, avec inversion de lettres dans security. Selon l’analyse, le faux actions/checkout téléchargeait depuis ce domaine plusieurs fichiers Go destinés à remplacer des composants du binaire Trivy, ainsi qu’un fichier .golangci.yaml pour masquer les alertes du linter sur le code injecté.

Toujours selon Boost, les fichiers téléchargés permettent de comprendre l’intention : point d’entrée modifié, démon persistant et code spécifique Unix/Windows. En s’appuyant sur l’analyse de Socket, BoostSecurity relie aussi cette charge utile à des capacités de vol de secrets en mémoire, de collecte de clés SSH, de credentials cloud et de tokens Kubernetes.

La chronologie du 19 mars

La séquence publiée par BoostSecurity est particulièrement instructive.

À 17:43 UTC, le tag v0.69.4 est poussé vers le commit empoisonné, ce qui déclenche les workflows de documentation et de release. Huit minutes plus tard, à 17:51 UTC, aqua-bot supprime un tag v0.70.0, ce qui laisse penser à une première tentative abandonnée car trop visible. L’attaquant serait ensuite revenu à v0.69.4 pour mieux se fondre dans la série de versions existante.

BoostSecurity indique ensuite que le pipeline de release a exécuté une chaîne classique mais dangereuse dans ce contexte : login sur les registres, checkout du code, build multi-plateforme avec GoReleaser, publication des images et de la GitHub Release. La publication de la release compromise aurait eu lieu à 18:25:54 UTC.

La propagation aval

C’est ici que l’incident change vraiment de dimension.

Homebrew

BoostSecurity documente qu’à 18:05 UTC, un bot Homebrew a ouvert une PR automatique pour intégrer trivy 0.69.4 dans homebrew-core. La PR a été mergée à 19:35:58 UTC, ce qui a rendu disponibles des bouteilles compromises sur plusieurs plateformes avant qu’un downgrade d’urgence vers 0.69.3 ne soit ensuite déclenché. StepSecurity confirme aussi ce rollback d’urgence vers v0.69.3.

setup-trivy

BoostSecurity indique qu’entre 22:06 et 22:08 UTC, aqua-bot a publié en rafale plusieurs releases sur aquasecurity/setup-trivy, réécrivant l’historique de versions v0.1.0 à v0.2.5. BoostSecurity note aussi qu’aucun workflow n’a été déclenché ce jour-là sur ce dépôt, ce qui suggère des publications faites directement via l’API GitHub. Plus tard, la réponse à incident a supprimé tous les tags sauf v0.2.6, propre, ce qui a cassé les pipelines épinglés sur les anciennes versions. StepSecurity confirme que seul v0.2.6 a été conservé comme tag sain.

trivy-action

BoostSecurity écrit que 75 tags sur 76 de aquasecurity/trivy-action auraient été forcés vers du code malveillant, seul @0.35.0 restant intact. StepSecurity, plus prudent sur la formulation, indique que trivy-action était encore compromis au moment de sa publication. Si c’est exact, l’impact potentiel est énorme, car cette action est largement référencée dans les workflows GitHub.

Registres d’images

BoostSecurity affirme que GoReleaser a poussé des images multi-architecture vers public ECR, Docker Hub et GHCR sous le tag 0.69.4. Là encore, si cette chaîne est confirmée de bout en bout, le problème dépasse largement le seul binaire GitHub Release.

Une réponse à incident perturbée

Autre élément troublant : BoostSecurity indique que la discussion GitHub initiale de l’incident de février, #10265, a été supprimée pendant la phase de réponse. StepSecurity rapporte aussi que cette discussion contenait des échanges actifs sur la nouvelle compromission v0.69.4.

BoostSecurity décrit également une campagne de flood par comptes bots dans la discussion de remplacement, avec des commentaires génériques destinés à noyer les signaux utiles. Si c’est bien le cas, on ne parle pas seulement d’une compromission technique, mais aussi d’une tentative de brouillage de la coordination communautaire pendant la remédiation.

Ce que l’on sait, ce que l’on pense, ce qui reste à confirmer

À ce stade, plusieurs éléments sont observables publiquement :

une release v0.69.4 a bien existé puis a été supprimée ;
un retour d’urgence de Homebrew vers v0.69.3 a bien eu lieu ;
setup-trivy a bien été purgé pour ne laisser qu’un tag v0.2.6 propre ;
la communauté a lancé un audit plus large des workflows Trivy après le premier incident. Une PR publique mentionne 26 findings sur 22 workflows et 2 composite actions, avec notamment des corrections d’exposition de secrets et l’ajout de blocs permissions: explicites.

En revanche, certains points restent encore au niveau de l’analyse très probable, pas de la certitude absolue :

que le même PAT soit bien la cause directe de ce second épisode ;
que l’ensemble des canaux de distribution cités aient effectivement servi des artefacts compromis pendant la même fenêtre ;
que toute l’étendue de la compromission de trivy-action soit précisément connue.

Je préfère donc rester rigoureux : les indices sont très forts, mais l’enquête externe est toujours active.

Les vraies leçons pour nos pipelines

1. Un secret d’organisation dans GitHub Actions est une dette de sécurité majeure

Le point le plus frappant ici n’est pas seulement l’exploitation initiale. C’est le niveau de blast radius d’un secret partagé entre de nombreux workflows. Quand un PAT donne potentiellement accès à plusieurs dépôts, releases, tags et discussions, la compromission d’un seul workflow devient une compromission organisationnelle.

2. La rotation immédiate n’est pas négociable

Si l’hypothèse BoostSecurity est correcte, le second incident est précisément ce qui arrive quand un credential volé n’est pas révoqué à temps. Le délai de vingt jours entre les deux épisodes n’est pas un détail : c’est une fenêtre d’exploitation énorme.

3. Le pinning par SHA ne suffit pas

On répète souvent qu’il faut pinner les actions GitHub par SHA. C’est vrai. Mais ce cas rappelle qu’il faut aussi valider la provenance du commit, vérifier s’il est signé, s’il appartient bien à l’historique attendu, et s’il n’est pas simplement un commit orphelin préparé pour tromper les défenseurs. BoostSecurity note d’ailleurs que les commits utilisés ici étaient non signés et que ni actions/checkout ni aquasecurity/trivy n’imposaient la signature.

4. Les bons workflows doivent être pensés comme des surfaces d’attaque

L’audit public lancé après le premier incident est révélateur : secrets exposés en ligne de commande, injections shell possibles, permissions absentes ou trop larges. Ce ne sont pas des détails de style. Ce sont des portes d’entrée.

5. Les canaux de distribution automatisés propagent très vite une release compromise

Homebrew, images OCI, GitHub Actions : une fois qu’une release a l’air légitime, la propagation peut être très rapide et largement automatisée. Ici, c’est précisément cette automatisation qui transforme un incident de dépôt en incident de supply chain.

Ce qu’il faut faire maintenant si vous utilisez Trivy

Si vous avez consommé Trivy autour du 19 mars 2026, en particulier la version 0.69.4, la prudence impose de considérer cette version comme non fiable. Les utilisateurs de setup-trivy et trivy-action doivent aussi vérifier précisément les versions, tags et SHAs consommés, car plusieurs tags ont été supprimés ou réécrits pendant la réponse à incident.

Il faut également :

vérifier vos caches CI ;
rechercher la présence de 0.69.4 dans vos builds et images ;
inspecter les téléchargements et releases GitHub autour du 19 mars ;
contrôler les références à setup-trivy et trivy-action dans vos workflows ;
rechercher toute communication vers scan.aquasecurtiy.org.

Mon point de vue

Ce second épisode est, à mes yeux, encore plus instructif que le premier.

Le premier montrait qu’un workflow GitHub Actions mal conçu pouvait mener à une compromission majeure. Le second montre quelque chose de plus dur à entendre : une fois qu’un attaquant tient un credential puissant, il peut revenir plus tard, se fondre dans les automatismes du projet, puis transformer l’écosystème de build et de distribution en vecteur d’attaque.

La vraie leçon n’est donc pas seulement “ne pas utiliser pull_request_target n’importe comment”. La vraie leçon est plus large : un pipeline CI/CD doit être administré comme un système critique, avec séparation des privilèges, secrets à très courte durée de vie, rotation immédiate, signatures obligatoires, contrôle des tags, vérification de provenance et capacité de réponse rapide.

Sinon, le jour où la chaîne casse, ce n’est pas juste votre dépôt qui tombe. C’est la confiance de vos utilisateurs qui part avec.