L'IA est passée du côté des attaquants — et on s'est endormi

En six semaines, j'ai vu passer plus de campagnes supply chain orchestrées par LLM qu'en six ans de carrière en cybersécurité. prt-scan, CanisterSprawl, Asurion, Checkmarx KICS, Trivy : à chaque fois, le même schéma — l'attaquant industrialise grâce à l'IA, et nous, on continue à défendre avec des règles statiques écrites en 2018. Il est temps d'admettre que la partie a changé.

Le moment où on aurait dû voir venir

Reprenons la chronologie récente. En mars 2026, un acteur baptisé ezmtebo ouvre 475 PR malveillantes sur GitHub en 26 heures. Sept par heure, soutenues sur 22 heures. Aucun humain ne fait ça. La cadence trahit la machine. Les payloads ? Ils s'adaptent au langage du dépôt cible. Vous avez un projet Go ? Le payload arrive sous forme de _test.go idiomatique. Un projet Python avec pytest ? Le payload est un conftest.py qui passe la revue rapide. Cette adaptation contextuelle, c'est la signature d'un LLM dans la boucle.

Côté npm, CanisterSprawl pousse encore plus loin. Le worm cherche les tokens npm dans l'environnement, identifie tous les packages que la victime peut publier, incrémente le numéro de version, injecte sa charge utile et republie. Auto-propagation. La logique est triviale à coder. Ce qui est nouveau, c'est l'industrialisation : le worm cible simultanément npm et PyPI, exfiltre vers un canister ICP pour résister à la censure, et adapte ses signatures à chaque package. On n'est plus face à un script kiddie qui colle un curl bash dans un postinstall.

L'attaquant utilise l'IA comme un junior développeur productif : génération de payloads, adaptation au framework, contournement des linters de sécurité, rédaction de descriptions de PR plausibles. Tout ce qu'on imagine pour les défenseurs — l'IA qui automatise les tâches répétitives — fonctionne aussi en offensif. Et probablement mieux, parce que l'attaquant n'a pas besoin que ça marche à 100 %. Un taux de succès de 5 % sur 500 dépôts, c'est 25 organisations compromises.

Pourquoi nos défenses sont obsolètes

La détection statique repose sur des signatures. Hash du payload, regex sur les commandes suspectes, listes de domaines C2 connus. Cette approche fonctionnait quand l'attaquant réutilisait son code d'une victime à l'autre. Aujourd'hui, chaque payload est unique. Le hash ne sert plus à rien. Les regex sont contournées par des variations syntaxiques que le LLM produit à la volée. Les listes de domaines sont obsolètes au moment où elles sont publiées.

Pire : nos outils de scan SAST et nos linters de sécurité, sur lesquels on s'appuie pour bloquer le code malveillant à l'entrée des dépôts, peuvent être contournés trivialement. L'affaire LeRobot l'illustre parfaitement. Les développeurs ont volontairement collé des # nosec à côté de leurs pickle.loads() pour faire taire Bandit. Si nos défenseurs eux-mêmes désactivent les warnings, comment espérer détecter un payload soigneusement camouflé par un LLM ?

Les pull request reviews tombent dans le même piège. Un développeur qui survole une PR de 200 lignes ne va pas distinguer un conftest.py légitime d'un conftest.py qui exfiltre les variables d'environnement vers un C2. Surtout si le payload est intercalé entre du code apparemment utile, ce que le LLM peut générer sans peine. La revue par les pairs, sacro-saint pilier de l'open source, repose sur l'hypothèse que l'attaquant produit du code reconnaissable comme malveillant. Cette hypothèse est cassée.

Ce qui marche vraiment, et ce qu'on ne fait pas

Wiz a documenté la liste des dépôts qui ont bloqué prt-scan : Sentry, OpenSearch, IPFS, NixOS, Jina AI, recharts. Tous avaient en commun trois protections : approval gate pour les contributeurs first-time, restrictions actor sur les workflows pull_request_target, et conditions de path-based trigger. Aucune de ces mesures n'est nouvelle. Aucune n'est complexe à mettre en place. Pourtant, sur les 475 dépôts ciblés par la dernière vague, la majorité écrasante n'avait rien de tout cela.

Pourquoi ? Parce qu'on continue de penser la sécurité comme une couche optionnelle. On active GitHub Actions, on copie un workflow trouvé sur Stack Overflow, on l'adapte au minimum, on passe à autre chose. Personne ne lit la doc sur la différence entre pull_request et pull_request_target. Personne ne vérifie les permissions par défaut du GITHUB_TOKEN. Personne ne se demande pourquoi son secret AWS est accessible depuis un fork externe.

L'enjeu n'est plus technique, il est culturel. La supply chain dev — npm, PyPI, GitHub, Docker Hub — est devenue le terrain de jeu privilégié des attaquants parce qu'elle est universelle, peu surveillée, et que ses contrôles de sécurité sont laissés à la discrétion de chaque mainteneur. Tant qu'on n'aura pas accepté que la confiance par défaut dans les workflows CI/CD est une faille de conception, on va continuer à se faire avoir vague après vague.

L'IA défensive, vraie réponse ou nouveau marketing ?

Tout le monde sort sa solution IA-powered EDR, AI-driven CSPM, smart supply chain protection. Les budgets se réorientent. Les RSSI achètent. Et les attaques continuent. Pourquoi ? Parce que beaucoup de ces outils plaquent un modèle ML sur des règles existantes, sans changer le paradigme défensif. On détecte mieux ce qu'on connaît, mais on reste aveugle à ce qui n'a pas encore été vu.

L'IA défensive utile, c'est celle qui détecte les anomalies comportementales : un workflow qui se met soudainement à appeler un endpoint inhabituel, un postinstall script qui itère sur les variables d'environnement, un commit qui ajoute du code dans un fichier qui n'aurait pas dû être touché par la nature du PR. Cette approche existe — Snyk, Socket, Endor Labs, GitGuardian, StepSecurity proposent des choses sérieuses — mais elle reste minoritaire dans les déploiements réels.

Ce qu'il faut faire maintenant

Audit immédiat de tous vos workflows GitHub Actions : pull_request_target restreint, GITHUB_TOKEN en read-only par défaut, secrets dans les Environments avec approval gates. Pinning strict des versions de dépendances dans package.json, requirements.txt, go.mod. Activation de Dependabot ou Renovate avec revue manuelle obligatoire des bumps majeurs. Mise en place d'un outil de runtime monitoring sur les workflows CI : Socket, StepSecurity Harden-Runner, ou équivalent.

Au-delà de l'outillage, c'est une discipline d'équipe. Plus jamais de copier-coller de workflows trouvés en ligne sans relire chaque permission. Plus jamais de # nosec sans justification écrite et validée. Plus jamais de secrets cloud accessibles depuis des PR de forks. Le terrain de jeu de la supply chain dev exige le même niveau d'hygiène que ce qu'on imposait sur l'edge réseau il y a vingt ans.

Conclusion

L'IA est passée du côté des attaquants pendant qu'on regardait ailleurs. Les six dernières semaines ont été un avertissement. Les six prochaines vont coûter cher à ceux qui n'auront pas adapté leurs défenses. Vous avez encore quelques semaines pour serrer les boulons avant la prochaine vague. Utilisez-les.