Durante décadas, la seguridad de software tuvo un problema central: encontrar las vulnerabilidades. Los equipos de seguridad eran pocos, los sistemas enormes y muchas fallas pasaban años sin que nadie las viera.
En 2026 ese problema empezó a cambiar de forma radical. Y, como suele pasar, resolver un cuello de botella dejó al descubierto el siguiente.
Qué es Project Glasswing
El 7 de abril de 2026, Anthropic lanzó Project Glasswing, una iniciativa para usar IA avanzada en la defensa del software crítico antes de que capacidades similares queden en manos de atacantes.
En el centro del proyecto está Claude Mythos Preview, un modelo con una capacidad inédita para encontrar y analizar vulnerabilidades de software, comparable a la de los especialistas de seguridad más avanzados. Por ese mismo potencial ofensivo, su acceso es restringido: solo lo usan organizaciones seleccionadas y con fines defensivos.
Entre los socios de lanzamiento están AWS, Apple, Cisco, CrowdStrike, Google, JPMorganChase, Microsoft, NVIDIA, Palo Alto Networks y la Linux Foundation, además de unas 40 organizaciones que mantienen software crítico, entre ellas Cloudflare y Visa. En junio, la iniciativa se amplió a unas 200 organizaciones en más de 15 países, incluidos operadores de infraestructura crítica.
Algunos hallazgos muestran la magnitud del cambio:
- Una vulnerabilidad de 27 años en OpenBSD, uno de los sistemas operativos considerados más seguros.
- Una falla de 16 años en FFmpeg, una librería de video que se usa en todas partes, que había sobrevivido a más de 5 millones de pruebas automatizadas.
10.000 vulnerabilidades en un mes
En su primera actualización, a fines de mayo, Anthropic informó que los socios de Glasswing habían identificado más de 10.000 vulnerabilidades de severidad alta o crítica en sus sistemas.
La cifra impresiona, pero hay otra que es más reveladora. En proyectos de código abierto, de 530 vulnerabilidades altas o críticas reportadas a sus mantenedores, solo 75 habían sido corregidas al momento del informe, y cada corrección tomaba en promedio dos semanas. Algunos mantenedores incluso pidieron que les reportaran fallas más lento, porque no daban abasto.
Anthropic lo resumió así: “el cuello de botella en ciberseguridad ahora es verificar, divulgar y parchar” la gran cantidad de vulnerabilidades que estos modelos pueden encontrar.
Encontrar dejó de ser lo difícil. Corregir se volvió el problema.
La tentación: corregir más rápido
La reacción natural es acelerar las correcciones. Si la IA puede encontrar las fallas, ¿por qué no dejar que también escriba los parches?
Cloudflare lo intentó y contó el resultado con franqueza en su blog:
Lo aprendimos cuando dejamos que el modelo escribiera sus propios parches y vimos que algunos salieron a producción corrigiendo el error original, mientras rompían silenciosamente algo de lo que el código dependía.
Y agregó una advertencia que cualquier equipo de desarrollo debería tener presente:
Parchar más rápido no cambia la forma del proceso que produce el parche. Si las pruebas de regresión toman un día, no se puede llegar a un plazo de dos horas sin saltárselas, y los errores que se publican al saltarse esas pruebas suelen ser peores que los que se intentaba corregir.
Es decir, un parche que cierra una puerta pero abre otra no reduce el riesgo, solo lo cambia de lugar.
Visa: medir la capacidad de adaptarse
Visa, otro participante de Glasswing, llegó a una conclusión similar y la convirtió en un indicador: Mean Time to Adapt (MTTA), el tiempo que le toma a un equipo confirmar que una vulnerabilidad es realmente explotable, corregirla y validar que la corrección funciona en producción.
Su tesis es directa:
Encontrar vulnerabilidades ya no es lo difícil. El verdadero desafío es qué tan rápido un equipo puede confirmar que un problema es realmente explotable, corregirlo y luego demostrar que el camino de ataque quedó cerrado.
El cambio de indicador es significativo. Ya no se trata de cuántas vulnerabilidades se encuentran ni de cuántos parches se aplican, sino de cuánto tarda la organización en cerrar el riesgo de verdad, sin generar uno nuevo.
Por qué corregir es más difícil que encontrar
Para encontrar una vulnerabilidad basta con analizar un componente. Para corregirla bien hay que entender todo lo que lo rodea:
- Qué depende de ese código: Otros módulos, servicios o procesos que podrían verse afectados por el cambio.
- Cuál es la mejor corrección: A menudo hay varias formas de cerrar una falla, y no todas tienen el mismo impacto en el resto del sistema.
- Qué hay que volver a probar: Sin una revisión de regresiones, no hay forma de saber si el parche rompió algo.
- Quién aprueba y qué queda registrado: En sectores regulados, como la banca, cada cambio en producción tiene que ser trazable.
Es el mismo desafío del que hemos escrito antes: el problema no es la velocidad, es el contexto. Un parche escrito sin conocer el sistema completo es una apuesta.
Cómo lo abordamos en Tinet: remediar con contexto
En esa brecha entre encontrar y corregir es donde se enfoca Tinet.
Junto a un banco de primera línea en la región, cuyo nombre no podemos revelar por un acuerdo de confidencialidad, abordamos vulnerabilidades detectadas con Mythos. No usamos un escáner más: usamos Suite Loica para llevar cada hallazgo hasta una corrección segura.
- GenDEV: decidir cómo corregir. Por cada vulnerabilidad, GenDEV evaluó la mejor forma de corregirla rápido y con el menor impacto posible en las plataformas del banco. Para eso trabaja sobre la KDB, la memoria de la empresa, que contiene el código, las reglas y las dependencias de los repositorios del cliente y vive solo en su infraestructura. Así, cada propuesta de corrección se valida contra el código real: qué componentes toca, qué depende de ellos y qué se puede ver afectado.
- GenQA: comprobar que no se rompió nada. Una vez implementada la corrección, GenQA aceleró la revisión de regresiones. Prueba la aplicación como lo haría un usuario, verifica que el parche funcione correctamente, confirma que el resto de la plataforma sigue operando y deja evidencia en fotos y video de cada prueba.
- Personas que aprueban en cada etapa. Loica propone y el equipo decide. Cada corrección pasa por la revisión y aprobación de especialistas, y cada cambio guarda su historia: qué se corrigió, por qué, quién lo aprobó y cómo se validó.
Así cubrimos las tres cosas que Visa y Cloudflare identificaron como críticas: corregir con conocimiento del sistema, probar que no hubo efectos colaterales y dejar trazabilidad de todo el proceso.
Tres preguntas para hacerse esta semana
- ¿Cuánto tarda hoy su organización en cerrar una vulnerabilidad crítica? No en detectarla: en corregirla, probarla y desplegarla. Ese es su Mean Time to Adapt.
- ¿Qué pasaría si mañana recibiera cien hallazgos críticos? Si su proceso de corrección no escala, más detección solo significa más pendientes.
- ¿Cómo sabe que un parche no rompió otra cosa? Si la respuesta depende de la memoria de alguien o de pruebas manuales parciales, ahí está el riesgo.
Para cerrar
Project Glasswing marca un punto de inflexión. La IA ya encuentra vulnerabilidades más rápido de lo que las organizaciones pueden corregirlas. Esa brecha es hoy uno de los principales riesgos de seguridad para cualquier empresa con software crítico.
La ventaja ya no está en encontrar más vulnerabilidades. Está en poder cerrarlas antes de un posible ataque, con contexto, trazabilidad y control.
Si quiere revisar cómo está hoy su capacidad de remediación, le proponemos 45 minutos con nuestro equipo, sobre su realidad y sin presentaciones. La primera conversación es un diagnóstico, no una demo.
Fuentes: Anthropic, "Project Glasswing" (abril 2026), "Project Glasswing: An initial update" (mayo 2026) y "Expanding Project Glasswing" (junio 2026); Cloudflare, "Project Glasswing: what Mythos showed us" (mayo 2026); Visa, "Visa Releases Its AI-Powered Cyber Defense System to Open Source" (junio 2026).
