La plupart des équipes de sécurité cochent la case EDR, cochent la case proxy et passent à autre chose. Contre les malwares de la chaîne d'approvisionnement, aucun des deux n'offre une protection significative, car ils ont été conçus pour un problème différent.
Les malwares traditionnels ont un moyen de s'introduire furtivement sur une machine, tandis que les malwares de la chaîne d'approvisionnement sont invités. Le développeur exécute npm install, et le code malveillant atterrit avec toutes les autorisations d'exécution. Cette inversion rend les deux outils inopérants au niveau de la conception.
Pourquoi l'EDR ne détecte pas les malwares
L'EDR surveille les processus à la recherche de comportements suspects : appels système inhabituels, relations parent-enfant inattendues, signatures malveillantes connues. Il demande : « Ce processus agit-il comme un malware ? »
Le problème est que les malwares de la chaîne d'approvisionnement s'exécutent au sein de runtimes de confiance, faisant des choses que ces runtimes font toute la journée. Un script post-installation qui lit les fichiers `.env` et envoie (POST) le contenu à un attaquant ressemble à un outil de build qui récupère des identifiants pour déployer du code. Les deux sont node ou python lisant des fichiers et effectuant des appels HTTP. Les appels système et les appels réseau sont les mêmes. L'EDR n'a aucun contexte pour savoir si l'un est légitime et l'autre non.
En mars 2026, des attaquants ont piraté le compte npm du principal mainteneur d'axios, un package avec environ 100 millions de téléchargements hebdomadaires. Ils n'ont pas touché au code source. Ils ont ajouté une nouvelle dépendance dont le seul rôle était un script post-installation qui téléchargeait un RAT multiplateforme et s'auto-supprimait. Pour un moniteur de processus, cela était indiscernable d'un `npm install` faisant son travail. Il résout une dépendance, exécute un hook et effectue une requête HTTP.
Deux mois plus tard, trois versions de durabletask, un package Python de l'écosystème Azure de Microsoft, ont été piégées par une backdoor. L'injection représentait une dizaine de lignes dans __init__.py. Le code récupère un fichier et l'exécute dans un sous-processus, en ignorant les exceptions. La deuxième étape a collecté des identifiants d'AWS, Azure, GCP, Kubernetes et Vault, puis s'est propagée à d'autres instances via SSM et à d'autres pods via kubectl exec, en utilisant les propres identifiants de la victime, et en atteignant les propres API cloud de la victime. Sur les hôtes avec des paramètres régionaux israéliens ou iraniens, une chance sur six exécutait rm -rf \/*. Pas de binaire étranger, pas de destination anormale. L'EDR n'a pas de modèle pour le cas où le package lui-même constitue la menace.
Les attaques de la chaîne d’approvisionnement à cette couche sont si dangereuses car la charge utile malveillante est un comportement normal. Il n'y a pas d'anomalie à détecter, car tout l'intérêt est de se fondre dans le bruit, ou dans ce cas, d'être le bruit.
Pourquoi les proxys ne le détectent pas
Un proxy dans le chemin du trafic peut intercepter les téléchargements de packages et les vérifier par rapport aux packages malveillants connus. Cela fonctionne, en théorie. Le problème réside dans la partie « dans le chemin du trafic ».
Les proxys distants et d'entreprise sont des contrôles à activation volontaire sur les machines que les développeurs possèdent. Les développeurs travaillent depuis chez eux, des cafés, ou via le Wi-Fi des hôtels. Ils installent des outils qui contournent les paramètres de proxy système. VS Code gère ses propres téléchargements d'extensions. npm, pip et cargo ont leurs propres clients HTTP. De nombreux outils CLI et runtimes de langage ignorent HTTP_PROXY entièrement, sauf configuration explicite. Et lorsqu'un outil ne fonctionne plus à cause du proxy, les développeurs désactivent le proxy, réparent l'outil et oublient de le réactiver.
Des cas comme ceux-ci se produisent tous les jours. Un développeur installe une extension VS Code compromise à 23h depuis sa machine personnelle. Un runner CI télécharge une dépendance empoisonnée en dehors du périmètre du réseau d'entreprise. Aucune de ces installations ne passe par le proxy. Le scan ne s'exécute jamais. La vérification censée le détecter n'était tout simplement pas présente.
Ce qui fonctionne réellement
L'EDR et les proxys résolvent de vrais problèmes pour les menaces pour lesquelles ils ont été conçus et restent précieux. Ils ne couvrent simplement pas la surface d'attaque de la chaîne d'approvisionnement spécifique aux développeurs.
Cette surface nécessite quelque chose qui réside sur la machine elle-même, comprend ce que font les packages au moment de l'installation, et est toujours présent quelle que soit la configuration réseau. Nous avons conçu Aikido Device Protection pour faire exactement cela. Découvrez comment plusieurs organisations utilisent Device Protection pour protéger les machines des développeurs dans ce blog.
Si vous voulez une vue plus complète de ce que les outils de sécurité traditionnels des endpoints ne détectent pas sur les machines des développeurs, la version MDM de ce problème est abordée dans cet article.
