Hace poco más de un día la comunidad de desarrolladores JavaScript sufrimos un golpe fuerte y creo que envió olas a lo largo de todas las comunidades que dependen de una u otra forma del desarrollo web.
Axios —una de las librerías más usadas— fue comprometida en lo que se conoce como un supply chain attack. Traducido: no atacaron tu sistema directamente. Atacaron algo en lo que tu confías, yo y todos los desarrolladores confiamos. Y ahí está el verdadero problema.
Un npm install no es inocente. Es abrirle la puerta a código que no escribiste, que no auditaste y que probablemente nunca leíste. Yo lo veo todo el tiempo. Proyectos bien armados, buenas prácticas, buena arquitectura… y abajo de todo eso, una base de dependencias que nadie controla realmente.
Para quienes no sepan qué es npm, son las siglas de Node Package Manager y es el gestor de paquetes más utilizado para quienes trabajamos con JavaScript. Lo que hace es revisar el archivo package.json e instalar las versiones solicitadas de los paquetes del proyecto.
¿Sabés cuántos proyectos estás corriendo ahora mismo que dependen de código que nunca revisaste? No es una pregunta teórica. Es incómoda. Y después de lo que pasó con Axios, es más real que nunca. Y al final el problema no fue Axios sino la falta de controles.
Te explico cómo se rompe todo sin que te des cuenta
El flujo es más o menos así:
- Alguien compromete una librería popular
- Esa librería se publica como actualización “legítima”
- Tu proyecto la instala automáticamente (CI/CD, deploy, etc.)
- El código malicioso entra sin hacer ruido
- Llega a producción
- Y recién ahí empieza el problema
No hay hackeo visible. No hay alerta. No hay “te están atacando”.
Hay silencio.
Y después, consecuencias.
Esto ya pasó (y no fue barato). No estamos hablando de algo teórico. Casos como Kaseya mostraron cómo comprometer un solo proveedor puede afectar a cientos de empresas en cadena. Otros incidentes han generado pérdidas de millones. No es porque las empresas sean incompetentes. Es porque el modelo actual de desarrollo está basado en confianza distribuida. Y esa confianza… es frágil.
El error que veo en casi todas las empresas
Te lo digo directo porque lo veo en clientes todo el tiempo. La seguridad se trata como un gasto incómodo. Algo que se agrega “después”. Algo que se ve si sobra presupuesto. Algo que se posterga. Hasta que pasa algo. Y cuando pasa, ya es tarde. Es como manejar sin seguro. Mientras no choques, todo bien. El problema es que el día que pasa, te cambia el negocio entero y ya no tenés vuelta atrás. Ahí es donde te replanteás por qué no le hiciste caso a esa persona o a ese artículo que te recomendó prestar atención a la seguridad digital de tu negocio o emprendimiento.
Acá hay un cambio de mentalidad que todavía no termino de bajar. Ya no alcanza con “mi código está bien”.
Tienes que pensar en:
- Tus dependencias
- Tus repositorios
- Tus pipelines
- Tus integraciones
- Tus proveedores
Porque cualquiera de esos puntos puede ser la puerta de entrada.
Y lo más complicado es que muchas veces no depende directamente de ti.
El problema no es técnico. Es estratégico. Porque cada punto donde no hay control es un punto donde el ataque avanza. Nadie audita dependencias, nadie valida lo que entra en CI/CD, nadie monitorea integridad en serio, todos corremos para cumplir deadlines imposibles con el equipo más reducido para ser lo más eficientes con nuestros costos operativos y nadie tiene un plan cuando algo falla y ahí es donde se rompe todo. No cuando hackean. Cuando nadie estaba mirando.
Lo que hacemos distinto en Metamorfosis 360
Esto no se resuelve con “instalar un plugin de seguridad” o cruzar los dedos.
En Metamorfosis 360 trabajamos sobre los puntos donde realmente pasan estas cosas:
- Revisamos dependencias críticas (no a nivel superficial)
- Analizamos cómo se están desplegando los proyectos
- Detectamos comportamientos anómalos antes de que escalen
- Y armamos estructura para que, si algo pasa, no te explote todo
No es paranoia. Es control.
Si esto no te preocupa, debería. No hace falta que te pase para que te afecte. Ese es el problema de los ataques a la cadena de suministro. Cuando explotan, ya es tarde para reaccionar.
La pregunta no es si estás seguro.
La pregunta es: ¿Sabés realmente qué está corriendo dentro de tu propio sistema?
Sobre el autor
Este artículo fue escrito por Santiago Leston, Técnico Superior en Programación, con más de 10 años de experiencia trabajando en desarrollo web, aplicaciones mobile y seguridad informática.
A lo largo de su carrera trabajó con empresas y proyectos donde la estabilidad, la performance y la seguridad no son opcionales. Hoy forma parte de Metamorfosis 360, donde se enfoca en detectar riesgos reales antes de que se conviertan en problemas de negocio.
Su enfoque no es teórico. Es práctico: entender cómo funcionan los sistemas en producción y dónde realmente se rompen.
