Votre firewall est à jour. Votre SIEM tourne. Vos pentests annuels reviennent propres. Et pendant ce temps, un ingénieur de votre équipe vient d’exécuter npm install et de déposer un RAT sur son poste de développement. La supply chain logicielle n’est plus une menace théorique — c’est l’un des vecteurs d’accès initial les plus exploités en 2026 par les APT comme par les cybercriminels opportunistes. Voici pourquoi, et comment s’en protéger concrètement.

La surface d’attaque que personne ne surveille

Chaque jour, des dizaines de milliers d’organisations dans le monde exécutent npm install, pip install, composer require ou go get. Ces commandes récupèrent des bibliothèques depuis des registres publics — npm, PyPI, Packagist, pkg.go.dev — et les intègrent directement dans la chaîne de build, parfois en quelques secondes, sans contrôle humain systématique. C’est une confiance implicite absolue accordée à des milliers d’inconnus.

Pour mesurer l’ampleur, voici quelques chiffres : npm dépasse aujourd’hui 3,5 millions de paquets publiés. PyPI en compte plus de 550 000. Un projet Node.js moyen de taille modeste embarque entre 500 et 1 500 dépendances transitives — c’est-à-dire des paquets installés automatiquement parce qu’une dépendance directe en avait besoin. La grande majorité de ces paquets ne sont jamais lus par personne dans l’organisation qui les installe. C’est précisément dans cet angle mort que les attaquants opèrent.

L’incident que nous venons de traiter en analyse — 18 paquets npm ciblant les développeurs Alibaba avec un RAT multiplateforme — n’est pas exceptionnel. C’est représentatif d’une tendance lourde documentée depuis 2021, qui s’accélère et se sophistique en 2026. Selon les données de Socket et de l’équipe Palo Alto Unit 42, le nombre d’attaques supply chain npm/PyPI détectées a progressé de 165 % entre 2024 et 2025, et les premières données 2026 confirment la poursuite de cette trajectoire.

Ce qui a changé, c’est la qualité des attaques. On est passé de campagnes d’opportunisme grossières — des paquets nommement évidents — à des opérations ciblées, préparées sur des mois, avec des leurres quasi-indétectables et des techniques d’obfuscation dignes d’APT étatiques.

Les quatre vecteurs d’attaque que je rencontre le plus sur le terrain

1. La dependency confusion (confusion de dépendances)

C’est le vecteur théorisé par Alex Birsan dans son article fondateur de 2021, et c’est encore celui que je retrouve le plus souvent mal géré en mission. Le principe : votre organisation utilise un registre npm privé (Artifactory, Nexus, Azure Artifacts) pour héberger des paquets internes. Ces paquets ont des noms comme @monentreprise/utils ou, comme dans le cas Alibaba, @ali/config. Si le client npm de vos développeurs est configuré pour consulter le registre public AVANT le registre privé, et qu’un attaquant publie un paquet avec le même nom sur npm public, le client npm installera la version publique malveillante à la place de la version interne légitime.

La correction est simple dans son principe mais souvent mal implémentée : forcer la résolution des scopes internes vers le registre privé exclusivement via le fichier .npmrc, et configurer votre proxy de registre en mode blocage des scopes non whitelistés. En pratique, j’estime que 40 à 50 % des organisations ayant un registre npm privé ne l’ont pas correctement sécurisé contre ce vecteur. C’est une bombe à retardement.

2. Le typosquatting et le namespace squatting

Vous installez lodash, les 50 millions d’autres développeurs aussi. Quelqu’un publie lodas, 1odash, ou lodash-utils. Une faute de frappe, un copier-coller d’un tutoriel mal orthographié, et la machine de développement est compromise. C’est artisanal, mais ça marche. En 2025, l’équipe de recherche de Checkmarx a identifié plus de 7 200 paquets npm de typosquatting actifs en un seul mois.

Le namespace squatting est une variante plus sophistiquée : au lieu de squatter le nom exact, l’attaquant cible un namespace (@scope) correspondant à une organisation connue mais non revendiqué sur npm. C’est le cas Alibaba : le namespace @ali n’était pas officiellement revendiqué par Alibaba sur le registre public, ouvrant la voie à l’enregistrement de paquets se faisant passer pour des bibliothèques internes légitimes.

3. La compromission de compte mainteneur (account takeover)

C’est le vecteur le plus dévastateur. Au lieu d’inventer un nouveau paquet, l’attaquant prend le contrôle du compte d’un mainteneur légitime et publie une nouvelle version malveillante d’un paquet existant ayant des millions d’utilisateurs. L’incident axios de 2023 reste l’exemple canonique : une version malveillante d’axios (le client HTTP JavaScript le plus utilisé au monde, 330 millions de téléchargements hebdomadaires à l’époque) a brièvement exfiltré les variables d’environnement des machines l’installant.

