En mars 2026, l’écosystème Trivy a subi une nouvelle compromission majeure :
publication malveillante de v0.69.4, compromission de setup-trivy,
réécriture de tags trivy-action, puis extension à des images Docker Hub
0.69.5 et 0.69.6. L’incident a rappelé une réalité brutale : un projet
peut garder un code source sain tout en diffusant des artefacts dangereux via
une chaîne de release compromise.
C’est dans ce contexte que Chainguard a publié un billet affirmant que ses clients n’avaient pas été affectés. Pris comme un simple message marketing, l’article aurait peu d’intérêt. Pris comme un cas d’école, il met en lumière une idée bien plus importante : reconstruire depuis les sources dans une chaîne indépendante réduit fortement l’impact d’une compromission upstream.
Ce qui a réellement été compromis dans l’incident Trivy
Le 19 mars 2026, Aqua a indiqué qu’un acteur malveillant avait utilisé des
identifiants compromis pour publier une release malveillante de trivy
v0.69.4, tout en modifiant aussi trivy-action et setup-trivy. GitHub a
ensuite publié un advisory résumant l’incident : 76 tags sur 77 de
trivy-action ont été forcés vers des commits malveillants, et les 7 tags de
setup-trivy ont été remplacés. Quelques jours plus tard, l’incident s’est
étendu à Docker Hub avec des images 0.69.5 et 0.69.6 compromises. (Advisory
GitHub)
Le plus grave n’est pas seulement la diffusion d’un binaire compromis. Le vrai danger est la position de Trivy dans les pipelines CI/CD. Lorsqu’un scanner de sécurité, une GitHub Action ou une image d’outillage est compromise, ce sont potentiellement des jetons GitHub, des identifiants cloud, des mots de passe de registre, des clés API ou des secrets Kubernetes qui deviennent accessibles à l’attaquant.
Aqua recommande d’ailleurs de considérer comme potentiellement exposés les secrets accessibles aux pipelines ayant exécuté des versions touchées. C’est un point essentiel : l’incident ne se limite pas à “un outil cassé”, il devient rapidement un incident de compromission d’identités machine et de chaîne de confiance CI/CD.
La vraie leçon : dépôt source légitime ne veut pas dire artefact fiable
Beaucoup d’équipes pensent encore qu’un dépôt GitHub légitime, une release officielle et un artefact téléchargé depuis un canal bien connu sont trois choses équivalentes.
Ce n’est pas le cas.
L’incident Trivy montre qu’un projet peut conserver un code source applicatif sain, tout en distribuant des binaires, des images ou des actions GitHub malveillants si la chaîne de release ou les identifiants de publication sont compromis. Autrement dit, le problème ne se situe pas toujours dans le code que vous lisez : il peut être dans le chemin emprunté pour transformer ce code en artefact exécutable.
C’est précisément là que le billet de Chainguard devient intéressant.
Ce que l’article de Chainguard montre vraiment
Chainguard explique que ses images Trivy ne sont pas construites à partir des artefacts upstream déjà publiés. Elles sont reconstruites depuis le code source dans leur propre chaîne de build. Leur argument n’est donc pas seulement commercial : il illustre une propriété de sécurité concrète.
Si l’attaque vise la publication des releases, les tags, les images poussées sur des registres publics ou les actions GitHub, alors une organisation qui reconstruit dans sa propre usine logicielle à partir d’une source vérifiée casse une partie de la chaîne de confiance que l’attaquant cherche à empoisonner.
Dit autrement : ce n’est pas seulement l’outil qui compte, c’est l’endroit où vous lui faites confiance.
Le point important n’est donc pas “Chainguard protège tout par magie”. Le point important est qu’une chaîne de build indépendante peut limiter l’impact d’une compromission upstream, surtout quand l’attaque touche les artefacts distribués plus que le code source lui-même.
Pourquoi ce n’est pas un blanc-seing pour Trivy
Il faut être clair : ce billet n’est pas une réhabilitation de Trivy comme choix par défaut en production.
Ma position reste la même qu’après les incidents de mars 2026 : pour des pipelines de production, je préfère aujourd’hui Grype comme scanner principal, au moins tant que toute la séquence Trivy n’a pas produit un niveau de transparence et de garanties suffisant sur la remédiation complète, les contrôles de publication et la rotation des accès.
L’intérêt de l’article de Chainguard est ailleurs. Il apporte un cas concret pour illustrer une idée que beaucoup d’équipes repoussent encore : arrêter de faire confiance aveuglément aux artefacts upstream précompilés, même quand ils sont publiés par un projet populaire et réputé.
Les suites : pourquoi l’affaire ne s’arrête pas à Trivy
L’incident ne doit pas être lu comme un épisode isolé.
D’une part, Aqua indique que l’enquête restait en cours après le 24 mars et que le vecteur exact ayant permis la reprise d’accès restait encore à confirmer publiquement. BoostSecurity souligne lui aussi que le mécanisme de réentrée dans l’organisation Aqua au moment du second incident demeure une question ouverte. Autrement dit, même après publication des premiers correctifs, tout le scénario d’accès initial et de persistance n’était pas encore totalement clarifié.
D’autre part, plusieurs acteurs du secteur ont commencé à relier cette
compromission à une vague plus large visant des composants de sécurité ou de
CI/CD. StepSecurity présente même CanisterWorm comme une continuation directe
du second incident Trivy, avec réutilisation de secrets dérobés dans des
pipelines pour publier ensuite des paquets npm compromis. Cette attribution
demande encore de la prudence, mais elle renforce une idée simple : quand un
outil de pipeline est compromis, les dégâts peuvent se propager bien au-delà du
projet d’origine.
C’est exactement pour cela qu’il faut traiter ces incidents non comme des CVE classiques, mais comme des incidents d’identité machine et de propagation supply chain.
Ce que je changerais dans mes pipelines
L’incident Trivy renforce plusieurs décisions que je considère désormais non négociables.
1. Épingler les actions GitHub sur des SHA
Un tag, même versionné, reste une référence mutable si la gouvernance de publication est compromise. L’attaque sur trivy-action l’a démontré
brutalement.
2. Réduire la confiance dans les artefacts upstream précompilés
Quand c’est possible, il faut privilégier :
- des reconstructions internes,
- des images rebâties dans une chaîne maîtrisée,
- ou au minimum des sources disposant d’attestations, de signatures et d’une provenance vérifiable.
3. Introduire une vraie promotion interne des artefacts
Les pipelines ne devraient pas tirer directement en production depuis Internet. Il faut un registre interne ou un miroir de confiance, avec validation avant promotion.
4. Prévoir la rotation rapide des secrets CI/CD
Dès qu’un outil exécuté dans le pipeline est suspecté d’avoir pu lire la mémoire du runner, l’hypothèse de compromission des secrets doit être prise au sérieux.
5. Contrôler la provenance, pas seulement les CVE
Scanner les vulnérabilités reste utile, mais cela ne suffit pas contre un artefact malveillant publié “officiellement”. Il faut aussi vérifier :
- signatures,
- attestations,
- SBOM,
- identité du build,
- canal de distribution,
- politique de promotion interne.
Ce que l’affaire Trivy rend impossible à ignorer
La leçon de l’affaire Trivy n’est pas “achetez le produit X”.
La vraie leçon est plus inconfortable : beaucoup d’équipes confondent encore dépôt source légitime, release officielle et artefact digne de confiance.
Ces trois choses ne sont pas équivalentes.
À partir du moment où la chaîne de release devient une cible prioritaire, la sécurité supply chain ne peut plus se limiter à scanner des CVE après coup. Il faut contrôler la provenance, vérifier les attestations, réduire la confiance dans les binaires amont, et arrêter d’exécuter sans recul des composants “officiels” simplement parce qu’ils sont populaires.
L’article de Chainguard est utile pour une seule raison : il rappelle, de façon très concrète, qu’une chaîne de build indépendante vaut parfois plus qu’un outil de sécurité supplémentaire.
Et c’est probablement la leçon la plus durable de tout cet épisode.