npm audit No Es Suficiente: Vulnerabilidades de Dependencias en Node.js

npm audit es el primer comando de seguridad que aprende todo dev de Node.js. Es fácil, está incluido, corre en segundos. El problema es que muchos equipos lo tratan como si fuera suficiente — y las vulnerabilidades en dependencias de JavaScript que más daño hacen son exactamente las que npm audit no detecta.

Este post cubre qué detecta npm audit, qué se pierde, y cómo completar la cobertura de seguridad de dependencias en proyectos Node.js en 2026 sin montar infraestructura compleja.

Qué hace npm audit (y lo que hace bien)

npm audit cruza tu árbol de dependencias contra la base de datos de advisories de npm. Cuando un paquete tiene un CVE (Common Vulnerabilities and Exposures) registrado, npm lo sabe y te lo reporta.

# Correr el audit completo
npm audit
 
# Ver solo los críticos y altos
npm audit --audit-level=high
 
# Fix automático para versiones patch/minor
npm audit fix
 
# Reporte en JSON para CI/CD
npm audit --json > audit-report.json

El output te da:

El paquete afectado
La versión vulnerable que tienes instalada
La severidad (low, moderate, high, critical)
Si hay una versión que resuelve el problema y cómo llegar ahí

Eso es útil. Genuinamente útil. Si tienes lodash@4.17.4 con una vulnerabilidad de prototype pollution conocida, npm audit lo detecta y te dice que actualices a 4.17.21.

Los límites reales de npm audit

Aquí está lo que npm audit no cubre — y por qué importa.

Malware en paquetes publicados

npm audit solo conoce vulnerabilidades que ya tienen un CVE registrado. Un paquete que fue comprometido ayer — donde un atacante hackeó la cuenta del maintainer y publicó una versión con código que roba variables de entorno — no tiene CVE todavía. npm audit no lo ve.

El caso más famoso: event-stream en 2018. Un paquete con 2 millones de descargas semanales fue comprometido por un maintainer malicioso que agregó código para robar billeteras de Bitcoin. npm audit no lo habría detectado.

Typosquatting

crossenv vs cross-env. lodahs vs lodash. Paquetes publicados con nombres similares a paquetes populares, esperando que alguien cometa un typo al instalar.

# El typo está en el install, no en el paquete ya instalado
npm install cros-env  # typosquatting de cross-env
# npm audit no detecta que este paquete es malicioso

npm audit revisa paquetes que ya están en tu package.json. No analiza si el paquete en sí es legítimo o malicioso.

Dependencias transitivas que no deberían existir

Tu package.json puede tener 30 dependencias directas y 800 dependencias transitivas. npm audit revisa todo el árbol, pero no te dice si una dependencia transitiva está haciendo cosas que no debería — como hacer requests a URLs externas durante la instalación.

Vulnerabilidades de lógica

Si un paquete implementa incorrectamente validación de tokens JWT, npm audit no lo detecta si no hay un CVE oficial registrado. El paquete puede estar "actualizado" según npm audit y ser fundamentalmente inseguro.

Lo que sí deberías agregar

Análisis de la cadena de suministro (SCA más completo)

Data Hogo combina npm audit con la base de datos OSV (Open Source Vulnerabilities) de Google, que tiene una cobertura más amplia que la base de datos oficial de npm. En proyectos que escaneamos, encontramos en promedio 2-3 vulnerabilidades adicionales por repo que npm audit pasa por alto porque están en OSV pero no en la base de npm.

# npm audit solo — cobertura de la base de datos npm
npm audit
 
# Verificar contra OSV directamente con una herramienta como osv-scanner
osv-scanner --lockfile=package-lock.json

Revisar permisos de instalación de paquetes

Herramientas como npmluiten o revisar manualmente los postinstall scripts en paquetes nuevos que instalas. Un paquete que corre código arbitrario al instalarse es una señal de alerta:

// En el package.json de un paquete — revisar esto antes de instalar
{
  "scripts": {
    "postinstall": "node ./scripts/setup.js"  // ¿qué hace este script?
  }
}

Lockfiles en el repo y CI