En 2026, cette technique connaît une renaissance grâce aux credential stuffing automatisés alimentant des innombrables bases de données de mots de passe. npm a imposé la double authentification pour les mainteneurs de paquets critiques, mais la couverture reste partielle. Je recommande systématiquement à mes clients d’épingler les versions exactes de leurs dépendances dans les lock files ET de vérifier les hashes des paquets installés.

4. L’injection de malware dans les scripts d’installation

npm autorise les scripts preinstall, install et postinstall qui s’exécutent automatiquement lors de l’installation d’un paquet. Cette fonctionnalité légitime est détournée par les attaquants pour exécuter du code arbitraire dès le npm install. Dans le cas des 18 paquets Alibaba, c’est précisément via un script postinstall que le RAT s’est implanté. La bonne pratique — méconnue — est d’utiliser npm install --ignore-scripts pour désactiver ces scripts, ou d’auditer leur contenu avant installation via socket.dev.

Ce que les APT font vraiment de votre pipeline CI/CD

La distinction entre cybercriminel opportuniste et APT dans ce contexte est importante. Un cybercriminel opportuniste cherche à déployer un cryptomineur, à voler des credentials AWS et à passer à la cible suivante. Un APT a d’autres ambitions.

Ce que j’observe sur les incidents post-mortem auxquels j’ai été associé en réponse à incident : les APT qui utilisent la supply chain npm/PyPI comme vecteur d’accès initial visent généralement les postes de développement pour une raison très précise. Ces machines ont accès à des dépôts de code source (GitHub, GitLab, Bitbucket), à des secrets dans les variables d’environnement (tokens AWS, clés API, credentials base de données), à des environnements de staging, et parfois à des pipelines CI/CD qui déploient directement en production.

Compromettre un poste développeur via un paquet npm malveillant, c’est potentiellement obtenir les clés du royaume sans avoir à forcer un seul pare-feu. Le mouvement latéral depuis la machine de développement vers l’infrastructure cloud ou les dépôts de code peut se faire en quelques heures, en utilisant uniquement des credentials légitimes déjà présents sur la machine.

Le cas SolarWinds de 2020 a établi le modèle : compromission de la chaîne de build elle-même pour injecter du code malveillant dans un produit légitime distribué à des milliers de clients. Depuis, des incidents de moindre ampleur mais de même nature se répètent régulièrement. En 2025, un groupe APT lié à la Corée du Nord a utilisé des paquets npm pour cibler des développeurs de plateformes d’échange de cryptomonnaies, résultant en des vols de plusieurs dizaines de millions de dollars. En 2026, la campagne Alibaba s’inscrit dans la même logique d’espionnage industriel par la chaîne logicielle.

Les indicateurs que vous ne regardez pas

Lors de mes audits, je demande systématiquement aux équipes de sécurité si elles ont une visibilité sur les paquets installés par les développeurs. La réponse est presque toujours négative. Voici les indicateurs que personne ne surveille et qui permettraient de détecter ces attaques en temps réel.

Connexions réseau depuis le processus node ou python lors d’un npm/pip install. Un paquet légitime n’a aucune raison de faire des requêtes réseau vers des serveurs inconnus au moment de son installation. Si votre EDR capte des connexions sortantes depuis node.exe ou python.exe vers des IPs non répertoriées pendant une phase d’installation, c’est un signal fort. La plupart des EDR modernes peuvent générer des alertes sur ce pattern, mais il faut configurer la règle — elle n’est pas activée par défaut.

Variables d’environnement lues par des processus fils d’installation. Les scripts malveillants ciblent prioritairement les variables d’environnement (AWS_ACCESS_KEY_ID, GITHUB_TOKEN, DATABASE_URL). Certains EDR et outils de runtime security (Falco, auditd sur Linux) peuvent détecter cet accès anormal.

Création de fichiers dans des chemins inhabituels post-install. Un paquet qui crée des fichiers en dehors du répertoire node_modules, dans ~/.config, ~/.ssh, dans les dossiers système, ou qui modifie des scripts de démarrage shell (.bashrc, .zshrc) mérite investigation immédiate.

Nouvelles versions de paquets existants publiées en dehors des cycles normaux. Les outils comme socket.dev ou Dependabot peuvent alerter sur les nouvelles versions de vos dépendances. Un paquet qui n’avait pas bougé depuis 18 mois et qui sort soudainement 3 versions en une semaine devrait déclencher une revue manuelle avant mise à jour.

