Paquets npm malveillants : détecter la compromission de la chaîne d'approvisionnement open source

Réponse courte : les paquets npm malveillants transforment le workflow de développement en vecteur d'intrusion. Le paquet a l'apparence d'une dépendance, mais son véritable objectif est souvent le vol d'identifiants sur les postes locaux et dans les systèmes CI/CD. La détection exige une revue des paquets, l'isolation des builds, une hygiène des secrets et une visibilité réseau.

npm est une chaîne d'approvisionnement logicielle immense. Les applications modernes tirent des centaines, voire des milliers de dépendances directes et transitives. Cette échelle est productive, mais elle offre aussi aux attaquants de nombreux endroits où se cacher. Un paquet malveillant n'a pas besoin d'exploiter votre application en production s'il peut s'exécuter au moment de l'installation sur un poste de développeur ou un runner de build.

Les attaques contre la chaîne d'approvisionnement open source sont devenues récurrentes parce que l'économie de l'attaque est favorable. Publier un paquet convaincant, compromettre un mainteneur ou exploiter la dependency confusion suffit à faire exécuter du code attaquant par le pipeline de build, avec accès aux secrets, au code source, aux jetons et aux identifiants de déploiement.

Pour les organisations qui utilisent JavaScript ou TypeScript, le risque lié aux paquets npm malveillants n'est pas un sujet de niche. C'est un risque central de la livraison logicielle.

Schémas d'attaque courants

Le typosquatting est le schéma le plus simple. Les attaquants publient des paquets dont le nom est proche de celui de bibliothèques populaires. Un développeur se trompe en tapant le nom, ou un tutoriel malveillant y fait référence. Le paquet s'installe et s'exécute.

La dependency confusion vise les organisations qui utilisent des noms de paquets internes. Si la résolution de dépendances privilégie les registres publics ou les versions publiques les plus élevées, un attaquant peut publier un paquet portant le même nom et amener les builds à le télécharger.

La compromission de mainteneur fait davantage de dégâts. Les attaquants récupèrent par phishing ou par vol les identifiants d'un mainteneur légitime, puis publient une version malveillante d'un paquet de confiance. Ce chemin bénéficie de la confiance existante et peut se propager rapidement.

L'abus des scripts d'installation est fréquent, car les paquets npm peuvent exécuter des scripts de cycle de vie comme preinstall, install et postinstall. Ces scripts peuvent inspecter l'environnement, lire des fichiers et émettre des requêtes réseau.

L'obfuscation dissimule les charges utiles. Les attaquants peuvent minifier ou encoder le code, répartir la logique entre plusieurs fichiers, ou retarder l'exécution pour échapper à une détection évidente.

Ce que cherchent les attaquants

La première cible, ce sont généralement les secrets :

• NPM_TOKEN.
• Jetons GitHub.
• Identifiants cloud.
• Fichiers .env.
• Clés SSH.
• Variables de CI.
• Jetons de registres de paquets.
• Identifiants de déploiement.
• Clés d'API d'IA.

Une fois dérobés, ces secrets peuvent permettre la compromission de dépôts, l'accès au plan de contrôle cloud, l'abus de publication de paquets et le LLMjacking.

Les attaquants peuvent aussi modifier les artefacts de build, injecter des portes dérobées ou collecter du code source. Même un accès en lecture seule peut exposer la logique métier, des vulnérabilités, des références clients et des noms d'infrastructures internes.

Détection avant l'installation

La revue des dépendances doit examiner le nom du paquet, l'historique de l'éditeur, l'ancienneté de la version, les liens vers le dépôt, les tendances de téléchargement, les mainteneurs, les scripts et les récents changements de propriété. Un paquet publié hier avec un nom proche d'une bibliothèque populaire mérite un examen approfondi.

Les scanners automatisés aident, mais la revue humaine compte pour les dépendances à haut risque. Surveillez :

• Les nouveaux paquets dont le nom ressemble à des paquets internes ou populaires.
• Les paquets sans dépôt, ou dont le dépôt ne correspond pas.
• Les changements de version majeure soudains sur un projet dormant.
• Les nouveaux mainteneurs ajoutés peu avant une publication.
• Les scripts de cycle de vie qui téléchargent du code distant.
• Le JavaScript obfusqué.
• Les appels réseau vers des domaines sans rapport.
• Le code qui lit des variables d'environnement ou des chemins d'identifiants.

Pour les paquets privés, configurez les registres avec soin. Les noms de paquets internes ne doivent se résoudre qu'à partir de registres internes de confiance.

Détection pendant le build

Les systèmes de build doivent partir du principe que les dépendances peuvent être hostiles. Exécutez les installations dans des environnements isolés, avec un minimum de secrets. N'exposez pas les identifiants de production à l'installation des dépendances. Désactivez les scripts de cycle de vie lorsque c'est possible, ou ne les autorisez que pour les paquets ayant été revus.

Contrôlez le trafic sortant des runners de build. Si npm install se connecte de façon inattendue à un domaine récemment enregistré ou à une IP suspecte, c'est un signal précieux. Beaucoup de paquets malveillants ont besoin d'un accès réseau sortant pour exfiltrer des secrets.

