Análisis de seguridad de paquetes npm: guía práctica
El registro de npm sostiene la mayor parte del desarrollo web moderno, lo que también lo convierte en una de las cadenas de suministro de software más atacadas. Analizar el riesgo de seguridad de los paquetes npm ya es lo mínimo, pero «analizar» tiene que significar algo más que buscar CVE conocidos, porque los incidentes que más daño hacen implican paquetes maliciosos y actualizaciones comprometidas que ninguna base de datos de vulnerabilidades ha catalogado todavía.
Los tres riesgos que hay que analizar
- Vulnerabilidades conocidas: CVE en las versiones exactas que usas, incluidas las dependencias transitivas.
- Paquetes maliciosos o sospechosos: código ofuscado, scripts de instalación que exfiltran datos y typosquats que imitan nombres de paquetes populares.
- Procedencia e integridad: ¿procede de verdad este paquete de la fuente esperada y está sin modificar? Los hashes de integridad del lockfile y la procedencia firmada ayudan a responderlo.
Cómo funcionan los ataques a la cadena de suministro de npm
Los vectores recurrentes son el typosquatting (un paquete malicioso con un nombre parecido al de uno popular), la confusión de dependencias (una compilación descarga un paquete público en lugar del privado que pretendías) y el compromiso de la cuenta de un mantenedor (un atacante publica una actualización maliciosa de un paquete legítimo que todo el mundo descarga automáticamente). El código malicioso se esconde a menudo en scripts de instalación que se ejecutan durante npm install; por eso el comportamiento posterior a la instalación es algo clave que analizar y controlar.
¿Basta con npm audit?
No. npm audit comprueba las vulnerabilidades conocidas: es necesario, pero no suficiente. No detectará un paquete malicioso recién publicado, un typosquat ni una actualización comprometida reciente. Añade encima el análisis de paquetes maliciosos y de comportamiento y la verificación de la procedencia.
Intégralo en tu flujo de trabajo
- Ejecuta el análisis de dependencias y de paquetes maliciosos en el CI en cada pull request.
- Haz que fallen las compilaciones ante hallazgos de gravedad alta.
- Fija y verifica las dependencias con un lockfile confirmado en el repositorio (hashes de integridad).
- Desactiva o aísla en un sandbox los scripts de instalación de los paquetes no fiables.
Analiza un paquete ahora con el npm Scanner → o con el más amplio Package Scanner, y mira un compromiso real de npm diseccionado en el análisis de procedencia de Shai-Hulud. Para análisis estático, DAST y detección de secretos más allá de npm, consulta herramientas gratuitas de AppSec que no necesitan prueba gratuita.
Preguntas frecuentes
¿Qué hay que analizar? Las vulnerabilidades conocidas, los paquetes maliciosos o sospechosos (typosquats, scripts de instalación que exfiltran datos) y la procedencia y la integridad.
¿Cómo se llevan a cabo los ataques? Con typosquatting, confusión de dependencias y compromiso de la cuenta de un mantenedor, a menudo mediante scripts de instalación.
¿Cómo lo integro? Analiza en el CI, haz fallar las compilaciones ante gravedad alta, fija y verifica con un lockfile y aísla los scripts de instalación.
¿Basta con npm audit? No: detecta los CVE conocidos, pero no los paquetes maliciosos nuevos, los typosquats ni los compromisos recientes.
Preguntas frecuentes
¿Qué debe buscar el análisis de paquetes npm?
Tres cosas: las vulnerabilidades conocidas (CVE) en las versiones concretas de las que depende tu proyecto, incluidas las dependencias transitivas; los indicadores de paquetes maliciosos o sospechosos (código ofuscado, scripts de instalación o post-instalación sospechosos, exfiltración de datos, nombres con typosquatting que imitan paquetes populares); y la procedencia y la integridad (verificar que el paquete procede de verdad de la fuente esperada y está sin modificar, mediante los hashes de integridad del lockfile y, cada vez más, la procedencia firmada). Analizar solo los CVE deja fuera los riesgos de paquetes maliciosos y typosquats que han provocado muchos incidentes recientes.
¿Cómo se llevan a cabo los ataques a la cadena de suministro de npm?
Entre los vectores habituales están el typosquatting (publicar un paquete malicioso con un nombre parecido al de uno popular), la confusión de dependencias (engañar a una compilación para que descargue un paquete público en lugar del privado previsto) y el compromiso de la cuenta de un mantenedor (un atacante se hace con el control de un paquete legítimo y publica una actualización maliciosa que todos sus usuarios descargan automáticamente). El código malicioso se esconde a menudo en scripts de instalación que se ejecutan durante npm install; por eso el comportamiento de los scripts posteriores a la instalación es algo clave que analizar y controlar.
¿Cómo integro el análisis en mi flujo de trabajo?
Ejecuta el análisis de dependencias y de paquetes maliciosos en el CI para que se compruebe cada pull request y cada compilación, haz que fallen las compilaciones ante hallazgos de gravedad alta, fija y verifica las dependencias con un lockfile confirmado en el repositorio (hashes de integridad) y plantéate desactivar o aislar en un sandbox los scripts de instalación de los paquetes no fiables. Detectar una dependencia mala en la fase de pull request es mucho más barato que después de publicarla.
¿Basta con npm audit?
npm audit comprueba las vulnerabilidades conocidas de tu árbol de dependencias, lo cual es necesario pero no suficiente. No detecta un paquete malicioso recién publicado, un typosquat ni una actualización comprometida que todavía no se ha catalogado como vulnerabilidad. Un enfoque completo añade el análisis de paquetes maliciosos y de comportamiento y la verificación de la procedencia por encima del análisis de vulnerabilidades conocidas.