npm deja de fiarse por defecto: qué cambia con npm 12 y por qué deberías prepararte ya

De "me fío de todo" a "aprueba lo que ejecutas"

Si sigues la actualidad de seguridad, el último año en npm ha sido una sucesión de sustos: gusanos que se propagan solos, librerías con cien millones de descargas semanales comprometidas durante unas horas, y cuentas de mantenedores secuestradas para colar código malicioso en la cadena de suministro. Ayer, GitHub —que es quien mantiene npm— movió ficha con la que probablemente sea la reforma más profunda del gestor en años.

La idea de fondo es simple y llevaba tiempo pidiéndose: npm dejará de confiar por defecto. Lo que hoy se ejecuta solo al hacer npm install pasará a requerir tu permiso explícito. Llega en npm 12, previsto para julio, y si gestionas servidores, pipelines de CI o cualquier aplicación Node en producción, esto va contigo.

Por qué ahora: la oleada de paquetes envenenados

El detonante no es un caso, es un patrón. El más sonado fue Shai-Hulud, un malware que se comporta como un gusano autopropagante: se ejecuta en la fase preinstall, roba credenciales (tokens de GitHub, claves de AWS, GCP y Azure y secretos de CI/CD) y con ellas publica más paquetes infectados y crea repositorios maliciosos, encadenando la infección. En su segunda oleada se contabilizaron cientos de paquetes comprometidos y más de 25.000 repositorios creados de forma automática.

A eso se suman episodios como el secuestro de axios (una de las librerías más usadas del ecosistema), paquetes maliciosos publicados bajo espacios de nombre corporativos como @redhat-cloud-services a partir de una cuenta comprometida, y variantes menores tipo @tanstack o @antv. El vector se repite: un script que corre solo al instalar, o una dependencia que apunta a un Git o a una URL que tú nunca revisaste.

Qué cambia en npm 12 (los tres cambios rompedores)

GitHub lo resume como el paso de la confianza implícita al consentimiento explícito. En concreto:

1. Los scripts de instalación no se ejecutan por defecto. npm install dejará de correr los preinstall, install y postinstall de tus dependencias —además de las compilaciones de módulos nativos y los prepare desde Git o rutas locales— salvo que los apruebes de forma explícita. Es el cierre directo del vector de Shai-Hulud.
2. Dependencias desde Git bloqueadas. npm install ya no traerá dependencias apuntando a repositorios Git, ni directas ni transitivas, salvo permiso. Adiós a un camino cómodo para meter código sin pasar por el registro.
3. Dependencias desde URL remota bloqueadas. Los paquetes servidos desde una URL (tarballs HTTPS) tampoco se resolverán sin autorización, otra vez tanto directas como transitivas.

En resumen: lo que antes pasaba "solo" ahora tendrá que pasar porque tú lo has dicho.

A quién afecta

• A cualquiera que ejecute npm install en un servidor o en CI, que hoy es prácticamente cualquier despliegue con front moderno o backend Node.
• Especialmente a los pipelines de CI/CD, donde un postinstall malicioso tiene acceso a variables de entorno, tokens y claves. Es el sitio donde más daño hace y el que estos cambios protegen mejor.
• Y a los proyectos que tiran de dependencias desde Git o URLs (forks internos, paquetes privados sin registro): funcionarán, pero tendrás que declararlo. Mejor descubrirlo ahora que cuando el build se pare en rojo.

Qué puedes hacer hoy, sin esperar a la v12

No hace falta esperar a julio para reducir superficie. Estas medidas ya funcionan:

1. Mira en qué versión de npm estás

npm --version

Sube a npm 11.16.0 o superior para empezar a ver los avisos de qué flujos tuyos se verían afectados por la v12:

npm install -g npm@latest

2. Desactiva los scripts de instalación donde no los necesites

En CI y en despliegues reproducibles, casi nunca necesitas que las dependencias ejecuten scripts:

# Instalación puntual sin ejecutar scripts
npm install --ignore-scripts

# O de forma permanente en el proyecto (.npmrc)
echo "ignore-scripts=true" >> .npmrc

Si algún paquete legítimo necesita su postinstall (por ejemplo, uno con binario nativo), lo apruebas de forma controlada en lugar de dejar la puerta abierta para todos.

3. Usa instalaciones deterministas en CI

npm ci

npm ci instala exactamente lo que dice el package-lock.json, sin resolver versiones nuevas. Menos margen para que una versión recién publicada y comprometida entre sin que te enteres.

4. Fija y vigila

• Fija versiones (evita rangos amplios ^/~ en dependencias sensibles).
• Activa alertas de dependencias (Dependabot) y revisa qué paquetes traen postinstall.
• En cuanto salga npm 12, haz el inventario de scripts y de dependencias Git/URL que usas de verdad y apruébalas explícitamente. Ese trabajo, hecho con calma antes de actualizar, evita el susto del build parado.

Lo que hacemos nosotros

En los despliegues que gestionamos, las instalaciones de dependencias van con npm ci y --ignore-scripts por defecto, y los postinstall legítimos se aprueban uno a uno. No es paranoia: es que el coste de revisar un puñado de paquetes es ridículo comparado con el de que un preinstall se lleve las claves del servidor. npm 12 va justo en esa dirección, así que para nosotros no es un cambio, es la norma convertida en el comportamiento por defecto.

La rutina de siempre

Con la cadena de suministro, los gestos son parecidos a los de cualquier parche:

• npm --version para saber dónde estás.
• Subir a 11.16.0+ para ver los avisos.
• --ignore-scripts / npm ci en CI y despliegues.
• Inventariar scripts y dependencias Git/URL antes de dar el salto a la v12.

La confianza por defecto era cómoda, pero la factura la pagaba quien tenía la mala suerte de instalar el paquete equivocado el día equivocado. Si no tienes claro qué ejecuta tu npm install en producción o en CI, es buen momento para mirarlo. Y si prefieres que lo revisemos nosotros, hablamos.

Referencias

• GitHub announces npm security changes to tackle supply-chain attacks — BleepingComputer
• Shai-Hulud 2.0: ongoing supply chain attack — Wiz
• The npm Threat Landscape — Unit 42 (Palo Alto)