Qué es un ataque a la cadena de suministro y cómo reducir los riesgos de seguridad
Qué es un ataque supply chain, cómo se propaga y cómo reducir el riesgo, con o sin backend.
6 min de lectura
- seguridad
- kastavo
Cuando instalas una dependencia para un proyecto, confías en toda una cadena de código que nunca escribiste. Un ataque a la cadena de suministro (supply chain) explota justamente esa confianza: en lugar de atacar tu sitio directamente, el atacante compromete una biblioteca que miles de otros proyectos ya usan y espera a que instales la versión infectada.
El caso que muestra el tamaño del problema
En una campaña que alcanzó a axios, una biblioteca de JavaScript muy usada para hacer solicitudes HTTP, alguien tomó el control de la cuenta de npm del mantenedor principal y publicó dos versiones maliciosas, con unos 39 minutos de diferencia, como si fueran lanzamientos normales del proyecto. Las versiones estuvieron disponibles durante algunas horas, hasta que npm las eliminó.
No fue un caso aislado. ReversingLabs, una empresa de seguridad de software, registró un aumento de alrededor del 73% en las detecciones de paquetes maliciosos de código abierto en 2025 frente a 2024, con más de 10.000 identificados solo en npm. Y en una campaña reciente llamada Shai-Hulud, más de cien paquetes de npm fueron comprometidos por un código que se replicaba solo.
Cómo se propaga el ataque
El mecanismo suele seguir un patrón simple:
- El atacante roba las credenciales de un mantenedor (phishing, ingeniería social o filtración de un token en otro servicio comprometido)
- Usa esas credenciales para publicar una nueva versión del paquete, con código malicioso escondido
- Quien instala o actualiza la dependencia recibe el código infectado sin darse cuenta, porque el paquete sigue llegando desde la fuente "oficial"
- En algunos casos, el malware es capaz de replicarse solo: usa los tokens robados para encontrar otros paquetes del mismo mantenedor e infectarlos también, creando un efecto en cadena
Ese es el peligro central: desde el punto de vista de quien instala, parece una actualización normal. No hay aviso ni alerta: es solo una versión más de una biblioteca que ya usabas.
Si tu sitio tiene backend: qué puedes hacer
Para quien ejecuta aplicaciones con servidor (la mayoría de los sitios), no existe una solución mágica, pero hay prácticas que reducen bastante el riesgo:
- Fijar las versiones de las dependencias (lockfiles, como package-lock.json) en lugar de traer siempre la versión más reciente de forma automática
- Auditar las dependencias con regularidad con herramientas como npm audit, Socket Security o Snyk, que monitorean paquetes conocidos por comportamiento sospechoso
- Revisar qué cambia realmente una actualización antes de aplicarla en producción, sobre todo en bibliotecas con mucho acceso (autenticación, manejo de archivos, solicitudes de red)
- Usar publicación confiable (trusted publishing) cuando esté disponible: un mecanismo más reciente que elimina la necesidad de tokens de larga duración y reduce lo que se puede robar
- Limitar a qué puede acceder el backend, con el principio de mínimo privilegio: si una dependencia comprometida solo tiene acceso a lo estrictamente necesario, el daño potencial es menor
Ninguna de estas prácticas es una garantía total. Un ataque a la cadena de suministro es, por naturaleza, difícil de prevenir por completo, porque explota la misma confianza que hace útil al ecosistema de paquetes.
Si tu sitio no tiene backend procesando archivos
Este es el caso de Kastavo. Como las herramientas se ejecutan por completo en el navegador, no existe un servidor que reciba el archivo de la persona y lo procese con dependencias de backend. Por eso, un vector de ataque específico simplemente no existe aquí: no hay forma de que una dependencia comprometida del lado del servidor acceda a archivos que nunca llegaron a ese servidor, porque nunca salen del dispositivo de quien usa la herramienta.
Esto reduce la exposición, pero no elimina todo el riesgo. Una arquitectura del lado del cliente sigue dependiendo de:
- Dependencias usadas durante el desarrollo y el build: si una biblioteca usada para construir el sitio se compromete, el código que llega al navegador de la persona puede verse afectado
- Scripts de terceros cargados en la página: cualquier script externo (analítica, anuncios, fuentes) es, en sí mismo, una dependencia de confianza
- La integridad del propio proceso de publicación: desde el commit hasta el deploy, cada etapa es un eslabón que debe estar protegido
Por eso, incluso sin un backend que procese archivos, sigue valiendo la pena aplicar las mismas prácticas de la sección anterior (lockfiles, auditoría, mínimo privilegio) en el entorno de desarrollo y de build.
La lección que queda
Un ataque a la cadena de suministro no es un problema que se resuelva con una sola herramienta o configuración: es una categoría de riesgo que crece junto con la cantidad de dependencias que acumula cualquier proyecto moderno. La arquitectura de dónde ocurre el procesamiento (servidor o navegador) cambia qué vectores existen, pero no sustituye las prácticas básicas de seguridad en ninguno de los dos casos.
La pregunta más útil, al elegir qué herramienta usar para un archivo sensible, no es solo "¿es segura?", sino "¿a qué está expuesta exactamente, y por qué?"
Preguntas frecuentes
Es un ataque que, en lugar de entrar directamente en tu sitio o aplicación, compromete algo en lo que ya confías: una biblioteca, una herramienta de build o la cuenta de quien mantiene un paquete. Como la versión infectada llega por el canal normal de actualización, quien la instala suele no darse cuenta.
No. Ejecutar todo en el navegador elimina el vector en el que una dependencia del servidor accede a los archivos enviados, porque nunca llegan a un servidor. Pero el sitio sigue dependiendo de las bibliotecas usadas en el desarrollo y en el build, de los scripts de terceros cargados en la página y de la seguridad del proceso de publicación. El riesgo disminuye, pero no desaparece.
No hay garantía total, pero ayuda mucho fijar las versiones con un lockfile, auditar las dependencias con herramientas como npm audit, Socket Security o Snyk, revisar qué cambia cada actualización antes de pasar a producción, usar publicación confiable (trusted publishing) cuando esté disponible y limitar a qué puede acceder el backend.
