Si has seguido las noticias este año, probablemente ya notaste que varias cosas están pasando al mismo tiempo. Los repositorios de paquetes se están convirtiendo en armas — npm ha visto oleada tras oleada de gusanos auto-propagables que roban credenciales. La propia infraestructura y los mecanismos de confianza de GitHub han sido abusados para distribuir malware. La inteligencia artificial está escribiendo más código que en cualquier momento de la historia — y, a la vez, está siendo usada para construir los ataques. Hay guerras en Ucrania y en Medio Oriente. Carteles y fuerzas de seguridad pelean a cielo abierto. Estados fallidos como Corea del Norte hackean abiertamente, como parte de su presupuesto nacional.
Es tentador archivar todo esto como titulares separados. No lo son. Son el mismo fenómeno visto desde ángulos distintos: el costo de atacar se desplomó, y la distancia que antes te protegía ya no existe.
El modelo mental del siglo XX está muerto
Durante casi todo el siglo pasado, una guerra al otro lado del mundo no te tocaba. Estaba “muy lejos”. La geografía era un escudo. Un conflicto en otro hemisferio era problema de alguien más, separado de tu negocio por un océano y una frontera.
Internet borró las fronteras. La IA masificó el blast radius.
Un atacante ya no necesita estar cerca de ti, hablar tu idioma, ni siquiera saber que existes. Herramientas automatizadas — cada vez más escritas y operadas con IA — escanean todo el internet de forma continua, prueban miles de millones de pares de credenciales robadas y fabrican phishing convincente a escala industrial. La IA se volvió el arma termonuclear de la guerra digital: no hace al atacante más inteligente, sino que vuelve los ataques infinitamente más baratos de lanzar e infinitamente más amplios en alcance. Las guerras digitales son un campo de batalla real, y ese campo de batalla no tiene edición de ultramar. Corre sobre la misma nube, los mismos repositorios y las mismas dependencias que tú despachas a producción.
“No somos un objetivo” es la falacia peligrosa
Esta es la frase que escucho de dueños de negocio, CTOs y CISOs en nuestra región, y me preocupa cada vez: “De eso se preocupan Google, Microsoft o Apple, porque eso es allá en USA o en Europa. Somos muy pequeños para ser un objetivo.”
Es exactamente al revés.
A un grupo de operadores norcoreanos no le va a temblar el pulso ni un segundo para robarte la identidad, extraer tus credenciales de AWS y levantar miles de máquinas virtuales de muchos núcleos a minar criptomonedas — cripto que paga los misiles de Kim. No les importa qué hace tu empresa, dónde está, ni lo pequeña que se sienta. Para un roba-credenciales automatizado, no eres una empresa con una misión. Eres un set válido de llaves de la nube.
Decir “no somos un objetivo” en este campo de batalla es como pararte en el frente y anunciar que vas a salir a jugar pelota, porque tú no eres un objetivo militar. La guerra es la guerra. En un campo de batalla digital no hay civiles — solo sistemas endurecidos y sistemas que no lo están.
Lo vimos de cerca
Para nosotros esto no es teoría. A una empresa con la que trabajamos de cerca le robaron sus credenciales de la nube. En un solo fin de semana, el atacante usó esas llaves para levantar cerca de 3.600 máquinas virtuales de 128 núcleos cada una y las apuntó todas a minar cripto. Para el lunes la factura superaba los US$60.000 — cargos de los que la empresa era responsable. Uno de nuestros ingenieros pasó el fin de semana entero recuperando el control de la cuenta, apagándolas máquina por máquina, y después trabajamos con AWS para negociar y bajar la factura. El daño se contuvo, pero lo sentimos en tiempo real.
El punto de entrada no fue un zero-day de película. Fue una sola puerta olvidada: un set de credenciales que debió haberse desactivado, sin autenticación de múltiples factores. El tipo de puerta que cualquier organización puede dejar abierta sin darse cuenta — y ese es justamente el punto. El atacante no rompió un muro. Entró por una puerta que nadie estaba mirando.
Para mí también es personal. Hace años — en 2019 — las credenciales de un SaaS que usaba fueron comprometidas. El proveedor nunca le avisó a nadie. Como yo había reusado esa contraseña en otros lados, los atacantes la probaron de inmediato contra mi Gmail, mi LinkedIn, mis otras cuentas. Lo que me salvó fue una alerta de inicio de sesión que llegó a tiempo. Desde ese día uso una contraseña distinta para cada servicio, guardada en un gestor de contraseñas (Bitwarden), con MFA en todo. Eso fue hace años, y la amenaza solo se ha acelerado desde entonces.
Por qué es peor ahora, técnicamente
Tres cambios se potencian entre sí:
La IA desplomó el costo de atacar. El cred-stuffing, el phishing y el descubrimiento de vulnerabilidades que antes requerían esfuerzo humano experto ahora corren de forma automática, a escala, las 24 horas, contra todos — incluyéndote a ti.
La cadena de suministro convirtió tus dependencias en una superficie de ataque. Esta es la parte que demasiados equipos subestiman. Los gusanos de npm no fueron el final — fueron la punta del iceberg. Empezó por npm porque JavaScript tiene uno de los ecosistemas de dependencias más usados del planeta, lo que significa el mayor blast radius. El mismo modelo amenaza a cada gestor de paquetes detrás: Composer (PHP), módulos de Go, PyPI (Python), y más.
Y ya no es hipotético para PHP. El 22 de mayo de 2026, un ataque de cadena de suministro golpeó los populares paquetes Composer de laravel-lang — 233 versiones comprometidas — abusando del sistema de tags de GitHub para apuntar las etiquetas de versión a un fork malicioso. El payload era un roba-credenciales de dos etapas que cosecha exactamente lo que temerías: llaves de AWS, GCP y Azure, llaves SSH, contraseñas guardadas en el navegador, wallets de cripto, credenciales de Docker y de Kubernetes. Una sola dependencia envenenada, traída por un composer update, yendo directo por tus llaves de la nube — las mismas llaves que, en la historia de arriba, se volvieron 3.600 máquinas minando.
Y piensa en la raíz de la confianza misma. Cuando una plataforma tan central como GitHub es vulnerada y tranquiliza a todos diciendo que “solo se afectaron nuestros repositorios internos — los repos de los clientes están seguros”, eso no debería calmarte del todo. Esos repositorios internos son el software que hace funcionar la plataforma de la que todos dependemos. ¿Cuánto falta para que un bug descubierto en el código interno de GitHub sea convertido en arma para alcanzar los repositorios de los clientes — y los ataques de cadena de suministro vivan no en un puñado de paquetes envenenados, sino en todos los repos? La frontera entre “sus sistemas internos” y “tu código” es mucho más delgada de lo que sugiere la tranquilidad que ofrecen.
El reuso de credenciales más la falta de MFA es la verdadera puerta de entrada. No el exploit cinematográfico — la brecha aburrida y humana. La mayoría de las brechas entran por una contraseña reusada, un token filtrado o una cuenta que nadie desactivó.
Cuando “mantente actualizado” deja de ser seguro
Hay una ruptura más profunda aquí, casi filosófica. Durante toda la historia del software, la regla cardinal fue simple: mantente al día — la versión más reciente es la más segura, porque trae los últimos parches. Los ataques de cadena de suministro invierten esa regla. Cuando el ataque vive dentro de una versión recién publicada — un release envenenado de laravel-lang, una actualización de npm troyanizada — traer la última versión es precisamente cómo te comprometes. Por primera vez a escala, estar actualizado puede ser lo que te vuelve vulnerable. Y no se detiene en librerías pequeñas: la misma lógica alcanza al kernel de Linux y a los proyectos FOSS más grandes del planeta — el código que corre silenciosamente debajo de casi todo. Cuando el cimiento mismo es un vector potencial, “solo actualiza” ya no es una estrategia por sí sola.
Lo que esto revela es incómodo pero esclarecedor. En una guerra de cadena de suministro, la seguridad deja de ser un producto que compras y se vuelve una cuestión de alianzas y círculos de confianza — igual que funciona la confianza en tiempos de guerra. ¿Quién mantiene este paquete? ¿Quién firmó este release? ¿De quién verificas realmente la procedencia? ¿Cuáles dependencias se ganaron tu confianza, y cuáles adoptaste solo porque eran convenientes? Defender el software moderno significa curar ese círculo deliberadamente: fijar y revisar dependencias, verificar firmas y procedencia, minimizar lo que incorporas, y conocer a los humanos detrás del código que ejecutas.
Como ingenieros, estamos en el frente
Este es el cambio que quiero que cada dueño, CTO y CISO interiorice: la seguridad digital dejó de ser “el problema de Google, Microsoft y Apple allá”. Si escribes, despliegas u operas software, estás en el frente, te hayas ofrecido o no. Prepararse y entrenarse para esto ya no es higiene opcional; es el trabajo.
No lo digo para asustar a nadie. Lo digo porque esto se va a poner peor antes de mejorar, y porque la diferencia entre verse afectado y ser daño colateral es la preparación. Es cuestión de días — no de años — para que empecemos a ver casos muy cerca de nosotros: gente que conocemos golpeada por hackeos, estafas y robos digitales.
La buena noticia es que la disciplina que te protege es, en su mayoría, poco glamorosa y está a tu alcance hoy: autenticación de múltiples factores en todo, una contraseña única por servicio en un gestor de contraseñas, accesos de mínimo privilegio, desactivación inmediata de las cuentas de empleados que se van, auditorías periódicas de credenciales, fijado y revisión de dependencias, e infraestructura descrita como código que puedas auditar de verdad — sin cajas negras, sin nada que solo una persona entienda. Ese último principio es lo que llamamos la Caja de Vidrio, y existe precisamente para que, cuando el campo de batalla te alcance, puedas ver cada puerta y saber cuáles están cerradas.
La guerra es digital, y ya está aquí. La única pregunta real es si la vas a enfrentar preparado.