Supply chain : npm, composer, pip, quand vos dépendances sont l'attaque

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 :

Scripts 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 :

Stratégie de défense en profondeur

Chez 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.