Avant d’entrer dans le vif du sujet, une mise en contexte s’impose.
Trivy est un outil open source très populaire dans le monde du développement logiciel. Son rôle : analyser du code, des images Docker ou des dépendances pour y détecter des failles de sécurité. En clair, c’est un outil qui est censé protégerles systèmes. Des milliers d’équipes techniques l’utilisent quotidiennement, souvent de façon automatisée dans leurs chaînes de fabrication logicielle (ce que les développeurs appellent les pipelines CI/CD).
Trivy est maintenu par la société Aqua Security. Et c’est précisément parce qu’il est si largement utilisé qu’il est devenu une cible de choix.
Premier épisode : fin février, le dépôt disparaît
Un premier incident avait déjà eu lieu fin février 2026, avec la disparition du dépôt GitHub de Trivy. Un dépôt GitHub, c’est l’endroit public où le code source d’un logiciel est hébergé et partagé. Sa disparition avait été spectaculaire, mais relativement lisible : des fichiers supprimés, des installations qui cessaient de fonctionner. Grave, mais visible.
Ce qui s’est passé ensuite l’est bien moins.
Second épisode : une version piégée, habillée en légitime
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.
Là, le mécanisme change radicalement. On ne parle plus d’une destruction visible. On parle d’une version officielle en apparence, distribuée normalement, mais qui contenait en réalité du code malveillant.
Pour employer une analogie : imaginez qu’un médicament soit retiré du marché après une contamination (premier épisode). Puis que, quelques semaines plus tard, une nouvelle boîte soit remise en rayon avec le même emballage, les mêmes notices, mais un contenu altéré, sans que personne dans la chaîne de distribution ne s’en aperçoive immédiatement. C’est exactement ce qui s’est produit ici.
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.
Comment l’attaquant est entré : un mot de passe jamais changé
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.
Traduisons. Un « secret » GitHub Actions, c’est une sorte de clé d’accès automatique utilisée par les robots qui font tourner les chaînes de développement. Ici, cette clé avait été volée lors du premier incident de février. Et selon les analyses publiées par la société BoostSecurity, 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.
Le détail le plus accablant : il est très probable que ce PAT n’ait pas été roté immédiatement après l’incident initial.
En d’autres termes : la clé avait été volée en février, et elle n’avait pas été révoquée. L’attaquant l’avait gardée dans sa poche, attendant le bon moment pour revenir.
Une version conçue pour tromper
L’un des aspects les plus inquiétants de cet incident est le soin apporté par l’attaquant pour rendre la version piégée indiscernable d’une version normale.
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. 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.
Un « commit », c’est une modification de code enregistrée avec un auteur, une date et un message. Ici, l’attaquant avait fabriqué de faux commits avec de vrais noms, de vrais messages, des modifications anodines en apparence. La technique de camouflage est sophistiquée.
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é.
Un faux domaine pour recevoir les données volées
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 ».
Un « typosquat » consiste à enregistrer un nom de domaine très proche d’un nom légitime, pour tromper les systèmes ou les utilisateurs. Ici, la différence entre aquasecurity (légitime) et aquasecurtiy (malveillant) se limite à deux lettres inversées. Difficile à repérer à l’oeil nu dans un journal de connexions.
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. Concrètement, le code malveillant était capable de voler des mots de passe, des clés SSH, des identifiants cloud et des tokens d’accès aux environnements Kubernetes.
La contamination s’est répandue vite et loin
C’est là que l’affaire prend une tout autre dimension.
Une fois la version 0.69.4 publiée comme si elle était légitime, les circuits de distribution automatiques ont fait leur travail… avec le mauvais contenu.
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é.
Homebrew est un gestionnaire de paquets très utilisé sur Mac. En moins de deux heures, la version piégée était disponible pour installation par des milliers de développeurs.
75 tags sur 76 de aquasecurity/trivy-action auraient été forcés vers du code malveillant. « trivy-action » est le composant utilisé directement dans les pipelines GitHub pour lancer les scans automatiques. Si ce chiffre est exact, l’immense majorité des équipes utilisant Trivy dans leurs automatismes auraient exécuté du code compromis.
Un rebondissement supplémentaire le 22 mars
Comme si cela ne suffisait pas, un nouvel épisode s’est greffé quelques jours plus tard.
Le 22 mars 2026, Socket a signalé que de nouvelles images aquasec/trivy:0.69.5 et aquasec/trivy:0.69.6 avaient été poussées sur Docker Hub sans release GitHub ni tag source correspondant. Selon leur analyse, ces images contiennent les mêmes indicateurs de compromission que v0.69.4, notamment la référence au domaine typosquatté scan.aquasecurtiy.org.
Docker Hub est une plateforme de distribution d’images de conteneurs, massivement utilisée dans les environnements cloud. Le point le plus gênant est que le tag « latest » pointait alors vers 0.69.6. Autrement dit, même des pipelines qui ne demandaient pas explicitement 0.69.5 ou 0.69.6 pouvaient récupérer une image compromise via un simple « latest ».
En pratique : beaucoup d’équipes ne précisent pas de version et se contentent de demander « la dernière version disponible ». Ces équipes ont donc pu récupérer du code malveillant sans le savoir.
La coordination a aussi été sabotée
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.
Pendant qu’experts et équipes techniques tentaient de comprendre l’étendue de l’incident, des comptes automatisés auraient inondé les espaces de discussion pour brouiller les pistes. Une attaque dans l’attaque.
Ce que cela enseigne, au-delà du cas Trivy
L’auteur de l’article original, Stéphane Robert, tire plusieurs leçons qui dépassent largement le seul cas Trivy.
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. Le délai de vingt jours entre les deux épisodes n’est pas un détail : c’est une fenêtre d’exploitation énorme.
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. C’est précisément cette automatisation qui transforme un incident de dépôt en incident de supply chain.
Pour les DPO et les responsables de la sécurité des systèmes d’information, la leçon est directe : un pipeline de fabrication logicielle est une surface d’attaque à part entière. Il doit être traité comme tel dans les analyses de risques, les registres de traitements et les politiques de sécurité.
Que faire si vous utilisez Trivy ?
Si vous avez consommé Trivy entre le 19 et le 23 mars 2026, les versions à considérer comme non fiables sont : v0.69.4 pour les binaires et images, aquasecurity/trivy-action sur les tags compromis, aquasecurity/setup-trivy avant v0.2.6, et sur Docker Hub, aquasec/trivy:0.69.4, 0.69.5, 0.69.6 et potentiellement tout usage de « latest » pendant la fenêtre concernée.
Les équipes techniques concernées devront également rechercher toute communication vers le domaine scan.aquasecurtiy.orgdans leurs journaux de connexions, et procéder à une rotation complète des secrets potentiellement exposés.
La conclusion de l’auteur : la confiance est rompue
Tant qu’Aqua Security n’aura pas publié une analyse complète et transparente de l’incident, tant qu’il n’y aura pas de communication claire sur les mesures correctives mises en place, la confiance est rompue. Stéphane Robert recommande de se tourner vers Grype (scanner de vulnérabilités) et Syft (génération de SBOM), tous deux maintenus par la société Anchore, comme alternatives matures en attendant.
Et le lien avec le RGPD ?
L’article 32 : l’obligation de sécurité s’étend à la chaîne de fabrication logicielle
Le RGPD impose aux responsables de traitement et à leurs sous-traitants de mettre en oeuvre des mesures techniques et organisationnelles appropriées pour garantir la sécurité des données. Cela inclut les outils utilisés dans les pipelines qui traitent, manipulent ou transportent des données personnelles.
Si Trivy était intégré dans un pipeline CI/CD qui déploie des applications traitant des données de santé, des données RH ou des données clients, et que ce pipeline a exécuté du code malveillant capable de voler des credentials ou des tokens d’accès, on est directement dans le périmètre de l’article 32.
L’article 28 : le sous-traitant de votre sous-traitant
Beaucoup d’organismes utilisent des prestataires de développement ou d’hébergement qui, eux-mêmes, utilisent Trivy dans leurs chaînes de build. On entre alors dans la logique de la chaîne de sous-traitance.
Le responsable de traitement est censé s’assurer que ses sous-traitants présentent des garanties suffisantes. Mais jusqu’où descend cette obligation dans la chaîne logicielle ? Cet incident pose la question de façon très concrète.
Les articles 33 et 34 : l’obligation de notification en cas de violation
C’est le point le plus opérationnel. Si un pipeline compromis a eu accès à des données personnelles, même indirectement via des logs, des variables d’environnement ou des secrets exposés, cela peut constituer une violation de données personnelles au sens du RGPD.
La fenêtre de 72 heures pour notifier la CNIL commence dès que l’organisme prend connaissance de l’incident. Or, dans cet épisode Trivy, la fenêtre d’exposition s’étend du 19 au 23 mars, et la diffusion était très largement automatisée. Beaucoup d’équipes ne sauront jamais avec certitude si elles ont été touchées.
NIS2 : la directive qui monte en charge
La directive NIS2, en cours de transposition en France, impose des obligations renforcées en matière de sécurité de la chaîne d’approvisionnement logicielle pour les entités essentielles et importantes. Hôpitaux, services de santé au travail, collectivités : des organismes que vous accompagnez directement sont dans ce périmètre.
Un incident comme celui de Trivy est exactement le scénario que NIS2 cherche à couvrir : un outil tiers, massivement utilisé, qui devient vecteur d’attaque. La question de la due diligence sur les outils de la chaîne logicielle va devenir un sujet d’audit à part entière.
L’AIPD comme outil de réponse
Pour les organismes qui traitent des données sensibles et qui utilisent des pipelines automatisés, cet incident est un argument supplémentaire pour intégrer les outils DevSecOps dans le périmètre des analyses d’impact. Un pipeline CI/CD qui déploie une application de dossier médical partagé ou un logiciel de suivi de salariés n’est pas neutre au regard du RGPD.
