La mayoría de los equipos de seguridad se limitan a marcar la casilla de EDR, marcar la casilla de proxy y seguir adelante. Sin embargo, frente al malware de la cadena de suministro, ninguna de estas soluciones ofrece una protección significativa, ya que se diseñaron para resolver un problema distinto.
El malware tradicional suele colarse en un equipo, mientras que el malware de la cadena de suministro es bienvenido. El desarrollador ejecuta npm install, y el código malicioso se ejecuta con todos los permisos necesarios. Esa inversión hace que ambas herramientas dejen de funcionar a nivel de diseño.
¿Por qué el EDR no detecta el malware?
EDR supervisa los procesos en busca de comportamientos sospechosos: llamadas al sistema inusuales, relaciones padre-hijo inesperadas, firmas maliciosas conocidas. Se pregunta: «¿Este proceso se comporta como si fuera malware?».
El problema es que el malware de la cadena de suministro se ejecuta dentro de entornos de ejecución de confianza, realizando las mismas tareas que estos entornos llevan a cabo constantemente. Un script de postinstalación que lee archivos `.env` y envía su contenido mediante un método POST a un atacante parece idéntico a una herramienta de compilación que recupera credenciales para implementar código. Ambos son node o python leer archivos y realizar llamadas HTTP. Las llamadas al sistema y las llamadas de red son idénticas. El EDR no tiene ningún criterio para determinar que una sea legítima y la otra no.
En marzo de 2026, unos atacantes se apropiaron de la cuenta de npm del principal mantenedor de axios, un paquete con unos 100 millones de descargas semanales. No tocaron el código fuente. Añadieron una nueva dependencia cuya única función era un script de postinstalación que descargaba un RAT multiplataforma y se borraba a sí mismo. Para un monitor de procesos, esto era indistinguible de un proceso normal de npm install. Resuelve una dependencia, ejecuta un hook y realiza una solicitud HTTP.
Dos meses después, Tres versiones de durabletask, un paquete de Python del ecosistema Azure de Microsoft, contenían puertas traseras. La inyección tenía unas diez líneas de __init__.py. El código descarga un archivo y lo ejecuta en un subproceso, ignorando las excepciones. En una segunda fase, se recopilaron credenciales de AWS, Azure, GCP, Kubernetes y Vault, para luego propagarlas a otras instancias a través de SSM y a otros pods mediante kubectl exec, utilizando las propias credenciales de la víctima y accediendo a sus propias API en la nube. En los equipos con configuración regional israelí o iraní, una de cada seis ejecuciones ejecutaba el comando «rm -rf /*». Sin binarios externos, sin destinos anómalos. El EDR no cuenta con un modelo para el caso en el que el propio paquete constituya la amenaza.
ataques a la cadena de suministro este nivel son tan peligrosos porque la carga maliciosa se disfraza de comportamiento normal. No hay ninguna anomalía que detectar, ya que el objetivo es camuflarse entre el ruido o, en este caso, convertirse en el propio ruido.
¿Por qué los proxies no lo detectan?
Un servidor proxy situado en la ruta del tráfico puede interceptar la descarga de paquetes y compararlos con paquetes que se sabe que son maliciosos. En teoría, eso funciona. El problema es la parte de «situado en la ruta del tráfico».
Los proxies remotos y corporativos son controles opcionales en los equipos de los propios desarrolladores. Los desarrolladores trabajan desde casa, desde cafeterías o conectándose a la red wifi de un hotel. Instalan herramientas que eluden la configuración de proxy del sistema. VS Code gestiona sus propias descargas de extensiones. npm, pip y cargo tienen sus propios clientes HTTP. Muchas herramientas de línea de comandos y entornos de ejecución de lenguajes ignoran HTTP_PROXY por completo, a menos que se configure explícitamente. Y cuando una herramienta deja de funcionar debido al proxy, los desarrolladores desactivan el proxy, arreglan la herramienta y se olvidan de volver a activarlo.
Casos como estos ocurren a diario. Un desarrollador instala una extensión de VS Code comprometida a las 23:00 desde su ordenador personal. Un servidor de integración continua (CI) descarga una dependencia maliciosa fuera del perímetro de la red corporativa. Ninguna de esas instalaciones pasa por el proxy. El análisis nunca se ejecuta. La comprobación que se suponía que debía detectarlo simplemente no existía.
Lo que realmente funciona
Tanto el EDR como los proxies resuelven problemas reales relacionados con las amenazas para las que fueron diseñados y siguen siendo útiles. Simplemente no cubren la superficie de ataque de la cadena de suministro específica de los desarrolladores.
Esa interfaz necesita algo que se ejecute directamente en el propio equipo, que comprenda qué hacen los paquetes durante la instalación y que esté siempre disponible, independientemente de la configuración de red. Hemos creado Aikido Device Protection precisamente para eso. Descubre en este blog cómo varias organizaciones están utilizando Device Protection para proteger los equipos de los desarrolladores.
Si quieres tener una visión más completa de lo que las herramientas tradicionales para dispositivos finales no detectan en los equipos de los desarrolladores, en este artículo se aborda la versión de este problema relacionada con la gestión de dispositivos móviles (MDM).
