Sécuriser les dépendances JavaScript après la compromission d’axios
La compromission d’axios sur npm a rappelé une réalité que beaucoup d’équipes techniques sous-estiment encore : dans l’écosystème JavaScript, la surface d’attaque ne se limite pas au code applicatif. Elle s’étend à la chaîne d’approvisionnement, aux lockfiles, aux scripts d’installation et aux environnements CI/CD qui répliquent automatiquement les dépendances. Quand un package aussi omniprésent qu’Axios devient le vecteur d’une attaque, c’est tout le modèle de confiance autour de la distribution logicielle qui doit être réévalué.
Le cas est d’autant plus instructif qu’il ne s’agissait pas d’une faille classique dans le cœur du projet. Sonatype a souligné que la compromission a touché la distribution npm d’Axios sans modifier le code source principal, via une dépendance injectée et un script d’installation. Autrement dit, une bibliothèque peut rester « saine » dans son dépôt tout en étant compromise au moment de sa publication. Pour les organisations qui déploient, buildent ou packagent du JavaScript à grande échelle, ce type d’événement impose des mesures de contrôle plus strictes et plus systématiques.
Les faits connus sont clairs : deux versions malveillantes, axios@1.14.1 et axios@0.30.4, ont été publiées le 31 mars 2026 via un compte npm compromis. Selon les analyses de Datadog Security Labs et le post-mortem du mainteneur, elles sont restées en ligne environ trois heures, ce qui est court, mais suffisant pour infecter des postes de développement, des images Docker et des pipelines automatisés. Le package malveillant visait macOS, Windows et Linux, preuve qu’une chaîne d’attaque bien conçue ne se limite pas à un seul environnement.
Comprendre la mécanique de l’attaque
L’attaque observée autour d’Axios est emblématique d’un schéma désormais classique dans la sécurité des dépendances : introduire une dépendance fantôme pour déclencher un comportement malveillant au moment de l’installation. StepSecurity et le post-mortem GitHub indiquent que la charge ajoutait plain-crypto-js@4.2.1, une dépendance injectée, puis s’appuyait sur un script postinstall pour déposer un RAT multiplateforme. Ce détail est essentiel, car il montre que l’exploitation a lieu non pas à l’exécution de l’application, mais dès l’installation du package.
Dans ce type de scénario, le danger ne vient pas seulement d’un usage direct du package dans un projet de production. Il existe aussi dans les environnements de build, les machines de développeurs et les workflows d’automatisation qui exécutent des installations régulières. Une simple commande npm install, lancée sur un poste disposant de secrets locaux ou de droits d’accès à des services cloud, peut suffire à exposer des identifiants sensibles. C’est ce qui rend les attaques par supply chain particulièrement coûteuses à contenir après coup.
Le point le plus préoccupant est la rapidité de propagation potentielle. Même si la fenêtre d’exposition a été estimée à environ trois heures, ce laps de temps est largement suffisant dans un contexte de CI/CD où des dizaines, voire des centaines d’installations peuvent être déclenchées automatiquement. Une image de base contaminée, un cache de dépendances partagé ou un pipeline récurrent peuvent transformer un incident ponctuel en compromission diffuse. C’est pourquoi la détection doit porter autant sur les artefacts que sur les environnements ayant réalisé l’installation.
Pourquoi ce cas concerne toutes les équipes JavaScript
Le compromis d’Axios est particulièrement instructif parce qu’il touche une bibliothèque très connue, intégrée dans des milliers de projets. Cela démontre qu’un package populaire peut devenir un vecteur d’attaque sans qu’une vulnérabilité traditionnelle soit présente dans la logique métier des applications consommatrices. Pour les équipes produit, le message est clair : la sécurité d’une application dépend aussi de la fiabilité de sa chaîne de distribution logicielle.
Ce cas rappelle également qu’il faut éviter de confondre « code source sain » et « distribution compromise ». Une revue de code ou un audit du dépôt GitHub ne suffit pas si la publication sur npm peut être détournée. La surface d’attaque inclut alors les comptes de publication, les jetons d’accès, les permissions du registre, les scripts de build et les dépendances transitivement introduites. Dans un environnement moderne, la confiance se construit à plusieurs niveaux, pas seulement au niveau du repository.
Il faut aussi replacer cet incident dans le contexte de sécurité antérieur d’Axios. En mars 2025, GitHub Advisory Database avait déjà signalé une vulnérabilité SSRF et fuite d’identifiants touchant plusieurs versions. Un autre avis de 2025, lié à une dépendance transitive form-data, a ensuite été retiré, illustrant qu’une correction peut se jouer à la source sans toucher directement Axios. Le changement de version vers v1.15.0, publié le 7 avril 2026 avec un correctif dans formidable, montre enfin que le durcissement d’une dépendance est un processus continu, pas un événement unique.
Mesures immédiates à prendre après l’incident
La première action opérationnelle consiste à vérifier les lockfiles. Le mainteneur Axios recommande explicitement de rechercher axios@(1.14.1|0.30.4) et plain-crypto-js dans package-lock.json et yarn.lock. Cette étape permet d’identifier rapidement si une version compromise a été résolue dans l’arbre de dépendances du projet. Elle doit être menée sur les dépôts applicatifs, mais aussi sur les images de build, les monorepos et les modèles de projet réutilisés par plusieurs équipes.
La deuxième étape est d’invalider l’hypothèse de confiance sur les machines ayant exécuté l’installation malveillante. StepSecurity recommande de considérer les secrets présents sur ces machines comme potentiellement compromis. Cela inclut les jetons npm, les clés AWS, les clés SSH et les secrets CI/CD. En pratique, cela veut dire rotation immédiate des identifiants, révocation des tokens, et vérification des accès latéraux possibles à des dépôts, buckets ou environnements de déploiement.
Enfin, il faut reconstruire les environnements sensibles depuis des bases propres. Les analyses de Microsoft, Wiz, SANS et Datadog convergent sur ce point : si un poste ou un runner a exécuté une dépendance compromise, il faut repartir d’une image saine plutôt que tenter un nettoyage partiel. Cette approche est plus coûteuse à court terme, mais elle réduit drastiquement le risque de persistance d’un trojan ou d’une exfiltration différée.
Durcir la chaîne de build et de déploiement
Dans les environnements CI, la mesure la plus défensive reste l’usage de npm ci plutôt que npm install. La documentation npm précise que npm ci exige un lockfile existant, refuse les incohérences avec package.json et n’écrit pas dans les fichiers de lock. Cela limite la dérive d’approvisionnement, garantit une installation reproductible et réduit les surprises lors des builds automatisés. Pour les équipes qui cherchent à standardiser leurs pipelines, c’est souvent le meilleur point de départ.
Le second levier est de bloquer les scripts d’installation lorsqu’ils ne sont pas indispensables. L’option ignore-scripts documentée par npm empêche l’exécution des scripts définis dans package.json, notamment postinstall. Dans un contexte où la plupart des packages n’ont pas besoin de scripts à l’installation, cette mesure réduit considérablement la surface d’attaque. Elle n’élimine pas tous les risques, mais elle neutralise précisément le mécanisme utilisé dans le cas Axios.
Il est également pertinent de séparer les contextes de confiance. Un environnement de build destiné à produire des artefacts ne devrait pas détenir les mêmes secrets qu’un poste d’administration ou qu’une machine de développement personnelle. Plus on limite les privilèges et les identifiants exposés pendant l’installation, plus on réduit l’impact d’un package compromis. C’est une logique de moindre privilège qui doit s’appliquer aux dépendances autant qu’aux accès humains.
Mettre en place une surveillance continue des dépendances
La sécurité des dépendances JavaScript ne peut pas reposer uniquement sur des réactions post-incident. Elle doit intégrer une surveillance continue des mises à jour, des advisories et des changements de comportement dans la chaîne de publication. GitHub recommande Dependabot pour suivre les mises à jour npm à intervalle quotidien ou hebdomadaire selon la configuration, ce qui permet de réduire le temps entre la découverte d’un correctif et son intégration effective.
Cette automatisation devient encore plus utile lorsqu’elle est couplée à des politiques d’acceptation précises. Par exemple, une équipe peut exiger qu’un changement de version soit accompagné d’une vérification de lockfile, d’un scan de vulnérabilités et d’un contrôle des scripts d’installation. Cette approche permet de traiter la mise à jour de dépendance comme un changement de sécurité à part entière, et non comme une simple maintenance technique.
Il faut aussi surveiller les connexions sortantes lors des installations et des builds. Un postinstall malveillant a souvent besoin de contacter un serveur externe pour exfiltrer des données ou télécharger une charge utile. Détecter des comportements réseau anormaux pendant l’installation peut fournir un signal d’alerte précieux, surtout dans les environnements de CI où les accès sortants devraient être plus prévisibles. Cette surveillance, combinée aux alertes de registre et aux diffs de lockfiles, augmente fortement la capacité de détection précoce.
Vers une stratégie durable de sécurisation
Pour les organisations qui veulent réellement sécuriser leurs dépendances JavaScript après la compromission d’axios, le trio le plus défensif est simple : lockfiles figés, npm ci, et ignore-scripts par défaut dans les environnements où les scripts d’installation ne sont pas indispensables. Cette combinaison ne garantit pas une immunité totale, mais elle impose un cadre de reproduction, réduit les écarts entre les environnements et bloque un vecteur d’attaque majeur.
À ce socle, il faut ajouter une gouvernance claire des secrets, des renouvellements automatiques, des audits de dépendances et une politique de rebuild depuis des images propres dès qu’un incident touche le pipeline. Dans une logique produit, cela doit être intégré au cycle de livraison, avec des tâches explicites de remédiation et des critères de sortie. La sécurité de la supply chain ne peut plus être traitée comme une optimisation secondaire.
Le cas Axios rappelle enfin qu’un incident sur une bibliothèque largement utilisée peut survenir même sans faille visible dans le code applicatif. Pour les équipes techniques, c’est un signal fort : la maturité en sécurité JavaScript ne se mesure plus seulement à la qualité du code, mais à la robustesse des processus qui l’installent, le verrouillent et le distribuent. C’est à ce niveau que se joue aujourd’hui une grande partie de la résilience logicielle.
Chez Hurter & Co, nous voyons cette évolution comme une opportunité de moderniser les pratiques de livraison logicielle autant que les produits eux-mêmes. Sécuriser les dépendances, c’est protéger les équipes, les clients et les environnements d’exploitation. C’est aussi construire une chaîne de confiance capable de résister à des attaques de plus en plus industrielles.
