Et si le code que vous utilisez chaque jour était devenu un cheval de Troie ? 

C’est la question que se posent actuellement de nombreuses équipes techniques, après la récente attaque ciblant la chaîne d’approvisionnement via NPM. Chez INOCO, ce sujet a fait l’objet d’un café-débat interne entre collègues ☕️

Plus qu’un simple partage d’actualité, c’était l’occasion de faire ce qu’on aime : échanger à chaud, décortiquer les implications sur le terrain, et partager des bonnes pratiques. Voilà ce qu’on en a tiré 👇

Le problème : un code malveillant infiltré dans l’écosystème NPM 

Cette attaque, la troisième du genre en moins d’un an, repose sur un mécanisme bien huilé : un code malicieux 🥷 injecté dans des packages open-source. Téléchargé depuis GitHub ou NPM, il s’exécute à l’insu de l’utilisateur lors du build, souvent au sein des pipelines CI/CD.

Conséquence ? Une fuite potentielle de mot de passe, de tokens, voire la prise de contrôle de certaines briques techniques sensibles.
Le script va créer des fichiers JSON contenant des informations confidentielles et les exfiltrer vers des dépôts contrôlés par des acteurs malveillants.

Pourquoi c’est un vrai sujet :

Parce que ce n’est pas une attaque spectaculaire, mais sournoise - comme on aime le dire 🦹 - et parce que personne n’est vraiment à l’abri : qu’on soit développeur front en Angular, backend, Java ou DevOps, l’usage de NPM est massif, souvent indirect.

Comme expliqué par Thomas, les malfaiteurs se glissent discrètement en exploitant des dépendances en cascade.

Une grosse librairie utilise plein de sous-librairies, qui elles-mêmes utilisent d’autres librairies. Alors l’attaquant cible une toute petite librairie très simple, mais utilisée partout et intégrée dans d’autres packages très populaires.

Et ainsi de suite, l'automatisation devient un facteur de propagation. Ce qui est censé nous sécuriser et faciliter la vie devient un canal d’attaque, outch 🥴.
À chaque mise à jour automatique d’un package, à chaque hotfix de sécurité appliqué on risque d’intégrer un code hostile.

Sur le terrain : comment on réagirait si ça nous tombait dessus 👇

1. Avertir tous les développeurs d’une attaque en cours

   En gardant en tête que tout ce qui utilise Node.js est potentiellement impacté par des packages contaminés.

   
   

2. Identifier la menace

   • Recenser les packages impactés utilisés entre les dates critiques.
     Les alertes sont généralement émises par des organismes comme le CERT et des modérateurs sur GitHub.
     
     

   • Vérifier quelles versions sont concernées.
     
     

3. Stopper l’hémorragie

   • Arrêter les échanges vers l'extérieur en cas de suspicion d'infection.
     
     

   • Isoler les pipelines CI/CD pour bloquer tout flux sortant.
     
     

   • Désactiver temporairement l’accès à certains dépôts.
     
     

4. Nettoyer et reconstruire

   • Révoquer tous les secrets techniques (mots de passe, tokens, clés d’accès).
     
     

   • Réinstaller proprement les dépendances en forçant les versions connues comme saines.
     
     

Comment se protéger des attaques de NPM ?

Mieux vaut prévenir que guérir ! Même si on peut difficilement éliminer tous les risques.

Les bonnes pratiques générales pour limiter les attaques et s’y préparer :

• Mettre en place un registre privé : ne pas dépendre directement de NPM ou d'autres registres publics.
  
  

• Renforcer l’usage d’un artefact privé ou d’un proxy d’entreprise (type Artifactory) pour éviter de tirer en direct depuis le registre NPM.
  
  

• Isoler les pipelines "sous cloche" afin qu’elle ne puisse pas contacter l’extérieur, bloquant l’exfiltration.
  
  

• Évitez de paramétrer votre "package.json" en utilisant "latest" ou "*" (ce qui est déconseillé de base).
  
  

• Créer des scripts de remédiation (clean, rebuild, rollback) pour corriger rapidement et sécuriser tout l’écosystème.

La reco de notre collègue François 👇

Pour limiter le risque sur une chaîne CI/CD - ou même sur un poste de développeur - un "npm ci" (clean install), empêchera les mises à jour automatiques des packages grâce au fichier "lock".
Selon comment est configuré votre "package.json", cela retire le côté pratique pour la mise à jour automatique des versions, mais ça assure que tous les environnements/postes utilisent les mêmes versions des packages.

En conclusion : 

Au-delà des outils, nous pensons que la clé reste une meilleure compréhension des mécanismes d’attaque, et la coopération des équipes 🤝 C’est en partageant les bonnes pratiques et les alertes que l’on réduit collectivement la surface d’exposition.