Siempre commitear package-lock.json o yarn.lock. Siempre usar npm ci en CI/CD en lugar de npm install. npm ci instala exactamente las versiones del lockfile — no resuelve dependencias de nuevo, no instala versiones más recientes que podrían ser comprometidas.

# MAL: en CI, permite instalar versiones diferentes al lockfile
npm install
 
# BIEN: en CI, instala exactamente lo que está en el lockfile
npm ci

Auditar el historial de Git

Si alguna vez alguien commiteó un token de npm o credenciales de npm en el código, hay que rotarlos. La detección de secrets de Data Hogo busca en el historial completo de commits, no solo en el código actual.

Dependencias comunes con vulnerabilidades históricas

Algunos paquetes tienen historial largo de CVEs. No significa que debas evitarlos — significa que mantenlos actualizados de forma más activa:

Paquete	Tipo de vulnerabilidad histórica	Severidad típica
`lodash`	Prototype pollution	Alta
`minimist`	Prototype pollution	Alta
`moment`	ReDoS (regex denial of service)	Media
`axios`	SSRF, credential exposure	Alta
`jsonwebtoken`	Algoritmo none bypass	Crítica

Para jsonwebtoken en particular, revisar que estés especificando el algoritmo explícitamente:

// MAL: acepta el algoritmo "none" que desactiva la verificación
jwt.verify(token, secret);
 
// BIEN: especifica el algoritmo permitido explícitamente
jwt.verify(token, secret, { algorithms: ["HS256"] });

Este es un ejemplo del tipo de problema que va más allá de npm audit — el paquete puede estar en la última versión sin CVEs activos, pero el patrón de uso en tu código es inseguro.

El proceso completo de seguridad de dependencias

npm audit es el paso uno. El proceso completo para proyectos Node.js en producción:

npm audit en cada PR (lo básico)
npm ci en CI/CD (lockfile estricto)
Scanner SCA extendido (OSV + base de npm) — Data Hogo lo incluye como parte del escaneo completo
Revisar paquetes nuevos antes de instalarlos — especialmente si tienen pocas descargas o son muy nuevos
Alertas de Dependabot — GitHub notifica automáticamente cuando una dependencia tiene un CVE nuevo, incluso en repos privados

Si haces todo esto, cubres la mayoría de la superficie de seguridad de dependencias. Para las vulnerabilidades comunes más allá de las dependencias — SQL injection, XSS, auth rota — necesitas análisis estático de código además de SCA.

Escanea tus dependencias con cobertura extendida gratis →

Preguntas frecuentes

¿Qué detecta npm audit?

npm audit detecta paquetes en tu árbol de dependencias que tienen CVEs registrados en la base de datos de advisories de npm. Te muestra el paquete afectado, la versión vulnerable, la severidad y si hay una versión actualizada que resuelve el problema.

¿Qué no detecta npm audit?

npm audit no detecta malware en paquetes (como paquetes que roban variables de entorno al instalarse), typosquatting (paquetes con nombres similares a populares), vulnerabilidades en lógica de negocio, ni secretos en tu código fuente. Solo cruza versiones contra una base de datos de CVEs conocidos.

¿Cuándo debo correr npm audit?

Como mínimo antes de cada deploy importante y después de instalar o actualizar dependencias. Lo ideal es tenerlo en tu CI/CD pipeline para que corra automáticamente en cada PR. Si solo puedes hacerlo una vez al mes, hazlo justo antes de ir a producción.

¿Qué es un ataque de supply chain en npm?

Un ataque de supply chain en npm ocurre cuando un paquete legítimo es comprometido por un atacante — ya sea hackeando la cuenta del maintainer, haciendo typosquatting con un nombre similar, o publicando una versión maliciosa. npm audit no detecta este tipo de ataques porque el paquete comprometido puede no tener un CVE registrado todavía.

¿npm audit fix es seguro de correr en producción?

npm audit fix aplica actualizaciones de patch y minor version que no deberían romper compatibilidad. Es generalmente seguro, pero siempre corre tus tests después de aplicarlo. Evita npm audit fix --force — esa opción puede hacer cambios de major version que rompen tu código.