TL;DR: La seguridad de la cadena de suministro de npm va más allá del escáner de vulnerabilidades.
La seguridad de la cadena de suministro de npm es la práctica de garantizar que cada paquete que instalen sus proyectos de JavaScript sea legítimo, no modificado y seguro. No solo está libre de vulnerabilidades conocidas.
- La brecha: Un escáner de vulnerabilidades clásico de npm compara los paquetes con bases de datos CVE. Un paquete malicioso no tiene ninguna vulnerabilidad CVE, por lo que pasa la prueba.
- La prueba: En marzo de 2026, una cuenta de administrador pirateada convirtió axios, con más de 100 millones de descargas semanales, en un canal de distribución de malware durante aproximadamente tres horas.
- El punto de entrada: La mayoría de los ataques de npm se realizan a través de scripts de instalación, que se ejecutan en el momento en que escribes
npm install. - La solución: Detectar comportamientos maliciosos en el momento de la publicación de los paquetes, no después de que aparezca una vulnerabilidad CVE, y reforzar la seguridad en el proceso de instalación.
El 31 de marzo de 2026, miles de desarrolladores ejecutaron el comando más común en JavaScript: npm installAlgunos instalaron una nueva versión de Axios, el cliente HTTP presente en gran parte de las aplicaciones web del mundo. Sus escáneres de dependencias no detectaron ningún problema. Sus compilaciones se completaron correctamente. Y, sin que nadie se diera cuenta, un troyano de acceso remoto se instaló en sus máquinas.
En esa historia no había ninguna vulnerabilidad. Precisamente por eso, tantos programas de seguridad de npm no la detectaron.
¿Qué pasó con Axios?
El ataque fue simple y paciente. Según el El análisis post mortem de los propios responsables del mantenimiento de Axios, dos versiones maliciosas, 1.14.1 y 0.30.4, fueron publicadas a través de la cuenta comprometida del mantenedor principal. El atacante no tocó ni una sola línea de código de axios. Añadieron una nueva dependencia, plain-crypto-js, que dirigía un postinstall script que recuperó una carga útil de segunda etapa.
Microsoft Threat Intelligence atribuyó la infraestructura a Sapphire Sleet, un actor estatal norcoreano. Las versiones envenenadas estuvieron activas durante aproximadamente tres horas antes de que npm las eliminara. Para cualquier CI pipeline o portátil que se instaló durante ese período, tres horas fueron suficientes.
No fue un caso aislado. En septiembre de 2025, el gusano Shai-Hulud se propagó por cientos de paquetes npm robando tokens de mantenedores y republicándose. Técnica diferente, misma lección: en npm, la confianza se hereda automáticamente, y los atacantes lo saben.
¿Por qué tu escáner de vulnerabilidades de npm no dijo nada?
La mayoría de los equipos tratan la seguridad de la cadena de suministro de npm como un problema de vulnerabilidad. Ejecutan un escáner de vulnerabilidades de npm, que compara su árbol de dependencias con bases de datos de fallos conocidos, y corrigen lo que detecta. Ese trabajo es importante, pero responde a una pregunta diferente.
| Dimensión | Paquete vulnerable | Paquete malicioso |
|---|---|---|
| Lo que es | Código legítimo con un error. | Código escrito para hacerte daño |
| ¿Tiene un CVE? | Por lo general, eventualmente | Casi nunca |
| Cuando es peligroso | Cuando la vulnerabilidad es accesible y explotable | En el momento en que se instala |
| ¿Qué lo atrapa? | Una búsqueda en la base de datos de vulnerabilidades | Análisis del comportamiento del propio paquete |
| Tiempo de respuesta típico necesario | Días a semanas | Minutos a horas |
Una base de datos de vulnerabilidades solo puede describir algo que alguien ya ha analizado y catalogado. Un paquete malicioso publicado hace una hora no tiene ninguna entrada en ningún sitio. Por lo tanto, el escáner no detecta ninguna vulnerabilidad, y un resultado negativo se interpreta como seguro.
Ese es el cambio fundamental en la seguridad de la cadena de suministro de npm: la pregunta ya no es "¿tiene este paquete una vulnerabilidad conocida?", sino "¿está este paquete haciendo algo que no debería?".
Cuatro maneras en que los atacantes acceden a tus node_modules
- Toma de control de cuenta. Robar las credenciales o el token de un mantenedor y publicar una versión manipulada de un paquete en el que la gente ya confía. Esta es la táctica de Axios, y es la más difícil de detectar, porque el nombre del paquete es exactamente el correcto.
- Typosquatting. Publicar
axoisorreqeustsy esperar a que un error tipográfico, un copiar y pegar de un mal tutorial o un asistente de codificación de IA sugiera el nombre incorrecto. - Confusión de dependencia. Publica un paquete público con el mismo nombre que uno de tus paquetes internos. Si la configuración de tu registro da preferencia al paquete público, se instalará el código del atacante.
- Scripts de instalación. El hilo conductor en casi todo lo anterior. npm permite que los paquetes se ejecuten.
preinstallypostinstallLos scripts se ejecutan automáticamente, por lo que el código malicioso se ejecuta antes de que nadie importe nada. CISLa orientación de A sobre el compromiso de Axios recomienda configurarignore-scripts=truepara precispor esta razón.
Cómo se ve en la práctica la seguridad de la cadena de suministro de npm
No detendrás todos los ataques con un solo control. Puedes convertirte en un objetivo mucho más difícil con un puñado de hábitos:
- Commit su archivo de bloqueo e instalar con
npm ci. Las compilaciones deben instalar exactamente lo que se revisó, nunca lo que estuviera registrado esa mañana. - Deshabilitar los scripts de instalación por defecto. Establecer
ignore-scripts=truey permitir scripts únicamente para los paquetes que realmente los necesiten. - Defina el alcance de sus paquetes internos. Los nombres internos sin ámbito son una invitación abierta a la confusión de dependencias.
- Comprobar la procedencia. npm admite declaraciones de procedencia que vinculan un paquete publicado con su código fuente y su compilación. Un lanzamiento repentino sin ellos, de un proyecto que normalmente los tiene, es una señal de alerta que merece ser automatizada.
- Combine el análisis de vulnerabilidades con la detección de malware. Mantén actualizado tu escáner de vulnerabilidades de npm para detectar fallos conocidos y añade un sistema de detección que analice lo que hacen realmente los nuevos paquetes.
El quinto hábito es el que la mayoría de los equipos omiten, y es el que el ataque Axios puso al descubierto.
Detecta el paquete malicioso antes de que tenga nombre.
xygenis Alerta temprana de malware (MEW) Escanea los nuevos paquetes en los registros públicos, incluido npm, tan pronto como se publican, y analiza el comportamiento de su código en lugar de esperar una firma conocida. Cuando se marca un paquete, los usuarios afectados son notificados por correo electrónico, plataformas de mensajería o web.hooksy el paquete es puesto en cuarentena, así que puedes detenerlo en tu CI/CD guardrails.
A su alrededor, xygenis open source security Captura el resto de los elementos en los que se basan las cuatro rutas de ataque anteriores: typosquatting, confusión de dependencias, scripts de instalación sospechosos y componentes internos de npm sin alcance. También cubre vulnerabilidades conocidas de NVD, OSV y avisos de GitHub, priorizadas por accesibilidad para que puedas corregir lo que realmente es explotable, con corrección automática. pull requests para las correcciones.
MEW está incluido en el plan gratuito para desarrolladores. Empieza gratis y analiza tus primeros proyectos npm en minutos.
Preguntas Frecuentes
¿Qué es la seguridad de la cadena de suministro de npm?
La seguridad de la cadena de suministro de npm abarca todos los riesgos que introducen los paquetes de los que dependen tus proyectos JavaScript: vulnerabilidades conocidas, paquetes maliciosos, cuentas de mantenedor comprometidas, typosquatting y confusión de dependencias. Va más allá del análisis de vulnerabilidades para verificar que lo que instalas sea legítimo.
¿Un escáner de vulnerabilidades de npm detecta malware?
Normalmente no. Un escáner de vulnerabilidades npm tradicional compara los paquetes con bases de datos de vulnerabilidades conocidas. Un paquete malicioso recién publicado no tiene entrada en la base de datos, por lo que pasa la prueba a menos que la herramienta también analice el comportamiento del paquete.
Is npm audit ¿suficiente?
npm audit Es una herramienta gratuita útil para detectar vulnerabilidades conocidas. No detecta malware recién publicado, errores tipográficos ni confusiones de dependencias, y no indica si una función vulnerable es realmente accesible desde tu código.
¿Cómo puedo saber si un paquete es malicioso?
Entre las señales de alerta se incluyen scripts de instalación que descargan o ejecutan código remoto, código ofuscado, llamadas de red no relacionadas con el propósito del paquete, una nueva dependencia a la que el repositorio de origen nunca hace referencia y una versión sin la procedencia que el proyecto suele publicar.
