La mayoría de los equipos de seguridad marcan la casilla EDR, marcan la casilla del proxy y siguen adelante. Frente al malware de la cadena de suministro, ninguna de estas soluciones proporciona una protección significativa, ya que fueron diseñadas para un problema diferente.
El malware tradicional encuentra la manera de colarse en una máquina, mientras que el malware de la cadena de suministro es invitado. El desarrollador ejecuta npm install, y el código malicioso se instala con plenos permisos de ejecución. Esa inversión invalida ambas herramientas a nivel de diseño.
Por qué EDR no detecta el malware
EDR monitoriza los procesos en busca de comportamientos sospechosos: llamadas al sistema inusuales, relaciones padre-hijo inesperadas, firmas maliciosas conocidas. Se pregunta: "¿Este proceso se está comportando como malware?"
El problema es que el malware de la cadena de suministro se ejecuta dentro de entornos de ejecución de confianza, haciendo cosas que esos entornos de ejecución hacen a diario. Un script de post-instalación que lee archivos `.env` y envía su contenido a un atacante parece idéntico a una herramienta de compilación que obtiene credenciales para desplegar código. Ambos están node o python leyendo archivos y realizando llamadas HTTP. Las llamadas al sistema y las llamadas de red son las mismas. EDR no tiene contexto para saber si uno es legítimo y el otro no.
En marzo de 2026, atacantes secuestraron la cuenta de npm del mantenedor principal de axios, un paquete con ~100 millones de descargas semanales. No tocaron el código fuente. Añadieron una nueva dependencia cuyo único trabajo era un script de post-instalación que descargaba un RAT multiplataforma y se eliminaba a sí mismo. Para un monitor de procesos, esto era indistinguible de npm install haciendo su trabajo. Resuelve una dependencia, ejecuta un hook y realiza una solicitud HTTP.
Dos meses después, tres versiones de durabletask, un paquete de Python en el ecosistema Azure de Microsoft, fueron comprometidas con una puerta trasera. La inyección era de unas diez líneas en __init__.py. El código obtiene un archivo y lo ejecuta en un subproceso, ignorando las excepciones. La segunda etapa recolectó credenciales de AWS, Azure, GCP, Kubernetes y Vault, luego se propagó a otras instancias a través de SSM y a otros pods mediante kubectl exec, utilizando las propias credenciales de la víctima, accediendo a las propias APIs cloud de la víctima. En hosts con configuraciones regionales israelíes o iraníes, una de cada seis veces ejecutaba rm -rf /*. Ningún binario externo, ningún destino anómalo. EDR no tiene un modelo para el caso en que el propio paquete sea la amenaza.
Los ataques a la cadena de suministro en esta capa son tan peligrosos porque la carga útil maliciosa es un comportamiento normal. No hay anomalía que detectar, porque el objetivo es mimetizarse con el ruido, o en este caso, ser el ruido.
Por qué los proxies no lo detectan
Un proxy en la ruta del tráfico puede interceptar las descargas de paquetes y compararlas con paquetes conocidos como maliciosos. Eso funciona, en teoría. El problema es la parte de "en la ruta del tráfico".
Los proxies remotos y corporativos son controles opcionales en las máquinas de los desarrolladores. Los desarrolladores trabajan desde casa, desde cafeterías, desde el wi-fi de hoteles. Instalan herramientas que omiten la configuración del proxy del sistema. VS Code gestiona sus propias descargas de extensiones. npm, pip y cargo tienen sus propios clientes HTTP. Muchas herramientas CLI y entornos de ejecución de lenguajes ignoran HTTP_PROXY por completo a menos que se configuren explícitamente. Y cuando una herramienta falla debido al proxy, los desarrolladores deshabilitan el proxy, arreglan la herramienta y olvidan volver a habilitarlo.
Casos como estos ocurren a diario. Un desarrollador instala una extensión de VS Code comprometida a las 23:00 desde su máquina personal. Un CI runner descarga una dependencia envenenada fuera del perímetro de la red corporativa. Ninguna de esas instalaciones pasa por el proxy. El escaneo nunca se ejecuta. La comprobación que se suponía que debía detectarlo simplemente no estaba allí.
Lo que realmente funciona
Tanto EDR como los proxies resuelven problemas reales para las amenazas para las que fueron diseñados y siguen siendo valiosos. Simplemente no cubren la superficie de ataque de la cadena de suministro específica para desarrolladores.
Esa superficie necesita algo que resida en la propia máquina, comprenda lo que hacen los paquetes en el momento de la instalación y esté siempre presente independientemente de la configuración de red. Hemos creado Aikido Device Protection para hacer exactamente eso. Descubra cómo varias organizaciones están utilizando Device Protection para proteger las máquinas de los desarrolladores en este blog.
Si desea una visión más completa de lo que las herramientas de endpoint tradicionales pasan por alto en las máquinas de los desarrolladores, la versión MDM de este problema se aborda en este artículo.
