Supply Chain Attack
Quand une dépendance devient une attaque : les risques supply chain dans les registres open source (npm,…)
Les attaques de la chaîne d’approvisionnement (supply chain attacks) ciblent les dépendances logicielles qu’utilisent les développeurs. Plutôt que d’attaquer directement une application finale, les attaquants compromettent les bibliothèques tierces ou les registres de paquets (comme npm, utilisé dans l’écosystème Node.js).
Ce type d’attaque est en forte augmentation car il exploite la confiance implicite des développeurs dans l’écosystème open source.
Comment fonctionnent les attaques supply chain sur npm comme exemple ?
- Typosquatting
- L’attaquant publie un paquet dont le nom ressemble à un paquet légitime.
- Exemple : expresss (trois “s”) au lieu de express.
- Un développeur qui fait une faute de frappe peut installer le paquet piégé.
- Dependency confusion
- Technique où un attaquant publie une dépendance avec le même nom qu’un paquet interne utilisé par une entreprise.
- En l’absence d’une configuration stricte des registres, npm peut résoudre une dépendance interne vers un paquet public du même nom.
- Exploité par Alex Birsan en 2021 pour infiltrer des grandes entreprises (Apple, Microsoft, etc.).
- Compte compromis ou abandonné
- Si un mainteneur npm utilise un mot de passe faible ou réutilisé, son compte peut être piraté.
- L’attaquant pousse alors une version malveillante du paquet.
- Exemple : en 2018, le paquet event-stream a été compromis via une prise de contrôle du projet.
Ce type d’attaque peut avoir comme impact :
- Vol de données sensibles (exfiltration de tokens, mots de passe, clés SSH ou toute information utile).
- Injections de malwares dans les applications finales.
- Cryptojacking : minage de cryptomonnaies sur la machine des victimes.
- Propagation rapide : une fois publié sur npm, un paquet compromis peut toucher des milliers de projets.
2025 : attaque supply chain majeure sur le registre npm
En 2025, le registre npm a été victime d’une attaque supply chain de grande ampleur, marquante par l’impact potentiel sur l’écosystème JavaScript.
Les attaquants ont compromis le compte du mainteneur « qix » qui a confirmé avoir étévictime d’une campagne de phishing. En cliquant sur le lien, les victimes étaient redirigées vers une fausse page de connexion qui exfiltrait leurs identifiants vers une URL contrôlée par les attaquants.
Source : aikido.dev
Une fois les précieuses informations entre leurs mains, les cybercriminels ont pu accéder au compte du mainteneur et publier de nouvelles versions infectées de plusieurs packages NPM :
- chalk (5.6.1) – ~300M téléchargements / semaine
- debug (4.4.2) – ~350M
- ansi-styles (6.2.2) – ~370M
- strip-ansi (7.1.1) – ~260M
- supports-color (10.2.1) – ~280M
- ainsi que d’autres dépendances très répandues (color-convert, wrap-ansi, ansi-regex, color-string, etc.)
Au total, ces bibliothèques cumulent plusieurs milliards de téléchargements hebdomadaires, ce qui a rendu cette attaque particulièrement critique par son potentiel de propagation.
Le code malveillant injecté ciblait spécifiquement les portefeuilles de cryptomonnaies, en interceptant et redirigeant silencieusement les transactions initiées depuis des wallets tels que MetaMask ou Phantom vers des adresses contrôlées par les attaquants.
Cet incident illustre le risque systémique des attaques supply chain :
une compromission unique peut impacter des milliers de projets et des millions d’utilisateurs finaux, sans attaque directe des applications cibles.
Comment se protéger contre ce risque ?
La mise en place de mesures de protection doit s’envisager sous deux volets complémentaires :
- les bonnes pratiques individuelles des développeurs,
- les mesures organisationnelles et techniques au niveau de l’entreprise.
Pour les développeurs :
- Vérifier les noms exacts des paquets installés.
- Limiter l’usage de dépendances inutiles (principe de least dependency).
- Vérifier l’historique et l’activité des mainteneurs.
- Désactiver ou limiter l’exécution des scripts postinstall.
- Utiliser un lockfile (package-lock.json) pour figer les versions testées.
Pour les organisations :
- Mettre en place des miroirs internes de paquets et éviter le téléchargement direct depuis npm public.
- Déployer des solutions de Software Composition Analysis (SCA) pour détecter dépendances vulnérables.
- Former les développeurs à la sécurité de la supply chain.
- Mettre en place une veille cybersécurité
Les attaques supply chain, en particulier sur des registres comme npm, représentent aujourd’hui l’une des menaces majeures pour les développeurs et les entreprises.
La sécurité des applications ne se limite plus au code interne : elle dépend aussi de la vigilance sur les dépendances tierces.
Cela ne concerne pas uniquement npm, mais l’ensemble des registres de paquets open source comme PyPI (Python), RubyGems (Ruby), Packagist (PHP), Maven Central (Java), ou encore NuGet (.NET). Chaque écosystème est exposé aux mêmes risques : dépendances compromises, typosquatting, mainteneurs malveillants ou comptes compromis.
Face à ces menaces, une approche structurée et proactive de la sécurité des dépendances est devenue indispensable.
Chez ORNISEC, nous pouvons vous accompagner dans la sécurisation de votre chaîne d’approvisionnement logicielle, en vous accompagnant à mettre en place :
- des politiques de gestion des dépendances,
- des audits réguliers de vos composants,
- et des outils de Software Composition Analysis (SCA) adaptés à vos environnements.