Blog Por qué retrasar las actualizaciones de software pone en riesgo a tu empresa | Insight

Un colega soltó esto en un chat de grupo el otro día con una aprobación rotunda:

«Siento que mi trabajo a tiempo completo es instalar actualizaciones».

¿Molesto? Sí. ¿Disruptivo para avanzar realmente en el trabajo? Sin duda alguna. ¿Necesario? Al 100 %. Innegociable. Y ahora mismo, más urgente que nunca.

He aquí por qué.

¿Qué es Project Glasswing?

La razón por la que tus notificaciones de actualización son incesantes en este momento no es casual. No se trata de que los proveedores estén limpiando por fin el historial de mantenimiento pendiente. Es el resultado directo de algo llamado Project Glasswing.

El 7 de abril de 2026, Anthropic anunció que había desplegado silenciosamente su modelo de IA más potente, Claude Mythos Preview, no al público, sino a una coalición controlada de empresas que gestionan la infraestructura de software más crítica del mundo: Amazon, Apple, Cisco, CrowdStrike, Google, Microsoft, Palo Alto Networks y aproximadamente otras 40. La misión era totalmente defensiva: utilizar Mythos para encontrar vulnerabilidades antes de que los actores maliciosos pudieran hacerlo.

Lo que descubrió fue asombroso.

En cuestión de semanas, Mythos identificó miles de vulnerabilidades críticas y previamente desconocidas en todos los principales sistemas operativos y navegadores, incluidos fallos que habían estado ocultos a plena vista durante años, a veces décadas. Un error de 27 años de antigüedad en OpenBSD, ya parcheado y considerado durante mucho tiempo como uno de los sistemas operativos más robustos en seguridad, permitía a un atacante remoto colapsar cualquier máquina que lo ejecutara simplemente conectándose a ella. Una vulnerabilidad de 16 años de antigüedad en FFmpeg, la biblioteca de codificación de vídeo que sustenta casi todas las principales plataformas de vídeo, sobrevivió a años de intensa investigación de seguridad sin ser detectada (también parcheada). El equipo de red team de Anthropic lo documentó ellos mismos: estos errores no eran descuidos sutiles en código secundario. Estaban en el software que ejecutas todos los días.

Los proveedores reciben ahora las divulgaciones según un calendario estrictamente controlado y compiten a contrarreloj para lanzar parches. ¿Esa oleada de notificaciones de actualización? Es eso. Esa es la respuesta.

Por qué los retrasos en los parches aumentan tu riesgo en este momento

Siempre ha existido una brecha entre el momento en que se divulga una vulnerabilidad y el momento en que un atacante puede convertirla en un arma. Esa ventana se está reduciendo rápidamente.

El propio Mythos demostró la rapidez con la que puede avanzar el desarrollo de exploits cuando la IA se encarga del trabajo. El mismo modelo que encontró de forma autónoma un error de 27 años en OpenBSD también escribió 181 exploits funcionales para Firefox en una sola ejecución de prueba, en comparación con los 2 de la generación anterior de modelos de IA. Los defensores que están acostumbrados a medir el tiempo de respuesta en días o semanas operan ahora en un entorno diferente. Una vez que un parche es público, el reloj empieza a correr, y las personas del otro lado no van a esperar a la próxima ventana de mantenimiento de tu equipo de TI.

Suena alarmista. Pero la respuesta correcta aquí no es el pánico.

«No creo que Mythos sea un momento para entrar en pánico, sino más bien una llamada de atención», afirma Will Pocknell, director sénior de TI, Seguridad y Cumplimiento en Insight. «Los equipos de TI, desarrollo y seguridad llevan tiempo viendo la necesidad de aumentar la velocidad de entrega de parches, actualizaciones y correcciones, pero ahora estamos en un mundo en el que eso es una "obligación" en lugar de una aspiración».

La gestión de parches ha vivido en la columna de las aspiraciones durante mucho tiempo. Ciclos de despliegue más rápidos, ventanas más estrechas entre el lanzamiento y el despliegue, no permitir que los usuarios finales pospongan las actualizaciones críticas: estos eran objetivos en la hoja de ruta, no requisitos en el calendario.

Esa conversación ha terminado.

Cómo cerrar la brecha en el despliegue de parches

La pregunta más difícil es cómo operativizar la urgencia a escala, especialmente cuando el «más tarde» está grabado en la memoria muscular de cualquiera que haya hecho clic alguna vez en esa pequeña X de una notificación de actualización.

Algunas cosas que vale la pena hacer ahora:

Saber qué estás parcheando. Tu mayor exposición se encuentra en la infraestructura crítica y el software principal: navegadores, endpoints, sistemas operativos y cualquier cosa orientada a Internet. Si no tienes una imagen clara y actualizada de lo que estás ejecutando y qué sistemas están recibiendo divulgaciones de vulnerabilidades activas, esa es la primera brecha que debes cerrar.

Reducir el ciclo de vida del despliegue. El tiempo transcurrido entre «parche disponible» y «parche desplegado» es tu ventana de exposición. La antigua cadencia semanal o mensual ya no se ajusta al entorno de amenazas. Esta es la métrica que importa, y la que ha cambiado de forma más drástica con la llegada del desarrollo de exploits asistido por IA.

Dejar de permitir aplazamientos en parches críticos. La opción de «recordármelo mañana» debe desaparecer para las actualizaciones de alta gravedad. Establecer expectativas con los usuarios finales importa tanto como el despliegue técnico: la gente se resiste menos cuando entiende por qué ha cambiado la política.

Pensar con claridad en lo que gestionas frente a lo que subcontratas. La conversación sobre los servicios gestionados de endpoints está cobrando fuerza en este momento por una razón. Mantener el ritmo de una oleada coordinada de parches de múltiples proveedores en toda una organización, con plazos de explotación reducidos, no es una tarea secundaria. Es una tarea principal.

Mi colega no se equivocaba. Las actualizaciones son incesantes en este momento, y probablemente sigan así durante un tiempo. Estamos en medio de una respuesta de parcheo como ninguna otra que la industria haya visto a esta escala o velocidad.

Lo que Mythos reveló no es solo una lista de errores. Es algo más inquietante: las vulnerabilidades siempre han estado ahí. Ocultas en software en el que hemos confiado durante años, invisibles para herramientas que las examinaron millones de veces. La diferencia ahora es que las conocemos y tenemos una vía para solucionarlas.