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.

IA offensive et supply chain : l'industrialisation de la menace

Six semaines, plus de campagnes supply chain orchestrées par LLM qu'en six ans de carrière. Ce n'est pas une hyperbole — c'est la nouvelle réalité de la menace supply chain en 2026. L'IA n'a pas inventé les attaques supply chain (SolarWinds date de 2020, la compromission XZ Utils de 2024), mais elle a réduit le coût de production d'une attaque sophistiquée d'un facteur qui change le modèle de menace.

Comment l'IA industrialise les attaques supply chain logicielle

Les attaques supply chain logicielle sont traditionnellement coûteuses à préparer : elles requièrent une compréhension profonde des processus de build d'un projet, une infiltration discrète dans la communauté, et une patience de plusieurs mois ou années. L'IA offensive réduit ces barrières sur plusieurs points :

• Génération automatisée de packages typosquattés : des outils basés sur LLM peuvent générer des centaines de packages npm, PyPI ou RubyGems typosquattés (proxymy, reqests, colourama) avec des README crédibles, des métadonnées cohérentes et des fonctionnalités légitimes cachant un payload. Des campagnes comme prt-scan et CanisterSprawl ont démontré l'échelle de cette automatisation.
• Amélioration des payloads pour échapper à la détection : les LLM sont utilisés pour réécrire des malwares connus en variant leur code afin d'échapper aux signatures antivirus et aux outils d'analyse statique. La génération de variants polymorphes, autrefois un travail manuel de plusieurs heures, est automatisée en quelques minutes.
• Social engineering ciblé pour l'infiltration de projets open source : des LLM génèrent des historiques de contributions synthétiques, des messages crédibles dans les issues GitHub, des pull requests légitimes pour établir la confiance avant d'introduire une backdoor. XZ Utils illustrait déjà une infiltration patiente — l'IA accélère la préparation de ce type d'attaque.
• Analyse automatisée des dépendances pour identifier les cibles à fort impact : des outils IA analysent les graphes de dépendances npm/PyPI pour identifier les packages avec le plus de downstream dependents et le moins de mainteneurs actifs — les cibles idéales pour une compromission supply chain.

Vecteurs supply chain IA spécifiques à 2026

En 2026, de nouveaux vecteurs supply chain émergent spécifiquement liés à l'adoption massive des outils IA dans les workflows de développement :

• Compromission des plugins et extensions des IDEs IA : les extensions Cursor, GitHub Copilot et Cline ont accès au code source, aux fichiers d'environnement (.env) et parfois aux credentials système. Une extension malveillante dans ces marketplaces représente un vecteur d'exfiltration massif.
• Empoisonnement des datasets d'entraînement : des contributions malveillantes dans des dépôts GitHub publics utilisés comme datasets d'entraînement peuvent introduire des vulnérabilités dans le code généré par les LLM utilisés dans les IDE. Ces vulnérabilités se retrouvent ensuite dans des milliers de projets qui utilisent le code suggéré par l'IA.
• Hijacking des packages MCP (Model Context Protocol) : l'explosion de l'écosystème MCP (Anthropic, 2024) crée une nouvelle surface d'attaque — des serveurs MCP malveillants publiés dans des registres non gouvernés peuvent accéder aux systèmes de fichiers, aux bases de données et aux APIs auxquels l'agent LLM a accès.
• Compromission des pipelines CI/CD par injection dans les artefacts IA : des modèles IA téléchargés depuis Hugging Face et intégrés dans des pipelines CI/CD peuvent contenir des poids empoisonnés qui exécutent du code lors du chargement du modèle (pickle injection).

Défenses supply chain adaptées à la menace IA

Les défenses supply chain classiques (vérification des signatures, SBOM, pinning des dépendances) restent pertinentes mais doivent être complétées par des mesures spécifiques à la menace IA :

• Registres privés avec whitelist de packages : n'autoriser l'installation que depuis un registre privé (Artifactory, Nexus) où chaque package est validé manuellement ou par scan automatique. La consommation directe depuis npm/PyPI publics est un risque accepté, pas une nécessité.
• Audit des modèles IA avant intégration : pour les modèles Hugging Face ou autres, évitez les formats pickle (PyTorch .pkl) au profit de SafeTensors qui ne permettent pas l'exécution de code. Scannez les modèles avec des outils comme ModelScan avant leur déploiement.
• Gouvernance des plugins IDE IA : définissez une liste de plugins IDE approuvés et bloquez l'installation de plugins non validés via les politiques de gestion des postes (MDM, GPO). Les plugins IDE ont des accès très étendus.
• Monitoring de la chaîne de build : des outils comme SLSA (Supply chain Levels for Software Artifacts) ou Sigstore permettent d'attester l'intégrité de chaque artefact produit par le pipeline CI/CD et de détecter les modifications non autorisées.

Foire aux questions — IA et supply chain attacks

Comment détecter un package npm ou PyPI malveillant avant installation ?

Plusieurs approches complémentaires : vérifiez l'historique du package (date de création, auteur, nombre de téléchargements, issues signalées) — les packages malveillants sont souvent très récents. Utilisez des outils de scan comme Socket.dev, Phylum ou Snyk Open Source qui analysent le comportement du package (accès réseau, accès système de fichiers) avant installation. Configurez npm/pip pour exiger une version minimale de maturité ou un nombre minimal de téléchargements. Pour les projets critiques, auditez manuellement le code source des nouvelles dépendances avant leur intégration.

Les LLM peuvent-ils être utilisés pour détecter les attaques supply chain qu'ils facilitent ?

Oui, avec des limites. Des LLM fine-tunés sur des exemples de code malveillant peuvent détecter des patterns suspects dans les pull requests, les scripts post-install des packages npm, ou les configurations CI/CD. Des outils comme CodeShield (Meta) et Copilot Autofix (GitHub) vont dans cette direction. Mais c'est une course aux armements : les mêmes LLM qui génèrent du code malveillant peuvent être utilisés pour le rendre moins détectable. La défense est plus difficile que l'attaque dans ce contexte.