La défense concrète : ce qui marche vraiment

Je vais être direct : la plupart des listes de recommandations sur ce sujet sont soit trop vagues, soit trop théoriques. Voici ce que j’applique concrètement en mission avec mes clients.

Proxy de registre avec liste blanche. Déployez un proxy de registre npm/PyPI (Artifactory, Nexus, Azure Artifacts, JFrog Xray) et configurez-le pour ne laisser passer que les paquets explicitement approuvés. C’est radical mais efficace pour les environnements à haute sensibilité. Pour les environnements moins contraints, configurez a minima le blocage des paquets sans métadonnées (pas d’auteur, pas de README, pas de repository Git) — signaux forts de paquets malveillants.

Signature et épinglage des dépendances. Utilisez des lock files (package-lock.json, poetry.lock) et configurez CI/CD pour refuser les builds si le lock file a changé sans validation explicite. Ajoutez la vérification des hashes : npm supporte l’intégrité SHA-512 dans les lock files depuis la version 5. PyPI supporte le hash checking via pip install --require-hashes.

Sandboxing des installations. Exécutez les npm install dans des environnements isolés (containers Docker éphémères, VMs dédiées) qui n’ont pas accès aux secrets de production ni aux credentials cloud réels. Cette approche, plus contraignante pour le workflow de développement, élimine quasi-totalement le risque d’exfiltration de secrets via un script postinstall malveillant.

Scan SCA en CI/CD. Intégrez un outil de Software Composition Analysis (SCA) — socket.dev, Snyk Open Source, Mend ou FOSSA — dans votre pipeline CI/CD. Ces outils analysent non seulement les CVE connues dans vos dépendances, mais aussi les comportements suspects dans les scripts d’installation et les réputations des paquets (ancienneté, activité des mainteneurs, histoire des versions).

Politique de MFA pour les comptes mainteneurs internes. Si votre organisation publie des paquets internes sur npm ou PyPI, imposez la double authentification sur tous les comptes de publication et utilisez des tokens d’accès granulaires à durée de vie limitée pour la publication en CI/CD — jamais les credentials personnels d’un développeur.

Mon avis d’expert

La supply chain logicielle est devenue le talon d’Achille des organisations qui ont bien sécurisé leur périmètre réseau mais qui traitent leur pipeline de développement comme une zone de confiance absolue. J’entends régulièrement des RSSI me dire « nos développeurs, on leur fait confiance ». La question n’est pas de faire confiance aux développeurs — c’est de ne pas faire confiance à n’importe quel paquet qu’ils installent depuis internet. Ce n’est pas la même chose. La maturité sécurité en 2026, c’est traiter chaque npm install ou pip install comme un potentiel vecteur d’infection, avec les contrôles et la visibilité qui s’imposent.

Ce que les prochains 6 mois vont changer

Deux tendances vont accentuer cette menace dans les prochains mois. Premièrement, la prolifération des outils de développement IA — MCP servers, SDK d’agents, bibliothèques d’orchestration comme LangChain — crée une nouvelle surface d’attaque supply chain encore moins surveillée que npm/PyPI classique. Les équipes de sécurité n’ont pas encore intégré cette réalité dans leurs processus de gestion des dépendances.

Deuxièmement, l’accélération de la découverte de vulnérabilités par l’IA va augmenter le rythme des CVE publiées — 55 000 à 60 000 CVE attendues en 2026 selon les projections d’IBM et Proofpoint. La fenêtre entre publication d’un paquet vulnérable et son exploitation va se réduire. La supply chain logicielle ne sera pas épargnée par cette accélération.

La bonne nouvelle : les outils de défense progressent également. L’initiative Sigstore, désormais intégrée dans npm et PyPI, permet de vérifier cryptographiquement qu’un paquet a bien été publié depuis un pipeline CI/CD légitime et non depuis un compte compromis. Sa généralisation sera l’un des progrès les plus significatifs pour réduire le risque d’account takeover.

Conclusion

La supply chain logicielle n’est pas un problème de niche réservé aux Big Tech. C’est une menace qui touche toute organisation ayant une équipe de développement — c’est-à-dire pratiquement toutes les organisations en 2026. Les attaquants l’ont compris bien avant la majorité des équipes de sécurité. La réponse passe par trois choses concrètes : de la visibilité sur ce qui s’installe, des contrôles sur ce qui peut s’installer, et une isolation des environnements où l’installation se fait. Les trois ensemble forment une défense cohérente face à une menace qui ne va pas disparaître.

Besoin d’un regard expert sur votre sécurité ?

Discutons de votre contexte spécifique et de vos expositions supply chain.

Prendre contact