Ataques a la cadena de suministro npm y tu web

Un ataque a la cadena de suministro npm ocurre cuando alguien cuela código malicioso en un paquete que tu web instala. Tú nunca tocas ese código: lo trae el build, y desde ahí puede robar credenciales o ejecutarse en el navegador de tus visitantes. Incluso una web corporativa sencilla instala cientos de paquetes, así que el riesgo también es tuyo.

En este artículo explicamos cómo estos ataques llegan a webs de empresa normales, qué tenían en común los incidentes recientes y qué ajustes concretos aplicamos en cada build. Está escrito para fundadores y responsables de marketing, con el detalle suficiente para quien mantiene tu código.

¿Qué es un ataque a la cadena de suministro npm?

npm es el registro público del que depende casi cualquier proyecto JavaScript. Una web de marketing moderna en Next.js declara unas decenas de dependencias directas. Cada una trae las suyas, de modo que el árbol real de instalación suele superar varios cientos de paquetes. Tu equipo eligió a conciencia solo unos pocos.

El atacante no necesita entrar en tus servidores. Le basta con una de estas tres cosas:

• La cuenta de un mantenedor. Un phishing, una contraseña reutilizada o un token filtrado le permiten publicar una versión nueva de un paquete de confianza.
• Una imitación creíble. Un paquete cuyo nombre difiere en una letra del de uno popular, a la espera de una errata en el comando de instalación.
• Un mantenedor que cambia de bando. Es raro, pero ha pasado: el propio dueño publica código dañino a propósito.

En cuanto la versión maliciosa está publicada, la recibe cualquier proyecto que no tenga fijada la versión exacta. Puede ser el portátil de un desarrollador, tu pipeline de CI o el bundle de producción.

Incidentes recientes en npm y lo que tienen en común

Los últimos años dejan un patrón claro. Conviene conocer por su nombre algunos casos bien documentados.

• chalk, debug y otras utilidades básicas, septiembre de 2025. Un mantenedor cayó en un phishing desde un falso dominio de «soporte de npm». El atacante publicó versiones que interceptaban APIs del navegador para desviar transacciones de monederos cripto. Son paquetes que se instalan miles de millones de veces por semana, aunque las versiones limpias volvieron en pocas horas. Endor Labs publicó el análisis.
• El gusano Shai-Hulud, septiembre de 2025. Unos scripts de instalación maliciosos buscaban tokens de npm, GitHub y nubes en cada máquina. Después usaban los tokens de npm robados para publicar versiones infectadas de otros paquetes. CISA contó más de 500 paquetes comprometidos en su alerta. En noviembre de 2025 llegó una segunda oleada.
• Cambios en el registro. GitHub, que gestiona npm, publicó su plan para una cadena de suministro npm más segura: publicar solo con 2FA, tokens granulares de vida corta o trusted publishing desde CI.

Lo que une estos casos es sencillo: las víctimas no cometieron ningún error evidente. Instalaron una versión de un paquete que ayer estaba bien. Por eso la defensa tiene que funcionar incluso cuando confías en el nombre del paquete.

Por qué una web de marketing es un objetivo real

Es fácil pensar que los atacantes solo buscan bancos y grandes plataformas SaaS. Pero una web de marketing también guarda cosas valiosas:

• Secretos del build. Tokens del CMS, claves de analítica, webhooks de formularios y credenciales de despliegue suelen vivir en el entorno de build.
• Tus visitantes. El código que acaba en el bundle del cliente se ejecuta en cada visita, con acceso a la página y a sus formularios.
• Tu reputación. Una página alterada o un aviso del navegador en tu dominio destruyen una confianza que costó años construir.

La carga para navegador de septiembre de 2025 lo ilustra bien. No hacía nada en el servidor: esperaba en el JavaScript publicado a un visitante con monedero cripto. Cualquier web reconstruida en esa ventana pudo servirla.

Cómo blindamos las dependencias en cada build

No hacen falta herramientas exóticas. Hacen falta unos pocos valores por defecto, configurados una vez y comprobados de forma automática. Estos son los que aplicamos en cada proyecto Next.js que entregamos.

Lockfile en el repositorio e instalación solo desde él

