Ces derniers jours, le NCSC a signalé plusieurs attaques de supply chain ciblant des bibliothèques publiées sur npm et liées à l’écosystème Python. L’objectif : faire circuler des versions malveillantes qui peuvent, une fois installées, ouvrir la porte à des environnements d’IT et à des données d’authentification.
Si votre organisation développe des logiciels et s’appuie sur des dépendances tierces, l’alerte mérite votre attention. Les packages npm et Python compromis peuvent permettre aux attaquants d’atteindre vos systèmes de développement, puis de pivoter vers d’autres éléments de votre réseau—voire d’affecter vos utilisateurs finaux.
Pourquoi ces attaques sont particulièrement dangereuses
npm est un gestionnaire de paquets utilisé pour développer des applications en Node.js. Dans le même esprit, l’écosystème Python s’appuie sur des bibliothèques distribuées via des paquets. Dans les deux cas, des attaquants peuvent profiter d’un scénario simple : une version “légitime” est mise à jour, puis téléchargée et installée par votre pipeline.
Le résultat n’est pas uniquement un composant compromis. D’après l’alerte du NCSC, l’attaque vise notamment à obtenir des informations d’authentification. Une fois ces identifiants entre les mains de l’attaquant, celui-ci peut accéder à d’autres environnements de développement et systèmes internes, et potentiellement exfiltrer des données.
Attaque contre un scanner : Trivy et des capacités d’accès à distance
Le 19 mars, des acteurs malveillants auraient obtenu un accès non autorisé à l’environnement de développement de Trivy, un scanner de sécurité largement utilisé (notamment avec des environnements liés à des applications Node.js). Une version malveillante de Trivy aurait ensuite été distribuée.
Selon les informations rapportées, cette version modifiée a été associée à la récupération de données d’authentification jugées sensibles. L’alerte mentionne également la présence de mécanismes permettant d’exécuter des commandes à distance sur des systèmes compromis.
À partir de cette première compromission, des éléments malveillants auraient ensuite contribué à la propagation de logiciels malveillants : une logique d’exfiltration des identifiants puis de tentative de compromission d’autres paquets npm et PyPI.
Exemples de paquets touchés selon les informations disponibles
L’alerte évoque, via une source de sécurité citée, qu’au moins 47 paquets npm auraient été compromis de cette manière. Le nombre réel pourrait être nettement plus élevé.
En parallèle, des versions liées à des bibliothèques Python telles que LiteLLM et Telnyx seraient aussi concernées, toujours selon les informations mentionnées dans l’alerte.
Compromission d’axios : une bibliothèque HTTP très utilisée
Indépendamment de l’incident autour de Trivy, l’alerte indique qu’en date du 30 mars, la compromission du paquet axios sur npm a été rendue publique.
axios est une bibliothèque populaire qui permet aux applications de communiquer via HTTP avec d’autres systèmes. Dans ce scénario, l’attaque reposerait sur l’ajout de malwares au sein d’un paquet reconnu, ensuite diffusé sous forme de mise à jour.
Concrètement, l’alerte précise des versions d’axios à surveiller : 1.14.1 et 0.30.4.
Quel est le risque pour votre organisation et vos utilisateurs
Le cœur du risque, dans le cas de packages npm et Python compromis, tient au chemin d’attaque. Si votre logiciel installe un paquet compromis, l’attaquant peut récupérer des identifiants, puis exploiter ces accès pour atteindre :
- des environnements de développement et autres systèmes internes ;
- des composants liés au réseau de votre organisation ;
- des éléments pouvant mener à des actions sur des systèmes d’utilisateurs finaux.
Le NCSC mentionne aussi des indications d’utilisation des accès obtenus pour exfiltrer des données, ce qui peut ouvrir la voie à des scénarios d’extorsion. L’alerte cite la possibilité de menaces consistant à publier des données si une rançon n’est pas payée. Elle évoque également la revente de données à d’autres cybercriminels.
Enfin, cette méthode d’attaque—viser des bibliothèques externes pour voler des informations d’authentification—est décrite comme une technique régulièrement employée par les attaquants.
Vérifier si votre environnement est compromis
Le NCSC recommande d’abord de déterminer si vos environnements d’exécution et de build ont pu installer des versions concernées.
Contrôle ciblé des packages mentionnés
L’alerte propose de vérifier la présence de paquets précis dans votre environnement de développement :
- Trivy : version 0.69.4
- axios : versions 1.14.1 et 0.30.4
La présence de ces éléments peut indiquer une compromission.
Contrôle plus large via les indicateurs de compromission
Important : même si vous ne voyez pas ces paquets, l’attaque peut avoir franchi la chaîne via une autre dépendance également compromis. Le NCSC recommande donc de rechercher des indicateurs de compromission (IOC) partagés par des acteurs de sécurité cités dans l’alerte.
Si des IOC sont identifiés, cela doit être traité comme un signal de compromission possible, nécessitant une analyse et une réponse adaptées.
Que faire si vous avez des indices de compromission
Si vos contrôles font ressortir des signes plausibles, le NCSC conseille de passer rapidement à l’action.
- Démarrez votre processus d’intervention (IR) : lancez les étapes internes prévues et, si besoin, sollicitez un prestataire spécialisé afin d’évaluer l’étendue et l’impact.
- Rotez les identifiants : révoquez et remplacez tous les tokens, credentials et informations d’authentification auxquels un attaquant aurait pu accéder.
- Informez vos clients si nécessaire : si votre logiciel est concerné, vos clients doivent pouvoir appliquer les mesures de protection appropriées.
Dans une situation de supply chain, agir tôt est essentiel : les attaquants cherchent souvent à exploiter les accès avant qu’ils ne soient corrigés.
Prévenir à l’avenir les attaques via des dépendances
Au-delà de la réaction, l’alerte met l’accent sur des pratiques visant à réduire la surface d’attaque. L’idée : limiter la probabilité de télécharger une version malveillante, réduire l’impact d’une mise à jour compromise et améliorer la détection dans vos pipelines.
Limiter le risque de téléchargement de versions modifiées
- Utilisez le “version pinning” : lorsque votre logiciel s’appuie sur des bibliothèques externes, figez les versions autant que possible. L’alerte recommande, si cela est envisageable, de pinner des empreintes (hash) plutôt que des numéros de versions.
- Appliquez une période de “cooldown” pour les dépendances : déployez rapidement les mises à jour de sécurité critiques, mais conservez une courte fenêtre d’attente pour les mises à jour plus courantes quand c’est possible.
- Désactivez les post-install scripts quand c’est applicable : par exemple, en utilisant l’option –ignore-scripts avec npm ci.
Renforcer la détection dans les CI/CD
Les pipelines sont souvent l’endroit où les paquets sont installés et mis à jour. Le NCSC recommande donc :
- de scanner vos environnements CI/CD pour repérer des mises à jour et paquets suspects ;
- d’utiliser des pratiques de contrôle sur la provenance des bibliothèques.
Choisir des sources de confiance et vérifier l’authenticité
Pour réduire le risque d’introduction de dépendances compromises, l’alerte recommande :
- de n’utiliser que des paquets provenant d’éditeurs approuvés (trusted publishers) ;
- d’utiliser la commande npm audit pour aider à évaluer l’authenticité et l’exposition aux problèmes connus.
Enfin, l’alerte mentionne une mesure importante pour les processus de publication : mettre en œuvre npm Trusted Publishing via OpenID Connect (OIDC) plutôt qu’un NPM_TOKEN fixe de longue durée. L’objectif est de limiter le risque lié à la compromission et à l’usage abusif d’un token persistant.
Rester vigilant : une menace qui évolue
Les campagnes décrites montrent un schéma récurrent : compromettre des bibliothèques distribuées largement, puis étendre l’impact en profitant de la confiance accordée aux mises à jour. Pour limiter les dégâts, la combinaison contrôle, réponse rapide et durcissement des pipelines fait la différence.
Si votre équipe développe avec npm et Python, commencez par vérifier les versions mentionnées dans l’alerte, puis élargissez la recherche via les IOC. Ensuite, consolidez vos pratiques (pinnings, scans CI/CD, contrôle des scripts) afin d’abaisser la probabilité qu’une nouvelle variante de packages npm et Python compromis atteigne vos environnements.
Conclusion : l’alerte du NCSC rappelle que la sécurité de la supply chain ne se traite pas uniquement au moment d’un incident. En agissant dès maintenant sur la détection et la prévention, vous réduisez le risque d’accès non autorisé, d’exfiltration de données et d’impact sur vos clients.
Source: https://www.ncsc.nl/alerts/ontwikkelaars-opgelet-gecompromitteerde-npm-en-python-packages