Journalisez le comportement d'installation des paquets, les connexions sortantes et les accès à l'environnement. Enrichissez les destinations distantes avec des données de réputation. isMalicious peut aider à identifier les domaines et les IP suspects contactés pendant les builds.

Playbook de réponse

Lorsqu'un paquet malveillant est découvert :

1. Le supprimer des manifestes et des lockfiles.
2. Identifier chaque projet, build et poste de développeur qui l'a installé.
3. Faire tourner les secrets disponibles au moment de l'installation.
4. Reconstruire les artefacts depuis des environnements sains.
5. Inspecter les logs réseau sortants des runners de build.
6. Rechercher les artefacts modifiés ou les fichiers inattendus.
7. Passer en revue les jetons de registre de paquets et l'historique de publication.
8. Prévenir les équipes concernées avec le nom exact du paquet et la plage de versions.

Considérez que tout secret accessible au processus d'installation peut être compromis. Faire tourner uniquement le jeton évident suffit rarement.

Contrôles de prévention

Utilisez des lockfiles et versionnez-les. Épinglez les versions. Faites transiter les dépendances par un registre privé ou un proxy capable d'appliquer une politique. Bloquez les paquets inconnus dans les builds de production tant qu'ils n'ont pas été revus.

Minimisez les secrets dans la CI. L'étape d'installation n'a pas besoin des identifiants de déploiement. Séparez les privilèges de build, de test, de publication et de déploiement.

Utilisez le secret scanning sur l'ensemble des dépôts et des logs de build. Si un paquet malveillant lit les variables d'environnement, le rayon d'impact est plus faible quand il y a moins de secrets présents.

Sensibilisez les développeurs au typosquatting et à la provenance des paquets. Une commande d'installation copiée depuis un blog inconnu peut être un vecteur d'attaque.

Pour un contexte plus large, lisez Les bases de la sécurité de la chaîne d'approvisionnement avec le SBOM et Détection des attaques sur la chaîne d'approvisionnement.

Politique de registre et de dépendances

Les organisations doivent définir la manière dont les paquets entrent dans l'environnement. Pour les builds de production, les dépendances doivent passer par un registre ou un proxy contrôlé, capable d'appliquer une politique, de mettre en cache les versions connues comme saines et de bloquer les paquets suspects. Télécharger directement depuis les registres publics à chaque build crée une exposition inutile.

Utilisez des listes blanches de paquets pour les services critiques. Cela ne signifie pas que chaque dépendance doit passer devant un comité, mais que les nouveaux paquets et les changements de version majeure doivent être visibles. Une petite dépendance nouvelle avec un large impact transitif mérite une revue avant d'entrer dans un build de production.

Les lockfiles sont importants parce qu'ils réduisent les surprises. Sans lockfiles, les builds peuvent résoudre des versions différentes au fil du temps. Avec des lockfiles, l'équipe peut examiner exactement ce qui a changé. Combinez les lockfiles avec des pull requests automatisées qui affichent les métadonnées du paquet, les changements de mainteneurs, les scripts d'installation et les avis de sécurité connus.

Les noms de paquets privés doivent être protégés. Configurez les scopes et les registres pour que les paquets internes ne puissent pas être confondus avec des paquets publics. Testez périodiquement des scénarios de dependency confusion en vérifiant que la résolution des paquets se comporte comme prévu.

Durcissement des runners de build

Les runners de build doivent être jetables. Un paquet malveillant qui s'exécute pendant l'installation ne doit pas persister sur une machine de longue durée qui traitera ensuite d'autres projets. Les runners éphémères simplifient le nettoyage et réduisent la contamination entre projets.

Les secrets doivent être introduits tard dans le pipeline. L'étape d'installation des dépendances ne doit pas recevoir d'identifiants de déploiement, de clés de signature ni de jetons cloud de production. Si un paquet vole les variables d'environnement pendant l'installation, il ne doit pas y avoir grand-chose à voler.

Contrôlez le trafic sortant. Beaucoup de paquets malveillants doivent appeler un serveur externe pour exfiltrer des données. Restreignez le trafic sortant des environnements de build et alertez sur les domaines inconnus. Si un trafic sortant large est nécessaire, journalisez les destinations DNS et HTTP afin de pouvoir cadrer les incidents.

Séparez les zones de confiance. Un build pour une pull request non fiable ne doit pas s'exécuter avec les mêmes permissions qu'un pipeline de release signé. Les contributions issues de forks, les builds de preview et les tests de mise à jour de dépendances doivent recevoir un minimum d'identifiants.

Contrôles sur les postes de développeurs

Les paquets malveillants s'exécutent aussi sur les portables. Les développeurs installent des outils, exécutent des exemples et testent des paquets localement. Une compromission locale peut permettre le vol de sessions de navigateur, de clés SSH, d'identifiants de CLI cloud et de jetons de paquets.

Utilisez des postes de développement managés pour les dépôts sensibles. Appliquez la détection sur endpoint, le contrôle des extensions de navigateur, le chiffrement de disque et, lorsque c'est pertinent, le secret scanning des fichiers locaux. Encouragez l'usage d'identifiants de développement à durée de vie courte plutôt que de clés permanentes dans les profils de shell.

