Supply chain : npm, composer, pip, quand vos dépendances sont l'attaque
> En bref : Les attaques supply chain via les gestionnaires de paquets : typosquatting, dependency confusion, compromission de mainteneurs, et comment s'en...
Votre code n'est qu'une fraction de votre application
Une application moderne contient 80 à 95% de code tiers via ses dépendances. Un projet Node.js typique installe des centaines de paquets transitifs. Chacun est un vecteur d'attaque potentiel. Les attaques supply chain ciblent ce maillon faible : plutôt que d'attaquer votre code, l'attaquant compromet une dépendance que vous installez volontairement.
Typosquatting
L'attaquant publie un paquet dont le nom ressemble à un paquet populaire : lodassh au lieu de lodash, reqeusts au lieu de requests. Une faute de frappe dans package.json ou requirements.txt installe le paquet malveillant.
Cas réels : en 2022, des paquets npm comme ua-parser-jss et colors-2 ont piégé des milliers de développeurs. En Python, python3-dateutil (avec un tiret supplémentaire) contenait du code malveillant.
Protection : vérifiez toujours le nom exact du paquet. Utilisez npm audit, pip-audit ou composer audit pour détecter les paquets suspects.
Dependency confusion
Votre organisation utilise un registre privé pour des paquets internes. L'attaquant publie un paquet avec le même nom sur le registre public (npmjs.com, PyPI) avec une version supérieure. Le gestionnaire de paquets résout vers la version publique plus récente.
Cas réel : en 2021, le chercheur Alex Birsan a démontré cette attaque contre Apple, Microsoft et d'autres en publiant des paquets sur npm avec les noms de leurs paquets internes.
Protection : configurez le scoping des paquets (@company/package sur npm), utilisez des namespaces sur PyPI, et configurez votre gestionnaire pour interdire la résolution vers le registre public pour les paquets internes.
Compromission de mainteneur
Un mainteneur légitime d'un paquet populaire est compromis (phishing, credential stuffing) ou vend son accès. Le paquet est mis à jour avec du code malveillant qui s'exécute à l'installation (postinstall sur npm) ou à l'import.
Cas réels :
event-stream (2018) : un nouveau mainteneur a ajouté une dépendance malveillante qui ciblait les portefeuilles Bitcoinxz-utils (2024) : un contributeur patient a gagné la confiance du mainteneur pendant deux ans avant d'introduire une backdoor dans la bibliothèque de compression utilisée par SSHua-parser-js (2021) : le compte npm du mainteneur a été compromis, le paquet (7M de téléchargements/semaine) a été mis à jour avec un cryptominerScripts d'installation
Les scripts preinstall et postinstall de npm s'exécutent avec les mêmes droits que l'utilisateur qui fait npm install. Un paquet malveillant peut exfiltrer des variables d'environnement (tokens CI/CD, clés API), modifier d'autres fichiers du projet, ou installer des backdoors.
Protection : utilisez --ignore-scripts pour les installations non fiables. Configurez .npmrc avec ignore-scripts=true et n'activez les scripts que pour les paquets qui en ont vraiment besoin.
Lockfiles et intégrité
Le package-lock.json, composer.lock ou poetry.lock garantit la reproductibilité des installations. Mais si le lockfile est modifié (par un PR malveillant ou par un compromis du registre), l'intégrité est perdue.
Protection :
npm ci (pas npm install) en CI/CD pour respecter strictement le lockfileintegrity dans package-lock.json)Stratégie de défense en profondeur
npm audit, pip-audit, composer audit dans votre CI/CDChez CleanIssue, nous analysons l'arbre de dépendances de vos applications lors de nos audits. Parlez-nous de votre revue externe pour évaluer votre exposition aux attaques supply chain.
À retenir
Vous éditez un logiciel RH, paie ou recrutement ? CleanIssue réalise des audits de sécurité pour SaaS RH en conditions réelles, sans accès au code. Pour une première lecture de votre exposition, commencez par une revue externe de votre application.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
Ver npm sur les packages de mailing : quand un client MCP « postmark » exfiltre discrètement vos emails transactionnels
Un package npm largement utilisé pour envoyer des emails transactionnels (confirmations de compte, factures, réinitialisations de mot de passe) est compromis avec une porte dérobée en une ligne qui met en copie cachée chaque email sortant vers un serveur contrôlé par l'attaquant. Des dizaines de SaaS RH et paie qui envoient des bulletins de salaire par email sont exposés sans le savoir.
RCE GitLab via Oj : une chaîne de corruption mémoire cachée dans un patch non-sécurité
Deux bugs de corruption mémoire dans Oj (parser JSON Ruby) permettent à tout utilisateur authentifié de lancer des commandes en tant que `git` sur les GitLab auto-hébergés <18.10.8 / <18.11.5 / <19.0.2, via des notebooks Jupyter forgés. Le correctif a été livré le 10 juin mais listé en bug fixes, pas en sécurité. PoC publié le 24 juillet.
JetBrains TeamCity : un contournement d'auth critique menant à la RCE sur votre serveur CI/CD
Une vulnérabilité critique de contournement d'authentification dans JetBrains TeamCity On-Premises pourrait être exploitée pour une exécution de code à distance sur le serveur CI/CD — donnant aux attaquants l'accès aux pipelines de build, aux identifiants de déploiement et au code source. Correctif disponible.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.