La plupart des équipes de sécurité se contentent d'activer l'EDR et le proxy, puis passent à autre chose. Contre les logiciels malveillants de la chaîne d'approvisionnement, aucun de ces deux outils n'offre de protection efficace, car ils ont été conçus pour répondre à un autre type de problème.
Les logiciels malveillants traditionnels ont tendance à s'introduire subrepticement dans un système, tandis que ceux qui ciblent la chaîne d'approvisionnement y sont accueillis à bras ouverts. Le développeur exécute npm install, et le code malveillant s'exécute avec tous les droits nécessaires. Cette inversion rend ces deux outils inopérants dès leur conception.
Pourquoi les solutions EDR ne détectent pas tous les logiciels malveillants
EDR surveille les processus à la recherche de comportements suspects : appels système inhabituels, relations parent-enfant inattendues, signatures malveillantes connues. Il se demande : « Ce processus se comporte-t-il comme un logiciel malveillant ? »
Le problème, c'est que les logiciels malveillants de la chaîne logistique s'exécutent au sein d'environnements d'exécution fiables, en effectuant les mêmes tâches que ces derniers accomplissent quotidiennement. Un script post-installation qui lit les fichiers `.env` et envoie leur contenu via une requête POST à un pirate passe pour un outil de compilation récupérant des identifiants afin de déployer du code. Les deux sont node ou python la lecture de fichiers et l'envoi de requêtes HTTP. Les appels système et les appels réseau sont identiques. EDR ne dispose d'aucun élément permettant de déterminer si l'un est légitime et l'autre non.
En mars 2026, des pirates ont piraté le compte npm du responsable principal de la maintenance d'axios, un paquet enregistrant environ 100 millions de téléchargements hebdomadaires. Ils n'ont pas modifié le code source. Ils ont simplement ajouté une nouvelle dépendance dont la seule fonction était d'exécuter un script post-installation qui téléchargeait un RAT multiplateforme avant de s'effacer. Pour un moniteur de processus, cela était impossible à distinguer d'une installation npm normale. 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 module Python de l'écosystème Azure de Microsoft, ont été piratées. Le texte comptait environ dix lignes __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 consistait à extraire des identifiants d'AWS, d'Azure, de GCP, de Kubernetes et de Vault, puis à les propager vers d'autres instances via SSM et vers d'autres pods via kubectl exec, en utilisant les identifiants de la victime pour accéder à ses propres cloud . Sur les machines dont les paramètres régionaux étaient réglés sur Israël ou l'Iran, une exécution sur six lançait la commande « rm -rf /* ». Aucun binaire étranger, aucune destination suspecte. L'EDR ne dispose d'aucun modèle pour les cas où le paquet lui-même constitue la menace.
attaques de la chaîne d’approvisionnement ce niveau sont particulièrement dangereuses, car la charge malveillante se fond dans le comportement normal du système. Il n’y a aucune anomalie à détecter, car le but est justement de se fondre dans le bruit de fond, ou, dans ce cas précis, de devenir ce bruit de fond.
Pourquoi les mandataires passent à côté
Un serveur proxy situé sur le chemin du trafic peut intercepter les paquets en cours de téléchargement et les comparer à une liste de paquets connus pour être malveillants. En théorie, cela fonctionne. Le problème, c'est justement cette partie « sur le chemin du trafic ».
Les proxys distants et d'entreprise sont des contrôles optionnels sur les machines appartenant aux développeurs. Les développeurs travaillent depuis leur domicile, dans des cafés ou via le Wi-Fi d'un hôtel. Ils installent des outils qui contournent les paramètres de proxy du système. VS Code gère lui-même le téléchargement de ses extensions. npm, pip et cargo disposent de leurs propres clients HTTP. De nombreux outils en ligne de commande et environnements d'exécution de langages ignorent HTTP_PROXY à moins d'une configuration explicite. Et lorsqu'un outil cesse de fonctionner à cause du proxy, les développeurs désactivent ce dernier, corrigent le problème, puis oublient de le réactiver.
Ce genre de situation se produit tous les jours. Un développeur installe une extension VS Code compromise à 23 h depuis son ordinateur personnel. Un serveur d'intégration continue récupère une dépendance corrompue en dehors du périmètre du réseau de l'entreprise. Aucune de ces installations ne passe par le proxy. L'analyse ne s'exécute jamais. Le contrôle censé détecter le problème n'était tout simplement pas en place.
Ce qui fonctionne vraiment
Tant l'EDR que les proxys apportent des solutions concrètes aux menaces pour lesquelles ils ont été conçus et restent des outils précieux. Ils ne couvrent toutefois pas la surface d'attaque de la chaîne d'approvisionnement spécifique aux développeurs.
Cette interface nécessite un outil intégré à la machine elle-même, capable de comprendre le comportement des paquets lors de l'installation et toujours disponible, quelle que soit la configuration réseau. C'est précisément dans ce but que nous avons développé Aikido Protection. Découvrez dans cet article comment plusieurs entreprises utilisent Device Protection pour protéger les machines de leurs développeurs.
Si vous souhaitez avoir une vision plus complète de ce que les outils traditionnels de gestion des terminaux ne prennent pas en compte sur les machines des développeurs, cet article aborde la version MDM de ce problème.