El lockfile registra la versión exacta y el checksum de cada paquete. El CI debe instalar desde él y fallar si no coincide con package.json.

# pnpm
pnpm install --frozen-lockfile

# npm
npm ci

Como explica la documentación de npm, npm ci se niega a ejecutarse si el lockfile y el manifiesto no coinciden. Así ninguna actualización silenciosa se cuela en un despliegue.

Scripts de instalación bloqueados por defecto

Casi todos los gusanos de este tipo se ejecutan con preinstall o postinstall. pnpm 10 ya no ejecuta los scripts de ciclo de vida de las dependencias sin permiso. Mantenemos una lista explícita para los pocos paquetes que necesitan compilación nativa.

# pnpm-workspace.yaml
onlyBuiltDependencies:
  - sharp
  - esbuild

Con npm, el equivalente es un .npmrc del proyecto con ignore-scripts=true, más un paso de build manual para lo que de verdad lo necesite.

Esperar antes de instalar versiones recién publicadas

La mayoría de las versiones maliciosas se detectan y retiran en horas o días. Una pequeña espera hace que casi nunca te las cruces. pnpm añadió un ajuste para esto en la versión 10.16, documentado en la referencia de ajustes de pnpm.

# pnpm-workspace.yaml
minimumReleaseAge: 1440   # minutos: ignora versiones con menos de un día

Cuando sale un parche de seguridad real, excluimos ese paquete concreto y lo actualizamos a conciencia.

Secretos fuera del bundle del cliente

En Next.js solo llegan al navegador las variables con el prefijo NEXT_PUBLIC_. Revisamos esa lista al inicio de cada proyecto. Los tokens de escritura del CMS, las URL de webhooks y las cadenas de conexión a la base de datos nunca llevan ese prefijo.

Menos dependencias y actualizaciones revisadas

Cada paquete que no instalas es uno en el que no tienes que confiar. Preferimos las funciones de la plataforma y pequeñas utilidades propias a una librería para cada tarea. Las actualizaciones llegan como pull requests revisados, nunca como un cambio silencioso el día del despliegue.

Qué preguntar esta semana a tu desarrollador o agencia

No necesitas leer código para medir tu exposición. Haz estas preguntas y fíjate en si las respuestas son concretas:

1. ¿Está el lockfile en el repositorio y el CI instala con npm ci o pnpm install --frozen-lockfile?
2. ¿Los scripts de instalación de dependencias están bloqueados por defecto, con una lista corta de excepciones?
3. ¿Hay una espera antes de aceptar versiones de paquetes recién publicadas?
4. ¿Qué variables de entorno llegan al navegador y quién revisó esa lista?
5. ¿Quién recibe el aviso cuando una alerta de seguridad afecta a la web y en cuánto tiempo actúa?
6. ¿Las cuentas de npm y GitHub del proyecto tienen 2FA, idealmente con llaves físicas?

Si las respuestas son vagas, ahí tienes la señal. La higiene de dependencias va junto a lo básico de nuestro checklist de seguridad web: cabeceras, HTTPS y control de accesos.

Cómo encaja esto en un proyecto

Tratamos la política de dependencias como parte del build, no como una auditoría para más adelante. Se configura la primera semana, queda escrita en el repositorio y se comprueba en el CI. Lo mismo vale para las decisiones de stack que contamos en nuestra guía sobre la web corporativa con Next.js: menos piezas móviles hacen la web más fácil de proteger.

La seguridad también se nota en la entrega. Recibes el repositorio, la configuración del CI y una nota breve sobre qué hace cada ajuste. Si más adelante otro equipo se hace cargo, hereda las protecciones y no solo el código. Puedes ver dónde encaja todo esto en nuestro proceso de trabajo.

Planifica un build más seguro para tu web

Si tu web depende de paquetes npm, y casi seguro que sí, conviene tener estos ajustes antes del próximo incidente. Los aplicamos de serie en cada proyecto que construimos, también en el desarrollo de aplicaciones web, donde un MVP empieza en 25.000 $ y suele llevar 12-16 semanas. Y la respuesta a cuánto cuesta una página web la publicamos abierta, con cada extra en su propia línea.