Paquetes maliciosos: la amenaza de la cadena de suministro que tu escáner de CVE no ve
Tu escáner de dependencias responde muy bien a una pregunta: ¿esta versión del paquete tiene una vulnerabilidad conocida? Eso cubre los errores honestos en el código que alguien encontró y corrigió después. No cubre un paquete creado para hacerte daño, ni un paquete confiable que secuestraron anoche y volvieron a publicar con código malicioso.
Eso son los paquetes maliciosos, y se comportan de forma muy distinta a una vulnerabilidad. Muchas veces no tienen CVE, nunca reciben una "versión corregida" y suelen actuar en el momento en que los instalas. Esta guía explica qué los hace diferentes, qué nos enseñaron los incidentes de npm de 2025 y qué controles reducen el riesgo de verdad.
Vulnerable no es lo mismo que malicioso
La base de datos de avisos de GitHub lo explica con claridad. Una vulnerabilidad es un problema en el código de un proyecto que se puede explotar. El malware es código diseñado a propósito para funciones no deseadas o dañinas.
Esa diferencia lo cambia todo:
- Identificadores. Las vulnerabilidades se rastrean con CVE. Los paquetes maliciosos se reportan por otros canales: el repositorio Malicious Packages de OpenSSF los publica en formato OSV con identificadores que empiezan por
MAL-, y GitHub publica avisos de malware con identificadores GHSA. - Corrección. Un aviso de vulnerabilidad te dice desde qué versión está corregido el problema. Los avisos de malware de GitHub no tienen versión corregida: la solución es eliminar el paquete y buscar un reemplazo seguro.
- Momento. Una vulnerabilidad se suele explotar contra una aplicación en ejecución. Un paquete malicioso puede ejecutarse durante la instalación, en la laptop de un desarrollador o en un runner de CI, antes de que tu aplicación arranque.
Si tu análisis de composición de software (SCA) solo cruza las dependencias contra datos de CVE, está respondiendo la pregunta equivocada para esta amenaza. Si quieres repasar qué hace bien el SCA, lee SAST, SCA, secretos e IaC explicados.
Cómo llegan los paquetes maliciosos a tu build
Hay cuatro rutas habituales:
1. Typosquatting
El atacante publica un paquete cuyo nombre está a una tecla de uno popular. Basta un error de tipeo en package.json, en requirements.txt o en un comando de instalación copiado de internet.
2. Confusión de dependencias
Tu empresa usa un paquete interno con cierto nombre. El atacante publica un paquete público con el mismo nombre y un número de versión mayor. Un gestor de paquetes mal configurado que consulta el registro público puede preferir la versión del atacante.
3. Mantenedores comprometidos
Es la ruta más peligrosa, porque el nombre del paquete es el legítimo. En septiembre de 2025, el mantenedor de paquetes npm muy usados, entre ellos chalk y debug, cayó en un correo de phishing que se hacía pasar por un "restablecimiento de 2FA" desde un dominio parecido al de npm. Dieciocho paquetes con más de 2 000 millones de descargas semanales combinadas se volvieron a publicar con código que interceptaba la actividad de billeteras cripto en el navegador de los visitantes de los sitios web.
4. Malware que se propaga solo
Días después, el gusano Shai-Hulud llegó a npm. Según CISA, comprometió más de 500 paquetes. Buscaba secretos en los entornos infectados, como tokens de GitHub y claves de API de nube, los exfiltraba y usaba el acceso robado a npm para publicar versiones contaminadas de otros paquetes, propagándose por su cuenta.
¿Qué tan grande es el problema?
El informe State of the Software Supply Chain 2024 de Sonatype contó más de 704 102 paquetes maliciosos de código abierto identificados desde 2019, con un aumento interanual del 156 %. Después, su Open Source Malware Index identificó 17 954 paquetes maliciosos nuevos solo en el primer trimestre de 2025, y el 56 % de ellos estaba orientado a la exfiltración de datos.
El patrón es claro: los paquetes maliciosos no son casos raros, y el objetivo más común es robar datos y credenciales, no romper tu aplicación.
Controles que sí ayudan
Ningún control detiene todos los paquetes maliciosos. Combina estos:
Instala exactamente lo que revisaste
Versiona los lockfiles e instala desde ellos en CI. La documentación de npm es explícita: npm ci necesita un package-lock.json existente y termina con error si no coincide con package.json, en lugar de actualizarlo en silencio. Así evitas que una versión maliciosa recién publicada se cuele por un rango de versiones.
No ejecutes scripts de instalación por defecto
Muchos paquetes maliciosos lanzan su carga desde los scripts de ciclo de vida durante la instalación. Desde la versión 10, pnpm no ejecuta los scripts de las dependencias salvo que los permitas de forma explícita. En npm, la opción ignore-scripts evita que se ejecuten los scripts definidos en los package.json. Deja en una lista permitida solo los pocos paquetes que de verdad necesitan compilar algo.
Añade un periodo de espera
Una espera les da tiempo a los investigadores y a los registros para detectar y retirar una versión secuestrada antes de que llegue a ti. La opción minimumReleaseAge de pnpm (añadida en la versión 10.16.0) fija los minutos que deben pasar desde que se publica una versión antes de poder instalarla, y se aplica también a las dependencias transitivas. Un día de espera (1440 minutos) te evita estar entre los primeros en instalar una versión envenenada.
Cierra la puerta a la confusión de dependencias
Usa nombres con scope para tus paquetes internos y configura tu gestor de paquetes o tu repositorio de artefactos para que esos scopes se resuelvan solo desde tu registro privado.
Protege a quienes publican
El caso de chalk y debug empezó con phishing. Entre las recomendaciones de CISA tras Shai-Hulud está exigir MFA resistente al phishing en las cuentas de desarrolladores, sobre todo en GitHub y npm. GitHub también anunció que llevará npm hacia la publicación confiable (trusted publishing), el 2FA basado en FIDO y tokens de publicación granulares con una vida máxima de siete días.
Sabe dónde vive cada paquete
Cuando se anuncia una versión maliciosa, necesitas responder "¿la usamos y dónde?" en minutos. Un SBOM actualizado convierte esa pregunta en una consulta y no en un proyecto. Lee nuestra guía de formatos SBOM.
Si instalaste un paquete malicioso
Trátalo como un incidente de credenciales, no como una actualización de dependencias:
- Identifica los proyectos afectados a partir de los lockfiles, incluidas las dependencias anidadas, y revisa las copias en caché de tus repositorios de artefactos, como recomienda CISA.
- Elimina el paquete y fija una versión publicada antes del compromiso.
- Rota todas las credenciales a las que podían llegar los equipos y pipelines afectados: tokens de desarrolladores, secretos de CI, claves de nube.
- Revisa las apps de GitHub, las aplicaciones OAuth, los webhooks y los secretos de los repositorios en busca de cambios que no hiciste.
- Vigila las conexiones salientes inusuales desde los sistemas de build.
Las credenciales robadas muchas veces se usan después, no de inmediato. Por eso el monitoreo de credenciales filtradas forma parte del mismo plan.
Preguntas frecuentes
¿Mi herramienta SCA detecta paquetes maliciosos?
Solo si consume inteligencia de malware, como los reportes MAL- de OpenSSF o los avisos de malware de GitHub, además de los datos de CVE. Pregúntale directamente a tu proveedor.
¿Un paquete sin CVE conocido es seguro? No. Solo significa que nadie ha reportado una vulnerabilidad en él. Una versión recién secuestrada puede ser maliciosa y no tener ningún CVE.
¿Estos controles frenan a los desarrolladores? Los lockfiles y los registros con scope son casi invisibles una vez configurados. Un periodo de espera significa aguardar un día por las versiones nuevas, un precio pequeño comparado con rotar todos los secretos de tu CI.
Cómo ayuda priorIQ.ai
CodeIQ combina SCA con alcanzabilidad, detección de paquetes maliciosos y generación de SBOM en CycloneDX y SPDX, junto con SAST, escaneo de contenedores e IaC, y escaneo de secretos en todo el historial de git con validación de secretos activos. Su puerta en el pipeline puede detener una dependencia riesgosa antes del merge. Los hallazgos llegan a PriorIQ Core, que los pone en el mismo modelo de riesgo que tus endpoints y tu nube, para que tu equipo trabaje una sola cola priorizada. Solicita una demo.