La formation doit être concrète. Les développeurs savent que des dépendances peuvent être vulnérables ; ils ne pensent pas forcément à npm install comme à une exécution de code provenant d'un éditeur non fiable. Montrez des exemples de scripts d'installation, de typosquatting et de dependency confusion pour rendre le risque tangible.

Mesurer le risque sur la chaîne d'approvisionnement

Suivez le nombre de paquets comportant des scripts d'installation, les nouveaux paquets introduits chaque mois, les paquets sans lien vers un dépôt, les paquets avec un seul mainteneur, les dépendances plus anciennes que ce que la politique autorise, et les jobs de build au trafic sortant non restreint.

Suivez également les secrets disponibles pendant l'installation des dépendances. Moins il y a de secrets présents, plus le rayon d'impact est réduit lorsqu'un paquet malveillant arrive.

Scénario d'exercice sur table

Entraînez-vous sur un incident de paquet malveillant où une mise à jour de dépendance exécute un script postinstall, lit les variables d'environnement et les envoie vers un domaine suspect. L'équipe doit identifier les builds affectés, faire tourner les secrets exposés, supprimer la dépendance, reconstruire les artefacts et déterminer si des paquets publiés ont été modifiés.

L'exercice doit inclure l'enrichissement réseau. Si le domaine ou l'IP d'exfiltration est connu comme malveillant, l'urgence de la réponse augmente et la chasse doit s'étendre à d'autres projets.

Plan de durcissement en 30 jours

En semaine une, identifiez les paquets comportant des scripts de cycle de vie dans les dépôts critiques. Cela seul révèle souvent un risque insoupçonné. Vérifiez si ces scripts sont nécessaires et s'ils s'exécutent dans des environnements qui exposent des secrets.

En semaine deux, examinez l'exposition des secrets en CI. Séparez l'installation des dépendances des étapes de déploiement. Retirez les identifiants de production des étapes de build qui n'en ont pas besoin. Assurez-vous que les pull requests issues de forks ne peuvent pas accéder aux jetons sensibles.

En semaine trois, configurez les contrôles de registre. Imposez des registres privés à scope, bloquez les chemins de dependency confusion et faites transiter les builds de production par un proxy capable de journaliser et d'appliquer une politique de paquets.

En semaine quatre, ajoutez la supervision réseau des runners de build. Capturez les destinations DNS et HTTP sortantes pendant les installations. Enrichissez les destinations inconnues et alertez sur les infrastructures suspectes ou nouvellement observées.

Le point de vue de la sécurité produit

Les équipes applicatives doivent traiter les changements de dépendances comme des changements de code. Une mise à jour de paquet d'une seule ligne peut introduire des milliers de lignes de code nouveau, avec exécution au moment de l'installation. La revue doit prendre en compte la provenance du paquet, la confiance accordée au mainteneur, les dépendances transitives et le comportement au build.

Les équipes sécurité peuvent aider en rendant cette revue légère. Des commentaires automatisés sur les pull requests, affichant l'ancienneté du paquet, ses scripts, ses mainteneurs et les risques connus, sont plus utiles que le blocage systématique de chaque mise à jour assorti d'avertissements vagues.

Intégrité des releases

Après un incident de dépendance malveillante, reconstruire ne suffit pas si l'équipe ne peut pas prouver quels artefacts ont été produits à partir d'entrées saines. Utilisez des commits signés, des paquets signés, des attestations de provenance et des pratiques de builds reproductibles lorsque c'est réalisable. Ces contrôles aident à répondre à la question de savoir si une release a simplement été construite pendant la fenêtre d'exposition ou si elle a réellement été modifiée par du code attaquant.

Les jetons de publication de paquets méritent une protection particulière. Si une dépendance malveillante vole un jeton de registre, la compromission suivante peut viser vos clients à travers votre propre paquet. Séparez les identifiants de publication des secrets généraux de CI, exigez le MFA ou le trusted publishing lorsque c'est possible, et surveillez les publications de paquets inhabituelles.

Requêtes de threat hunting

Cherchez les runners de build qui se connectent à des domaines jamais vus auparavant, les processus qui lisent .npmrc, .env, des fichiers SSH, cloud ou de configuration de gestionnaire de paquets pendant l'installation, et les paquets qui lancent des commandes shell depuis des scripts de cycle de vie. Ces comportements ne prouvent pas toujours une intention malveillante, mais ce sont de solides candidats au triage.

Conservez ces observations avec le nom et la version du paquet, afin que de futurs incidents puissent être corrélés rapidement.

À retenir côté threat intelligence

Les paquets npm malveillants se trahissent souvent par leur infrastructure : domaines d'exfiltration, serveurs de callback, hébergement suspect et schémas d'attaque réutilisés. Les métadonnées du paquet comptent, mais c'est le comportement réseau qui boucle la boucle.

isMalicious aide à enrichir les domaines et les IP contactés par les postes de développeurs et les runners de CI. Lorsqu'une dépendance sort de l'écosystème attendu, le contexte de réputation peut transformer un log de build étrange en un incident précis.