Depuis plusieurs années, les attaques dites supply chain se multiplient.
Plutôt que d’attaquer directement une entreprise, les attaquants ciblent un maillon intermédiaire : une bibliothèque open source, un outil CI/CD, une dépendance populaire.
C’est une stratégie efficace :
- un seul point compromis
- des milliers, voire millions d’utilisateurs impactés
Dans ce contexte, StepSecurity a publié une analyse préoccupante :
l’outil open source Trivy a été ciblé dans le cadre d’une campagne menée par hackerbot-claw, un bot autonome basé sur l’IA.
Entre le 21 et le 28 février, six dépôts majeurs ont été ciblés.
Trivy était la sixième cible identifiée.
Ce qui rend cette affaire particulièrement intéressante ?
L’attaque n’était pas simplement automatisée.
Elle était pilotée par un agent IA capable d’analyser, générer du code et interagir avec les mainteneurs.
On ne parle plus d’un simple script malveillant.
On parle d’un attaquant autonome.
Du 21 au 28 février 2026
Durant cette période, plusieurs projets open source populaires ont reçu des contributions suspectes sous forme de Pull Requests.
Les cibles
- 6 dépôts open source majeurs
- Trivy identifié comme cible n°6
Trivy est un scanner de vulnérabilités extrêmement utilisé dans :
- pipelines CI/CD
- analyse d’images Docker
- environnements Kubernetes
- scans de dépendances
Une compromission aurait eu un effet en cascade massif.
Nature des actions
Le bot :
- analysait les dépôts
- générait des Pull Requests crédibles
- proposait des modifications techniques cohérentes
- tentait d’introduire des changements pouvant déclencher l’exécution de code
L’objectif supposé :
- exploiter les workflows GitHub Actions
- injecter du code dans le pipeline CI
- obtenir une exécution arbitraire
Bonne nouvelle :
Les mainteneurs et les protections en place ont empêché toute compromission.
Rappel sur le fonctionnement d’une attaque supply chain GitHub
Un dépôt open source fonctionne généralement ainsi :
- Contributions externes via Pull Request
- Déclenchement automatique de workflows CI
- Tests automatisés
- Validation par les mainteneurs
Si les permissions sont mal configurées :
- un workflow peut s’exécuter avec des droits excessifs
- un token GitHub peut être exposé
- du code malveillant peut être exécuté
C’est précisément ce point que les attaquants cherchent à exploiter.
Mode opératoire de hackerbot-claw
Ce qui distingue cette attaque :
Analyse autonome
Le bot :
- explorait les dépôts
- identifiait les opportunités techniques
- générait des modifications plausibles
Génération de PR crédibles
Les Pull Requests :
- semblaient légitimes
- amélioraient parfois le code
- ne contenaient pas immédiatement du code malveillant évident
On est ici dans une logique d’ingénierie sociale automatisée.
Exploitation potentielle
Scénario possible :
- La PR est acceptée
- Le workflow CI s’exécute
- Un script malveillant récupère un token
- L’attaquant obtient un accès élargi
Pourquoi l’IA change la donne
Un humain :
- cible quelques projets
- agit lentement
- peut commettre des erreurs
Un agent IA :
- cible des centaines de dépôts
- apprend de ses échecs
- adapte ses PR
- fonctionne 24/7
On entre dans une industrialisation intelligente de l’attaque.
Ce n’est plus l’automatisation brute.
C’est l’automatisation adaptative.
Ce qui a été corrigé (Réaction et mitigation)
Suite à la détection :
Analyse des PR suspectes
- revue approfondie
- suppression des contributions
- blocage des comptes associés
Renforcement des GitHub Actions
- limitation des permissions
GITHUB_TOKEN - séparation des workflows PR externes
- restriction des accès secrets
Surveillance accrue
- monitoring comportemental
- vérification renforcée des nouveaux contributeurs
Important :
Aucune compromission majeure n’a été confirmée.
Le système de review humaine a joué un rôle clé.
Sécuriser les GitHub Actions
- définir explicitement : permissions: contents: read
- ne jamais laisser
writepar défaut - utiliser des versions figées (
@commit SHA) - éviter les actions tierces non vérifiées
Isoler les PR externes
- utiliser
pull_request_targetavec prudence - ne pas exposer les secrets aux forks
- exécuter les PR dans un environnement sandbox
Renforcer la supply chain
- SBOM (Software Bill of Materials)
- signature des artefacts
- provenance verification (SLSA)
- vérification des dépendances
Se préparer aux attaques IA
- analyser les patterns de contribution
- surveiller la création massive de comptes
- mettre en place une validation humaine systématique
Le principe clé :
Ne jamais faire confiance à l’automatisation sans garde-fou.
Le début d’une nouvelle ère ?
Cette attaque n’a pas causé de dégâts.
Mais elle marque un tournant.
Nous assistons peut-être :
- aux premières campagnes offensives pilotées par IA autonome
- à une mutation des attaques supply chain
- à une industrialisation du social engineering technique
L’open source reste robuste.
Mais il devra désormais se défendre non seulement contre des humains…
… mais aussi contre des machines intelligentes.
💻 Retrouvez mes autres articles et dossiers sur ctrlaltplay.fr/
💬 Venez en discuter sur Discord
🎥 Suivez mes tests et chroniques en vidéo sur YouTube
🌀 Et mes actualités sur Bluesky
