Project Glasswing update: what the evidence says about AI-driven vulnerability discovery

Qué cambió después de la primera actualización de Glasswing

La actualización inicial de Anthropic señala que, tras aproximadamente un mes, Anthropic y cerca de 50 socios del Proyecto Glasswing habían utilizado Claude Mythos Preview para identificar más de 10,000 vulnerabilidades de severidad alta o crítica en software considerado de importancia sistémica. Anthropic también informa que varios socios aumentaron su tasa de detección de fallas de seguridad en más de diez veces.

Esas son afirmaciones de gran alcance, y deben leerse con la misma cautela que aplicamos en nuestra publicación anterior. Las estimaciones de severidad dependen del contexto; muchos hallazgos permanecen dentro de los periodos de divulgación coordinada, y la evaluación inicial de un modelo no equivale a una vulnerabilidad confirmada por el mantenedor. Aun así, la nueva actualización es más concreta que el anuncio inicial. Incluye ejemplos de socios, estadísticas de escaneo de código abierto, un panel de divulgación y referencias de benchmarks que se pueden inspeccionar a lo largo del tiempo.

En un anuncio posterior que expande el Proyecto Glasswing, Anthropic declaró que el programa va más allá de su cohorte inicial de aproximadamente 50 socios y está ampliando el acceso a cerca de 150 organizaciones adicionales. El nuevo grupo supuestamente abarca más de 15 países e incluye sectores que estaban menos representados en el lanzamiento, como energía, agua, atención médica, comunicaciones y hardware. Esta expansión cambia la escala de la ambición del proyecto: Glasswing ya no se presenta únicamente como un experimento defensivo con grandes empresas tecnológicas, sino como un intento de llevar las capacidades de su modelo a organizaciones cuyo software o infraestructura podría afectar a poblaciones muy grandes de resultar comprometido.

Hasta ahora, las cifras públicas más interesantes provienen del trabajo de código abierto de Anthropic. Según la actualización, Mythos había escaneado más de 1,000 proyectos de código abierto y generado 23,019 hallazgos candidatos, incluidos 6,202 inicialmente estimados como altos o críticos. Un subconjunto de 1,752 hallazgos de severidad alta o crítica había sido evaluado por firmas de seguridad externas o por el personal de Anthropic; de esos, el 90.6% se consideró como verdaderos positivos válidos, y el 62.4% se confirmó como alto o crítico después de la revisión.

Eso suena impresionante, pero la estructura del embudo de procesamiento importa más que la cifra del titular. En el panel de divulgación coordinada de vulnerabilidades, el embudo se estrecha bruscamente: los hallazgos candidatos se convierten en hallazgos revisados externamente, los hallazgos revisados se convierten en vulnerabilidades confirmadas, las vulnerabilidades confirmadas pasan a ser reportes para los mantenedores y solo un subconjunto mucho más pequeño se convierte en software parcheado con advertencias públicas. Por supuesto, esta caída no significa un fracaso para el proyecto. Es evidencia del trabajo real requerido para hacer útil el resultado de seguridad generado por IA.

Quizá el panel sea más importante para AppSec que el anuncio mismo, porque convierte una afirmación sobre las capacidades de un modelo en un flujo de trabajo observable: candidato, triado, validado, reportado, reconocido, parcheado y advertido públicamente. Ese es el tipo de estructura que la industria necesitará si el descubrimiento asistido por IA se vuelve algo habitual. Sin un registro, una cola, una revisión de severidad, comunicación con los mantenedores y un seguimiento de parches, decir "encontramos miles de vulnerabilidades" no constituye un resultado de seguridad valioso; es simplemente una acumulación de trabajo pendiente.

El proceso de divulgación de Anthropic ahora es parte de la historia

Una de las medidas responsables que ha tomado Anthropic es publicar una política de divulgación coordinada para las vulnerabilidades descubiertas a través de Claude. La política tiene como objetivo seguir la regla estándar de divulgación de 90 días, o la divulgación pública después de que se lance un parche, con posibles extensiones cuando los mantenedores estén trabajando activamente en una solución. Para vulnerabilidades críticas explotadas activamente, Anthropic describe un plazo mucho más corto: se espera un parche o mitigación en un plazo de 7 días, con la posibilidad de una breve extensión.

La política también plantea un punto importante sobre el ritmo: Anthropic tiene como objetivo proporcionar reportes revisados por humanos, con soluciones sugeridas cuando sea posible, y regular el volumen de envíos según lo que los mantenedores puedan manejar. Ese último aspecto no es cosmético. Si los sistemas de IA aumentan el ritmo de descubrimiento mucho más rápido de lo que los mantenedores pueden priorizar y parchear, la divulgación no coordinada podría convertirse en otra forma de presión para el ecosistema.

Por lo tanto, el Proyecto Glasswing opera en un término medio difícil. Por un lado, demorar demasiado la divulgación deja a los usuarios expuestos a vulnerabilidades que otros podrían descubrir de forma independiente. Por otro lado, divulgar demasiado rápido puede abrumar a los mantenedores y dar a los atacantes detalles útiles antes de que las soluciones estén listas e implementadas. Este no es un problema que solucione Mythos. Es un problema que Mythos hace visible a escala.

La expansión de Anthropic también aclara que el acceso sigue siendo una cuestión de gobernanza central. La compañía dice que está trabajando para lograr un acceso generalizado a capacidades del nivel de Mythos, pero solo después de desarrollar salvaguardas lo suficientemente sólidas como para prevenir el uso indebido, un problema que admite aún no ha sido resuelto por Anthropic ni, que se sepa, por otros desarrolladores de IA. Mientras tanto, planea expandir aún más el Proyecto Glasswing y escalar un Programa de Verificación Cibernética para poner su modelo a disposición de más organizaciones para tareas defensivas específicas.

El arnés importa tanto como el modelo

Varios informes de socios de Anthropic dentro de Glasswing coinciden en una lección que debería resultar familiar para los equipos de AppSec: un modelo potente no es suficiente; necesita un arnés sólido.

El análisis de Cloudflare es uno de los ejemplos más claros. Describe un flujo de procesamiento que no se limita a asignar un agente genérico de revisión de código a un repositorio y pedirle que encuentre errores. En su lugar, el proceso crea un contexto de arquitectura, divide el trabajo en tareas estrechas, ejecuta múltiples agentes en paralelo, valida los hallazgos mediante pruebas adversarias, desduplica las causas raíz, rastrea si una falla es alcanzable desde fuera del sistema y convierte el resultado en reportes estructurados.

Esto es importante porque los agentes de codificación genéricos están optimizados para un tipo de trabajo diferente. Son buenos para mantener un flujo de contexto enfocado mientras construyen, corrigen o refactorizan. El análisis de vulnerabilidades, por el contrario, a menudo requiere muchas hipótesis específicas en numerosos archivos, límites de confianza y clases de ataque. Un único agente de ejecución prolongada que "busca vulnerabilidades" en un repositorio grande puede generar ideas interesantes, pero no proporcionará una cobertura significativa. Un arnés le da forma al trabajo.

La experiencia de Mozilla fortaleciendo Firefox cuenta una historia similar. Experimentos anteriores con auditorías de código mediante LLM mostraron potencial pero generaron demasiados falsos positivos para ser escalados. Según Mozilla, los arneses basados en agentes cambiaron ese panorama porque podían crear y ejecutar casos de prueba reproducibles, probando hipótesis de manera dinámica en lugar de dejar informes especulativos en la cola de triaje. Mozilla luego construyó su propio pipeline sobre la infraestructura de fuzzing existente, paralelizó trabajos en máquinas virtuales efímeras e integró los resultados con el ciclo de vida de los errores de seguridad de Firefox: desduplicación, seguimiento, triaje, corrección, pruebas y gestión de lanzamientos.

Este es un punto clave para los programas de seguridad de aplicaciones. La unidad útil no es el "resultado del modelo". La unidad útil es un hallazgo validado que ha sido reproducido, evaluado en contexto, asignado a una parte responsable, remediado de manera segura y verificado. Los modelos pueden acelerar partes de ese proceso, pero no eliminan la necesidad de llevarlo a cabo.

Anthropic también ha declarado que está ampliando los casos de uso defensivos asociados con modelos como Mythos, incluyendo la escritura de parches, verificaciones previas al lanzamiento, pruebas de penetración, detección y respuesta automatizada ante amenazas, e incluso la reconstrucción de bases de código heredadas en lenguajes seguros para la memoria. Estas tareas no deben tratarse como una única capacidad de seguridad de IA genérica; cada una requiere su propio arnés, controles, métricas de éxito y revisión humana.

El descubrimiento está mejorando, pero la validación sigue siendo donde el riesgo se hace real

La evaluación de XBOW añade otra distinción útil. La firma descubrió que Mythos es particularmente fuerte en la auditoría de código fuente y el razonamiento técnico, especialmente cuando el código fuente está disponible. Sin embargo, también enfatizó que la validación en sitios en vivo sigue siendo un desafío. Muchos problemas explotables no son obvios únicamente en el código de la aplicación; surgen de decisiones de despliegue, configuraciones, dependencias, permisos y la forma en que componentes aparentemente seguros interactúan en producción.

La misma evaluación también señala que el juicio del modelo es un área con resultados mixtos. Mythos puede reducir los falsos negativos en algunos entornos y producir análisis técnicos precisos, pero aún puede ser excesivamente conservador, demasiado literal o inconsistente en su razonamiento sobre la seguridad de los comandos. Esto no es sorprendente. El trabajo de seguridad está lleno de decisiones de juicio: si una vulnerabilidad es alcanzable, si es seguro ejecutar una prueba de concepto, si una calificación de severidad coincide con el modelo de amenazas de un proyecto y si una corrección altera el comportamiento de formas inaceptables. Un modelo puede ser de gran ayuda, pero no puede reemplazar una revisión responsable.

La capacidad de explotación se está midiendo con mayor seriedad

Uno de los desarrollos más significativos para los defensores de la ciberseguridad es la aparición de benchmarks más sólidos para el desarrollo de exploits. El blog de Frontier Red Team de Anthropic analiza ExploitBench y ExploitGym, siendo el primero particularmente útil porque no trata la explotación como un único evento de aprobado/reprobado. En su lugar, la divide en etapas: alcanzar el código vulnerable, reproducir la vulnerabilidad, construir primitivas de explotación específicas del objetivo, construir primitivas genéricas que escapen de los límites de aislamiento y, finalmente, lograr la ejecución arbitraria de código.

Esta distinción importa: una falla no es lo mismo que un exploit. Alcanzar una función vulnerable no es lo mismo que obtener el control de un sistema. Una prueba de concepto puede revelar la existencia de un error sin probar que un atacante pueda convertirlo en un impacto significativo. ExploitBench intenta medir todo el proceso, en lugar de un solo paso.

En el benchmark V8 de ExploitBench, Anthropic informa que Mythos logró la ejecución arbitraria de código en 21 de 41 entornos de CVE al combinar la variante de referencia (sin guía adicional específica de la vulnerabilidad) con la variante guiada (una breve pista que orienta al modelo hacia el área vulnerable). Ningún otro modelo logró la ejecución arbitraria de código ni una sola vez en ninguna de las variantes, excepto a través de un andamiaje propietario, que lo logró en dos casos. El análisis de Anthropic sobre las evaluaciones de exploits enmarca esto como parte de una necesidad más amplia de medir qué tan lejos pueden llegar los modelos desde el descubrimiento de la vulnerabilidad hasta la explotación funcional, en lugar de tratar todo progreso parcial como equivalente.

Esta es una de las partes más serias de la actualización. Sugiere que la brecha de capacidad no se refiere solo a encontrar defectos, sino también a progresar desde los defectos hasta los exploits. Para los defensores, esto reduce el tiempo disponible entre que un parche se hace público, un atacante comprende la vulnerabilidad subyacente y la viabilidad práctica del código del exploit. También refuerza por qué importan los tiempos de prueba y despliegue de parches; si la construcción de exploits se vuelve más barata, el costo de una remediación lenta aumenta.

Los resultados del AISI sugieren un rápido avance de capacidades, con incertidumbre

El Instituto de Seguridad de IA del Reino Unido (AISI) ofrece una perspectiva más amplia sobre las capacidades. Su conjunto de tareas de ciberseguridad estima la duración de las tareas que los modelos de frontera pueden completar de forma autónoma con un umbral de confiabilidad determinado. En febrero de 2026, el AISI estimó que el "horizonte temporal" de ciberseguridad con un 80% de confiabilidad se había duplicado cada 4.7 meses desde finales de 2024. Mythos Preview y GPT-5.5 luego superaron significativamente esa tendencia en las pruebas del AISI.

El AISI es cuidadoso con la incertidumbre. Sus tareas no son intrusiones completas del mundo real contra sistemas defendidos. Las tareas más largas son pocas, las líneas de base humanas (los resultados de referencia obtenidos cuando los humanos realizan las mismas tareas del benchmark) son imperfectas, los presupuestos de tokens afectan los resultados y los benchmarks actuales pueden ser demasiado cortos para medir cómo se degrada la confiabilidad en tareas más largas. Aun así, la conclusión más amplia del AISI es difícil de ignorar: las capacidades cibernéticas autónomas están avanzando a un ritmo significativo mes a mes, no solo anualmente.

Esto no significa que todas las organizaciones deban entrar en pánico. Significa que los equipos de seguridad deben dejar de tratar la explotación asistida por IA como una preocupación lejana. Incluso si las capacidades actuales siguen siendo desiguales, su ritmo de mejora es lo suficientemente rápido como para afectar la forma en que los equipos planifican las pruebas, la remediación y la respuesta a incidentes.

Los resultados de los socios muestran rendimiento de parches, no solo descubrimiento

Los informes de los socios importan porque revelan lo que sucede después de que el modelo encuentra problemas. Palo Alto Networks informó que su aviso de "Miércoles de Parches" de mayo incluyó 26 CVE que representaban 75 problemas, en comparación con su volumen mensual habitual de menos de cinco CVE, tras un escaneo inicial de más de 130 productos. También enfatizó que los resultados de alta fidelidad requieren arneses, contexto, salvaguardas, inteligencia de amenazas y un enfoque multimodelo. Esta es una corrección útil para la versión más simplificada de la historia de Mythos. La IA de frontera puede encontrar problemas importantes, pero ningún modelo o prompt por sí solo es suficiente para identificar el superconjunto de vulnerabilidades.

La actualización de Oracle es útil por otra razón: separa los entornos gestionados por el proveedor de aquellos gestionados por el cliente. En los servicios en la nube gestionados por Oracle, el proveedor puede aplicar parches de forma continua. En los despliegues gestionados por el cliente, Oracle puede entregar las correcciones, pero los clientes aún deben planificar, probar y aplicarlas. Oracle también anunció actualizaciones mensuales de parches de seguridad críticos para correcciones críticas dirigidas, en lugar de depender únicamente de ciclos trimestrales.

Esa distinción se aplica mucho más allá de Oracle. Si el descubrimiento asistido por IA aumenta la cantidad de hallazgos urgentes, las organizaciones que puedan parchear de forma centralizada se moverán más rápido. Aquellas con entornos locales, gestionados por el cliente o altamente integrados enfrentarán más fricción. Aquí es donde AppSec, la infraestructura, las operaciones y la gestión del cambio se vuelven inseparables.

Mozilla proporciona otro ejemplo práctico: corregir 271 errores de Firefox identificados a través de Mythos requirió no solo el resultado del modelo, sino también personas, es decir, ingenieros escribiendo y revisando parches, equipos escalando el pipeline, triando reportes, probando correcciones y gestionando lanzamientos. Más de 100 personas aportaron código a este esfuerzo. Así se ve un programa de seguridad acelerado por IA en la práctica: un modelo en el centro del descubrimiento, rodeado de humanos, herramientas y disciplina de lanzamiento.

Claude Security: industrializando el flujo de trabajo

El producto Claude Security de Anthropic es otra señal de hacia dónde se dirige esto. Actualmente se encuentra en fase beta pública para clientes de Claude Enterprise y está diseñado para escanear bases de código, validar hallazgos y sugerir parches para su revisión. Anthropic afirma que cada hallazgo pasa por una fase de verificación adversaria, que las correcciones sugeridas preservan la estructura y el estilo del proyecto, y que los equipos pueden integrar los resultados con flujos de trabajo como Slack, Jira, escaneos recurrentes y exportaciones de auditoría.

Esto es relevante incluso si no tratamos a Claude como la respuesta definitiva. La existencia de un producto de este tipo demuestra que las lecciones aprendidas de Glasswing están pasando de ser un programa de investigación controlado a convertirse en herramientas de seguridad empresarial. El lenguaje del producto también es revelador: escanear, validar, parchear, revisar, aprobar. La propuesta de valor, como hemos reconocido durante años en Fluid Attacks, no es solo "encontramos vulnerabilidades". Es "ayudamos a pasar de la detección a la remediación manteniendo a los humanos con el control".

Para las empresas de AppSec, este es un recordatorio de que el mercado normalizará rápidamente la detección asistida por IA. Un escáner que solo produce una lista en constante crecimiento de hallazgos resultará cada vez menos atractivo. El diferenciador será qué tan bien una plataforma valida los hallazgos, los prioriza, los conecta con la exposición al riesgo empresarial, propone rutas de remediación seguras, verifica las correcciones y se integra en la forma en que los desarrolladores ya trabajan.

Lo que el panel enseña a los equipos de AppSec

El panel de divulgación coordinada de vulnerabilidades de Anthropic merece especial atención por parte de los profesionales de AppSec porque expone la física operativa del descubrimiento de vulnerabilidades asistido por IA. La parte superior del embudo es grande: 23,019 hallazgos candidatos. El resultado público es mucho menor: según la instantánea del panel, se habían divulgado 1,596 vulnerabilidades en 281 proyectos de código abierto; 97 habían sido parcheadas y 88 habían recibido un CVE o un GitHub Security Advisory.

Esas cifras demuestran que, en efecto, la identificación de vulnerabilidades puede escalar más rápido que la remediación y que esto no es un evento único. Incluye la reproducción, la evaluación de la severidad, la comunicación con los mantenedores, el diseño de parches, la revisión y el lanzamiento, la publicación de advertencias y el despliegue por parte de los usuarios intermedios.

El panel también nos recuerda que "verdadero positivo" no es lo mismo que "alto impacto para el negocio". Anthropic señala que las tasas de verdaderos positivos incluyen hallazgos que pueden ser reales pero caen fuera del modelo de amenazas de un proyecto, afectan a código que normalmente no es alcanzable o que los mantenedores tratan de manera diferente más adelante. La concordancia en la severidad también es imperfecta; en la instantánea pública, Anthropic reportó un 58.7% de concordancia exacta entre la evaluación de severidad inicial de Claude y las evaluaciones de firmas de seguridad externas, y un 94.4% de concordancia dentro de un mismo rango de severidad.

Esto no es un fracaso de la IA; es un recordatorio de lo que la gestión de vulnerabilidades siempre ha sido: un ejercicio contextual, adversario y aproximado limitado por restricciones operativas.

Un desafío útil: el sistema por encima del modelo

Vale la pena señalar el análisis de AISLE porque va en contra de una interpretación excesivamente centrada en el modelo. La empresa probó si modelos más pequeños y económicos podían redescubrir hallazgos conocidos de Mythos, incluido el CVE-2026-4747 en FreeBSD, e informó que varios modelos podían identificar la vulnerabilidad en pruebas repetidas a nivel de archivo mientras ignoraban correctamente la versión parcheada. El argumento más amplio de AISLE es que un sistema de escaneo bien diseñado con cobertura paralela, prompts, triaje y un presupuesto de tokens suficiente puede compensar algunas brechas en las capacidades del modelo.

Esta es, quizás, una forma de reconocer que el modelo de frontera es solo una parte de la ecuación. La pregunta práctica para los defensores puede no ser "¿Tenemos el modelo más potente?" sino "¿Tenemos el sistema adecuado implementado alrededor de los modelos a los que podemos acceder?". Ese sistema debe incluir: selección de objetivos, contexto de la base de código, diseño del arnés, validación, desduplicación, análisis de alcanzabilidad y seguimiento de la remediación.

Esto es especialmente importante para las organizaciones que no tendrán acceso temprano a modelos restringidos. Esperar a un lanzamiento de la clase de Mythos no es una estrategia. Construir el músculo operativo para utilizar los modelos actuales de forma segura y eficaz sí lo es.

Qué significa esto para AppSec

Para reiterar, el primer mes del Proyecto Glasswing está demostrando que la detección de vulnerabilidades y el desarrollo de exploits mediante sistemas basados en IA se están volviendo más rápidos, más automatizados y más medibles. La consecuencia no es que el trabajo de seguridad humana desaparezca, sino que se desplaza hacia la orquestación, la validación, la priorización, la remediación y la toma de decisiones responsable.

Para los equipos de AppSec, destacan varias lecciones.

Primero, las pruebas de seguridad deben volverse más frecuentes, o mejor dicho, continuas. Si los modelos pueden escanear código y generar pruebas rápidamente, entonces los ciclos de prueba anuales o trimestrales parecerán cada vez más desalineados con la velocidad tanto de desarrollo como de explotación.

Segundo, los hallazgos deben vincularse a la alcanzabilidad y la explotabilidad. Un error teórico, una caída reproducible y una vulnerabilidad alcanzable en producción son cosas diferentes. Les plataformas que no puedan distinguirlos harán perder tiempo a los analistas y desarrolladores.

Tercero, las capacidades de remediación dependen de la estrategia operativa. Las organizaciones que más se beneficiarán del descubrimiento asistido por IA no serán aquellas que generen la lista más larga de hallazgos; serán aquellas que puedan resolver los problemas de manera segura, rápida y verificable.

Cuarto, la diversidad de modelos importa. Diferentes modelos tienen diferentes fortalezas y puntos ciegos. Un enfoque robusto de AppSec no debe depender de un solo proveedor, modelo o benchmark.

Finalmente, los programas de seguridad requieren flujos de trabajo auditables. A medida que los hallazgos generados por IA pasan a formar parte de la gestión de vulnerabilidades, las organizaciones necesitarán evidencia de cómo se validaron los hallazgos, quién aprobó las correcciones, cuándo se desplegaron los parches y si el riesgo realmente disminuyó.

La perspectiva de Fluid Attacks

Para Fluid Attacks, esta actualización refuerza una postura que hemos mantenido durante años: la detección de vulnerabilidades es solo una primera etapa en la seguridad de las aplicaciones. El valor real radica en reducir la exposición al riesgo mediante pruebas continuas, validación experta, priorización estricta, soporte continuo de remediación y verificación disciplinada.

Los agentes de IA pueden acelerar el trabajo de seguridad. Pueden inspeccionar más código, generar hipótesis, escribir pruebas de concepto y sugerir correcciones. Pero necesitan un sistema controlado que los respalde, y las organizaciones necesitan gobernanza sobre sus resultados. De lo contrario, la IA simplemente aumenta la velocidad con la que la incertidumbre ingresa al backlog.

Los programas de AppSec más sólidos combinarán la automatización, la experiencia humana y la disciplina de plataforma. La automatización aumenta el alcance; los expertos aportan el juicio; la plataforma mantiene el trabajo trazable, priorizado y conectado con la remediación. Así es como las organizaciones pasan de saber que tienen vulnerabilidades a demostrar que han reducido su exposición al riesgo.

La actualización inicial del Proyecto Glasswing refuerza la idea de que identificar vulnerabilidades se está volviendo más barato, construir exploits es cada vez más accesible, los acumulados de divulgación son cada vez más difíciles de gestionar y los ciclos de parcheo están bajo presión. Los equipos de seguridad que traten estos cambios como una razón para comprar más detección no entenderán el punto clave: el verdadero desafío es construir sistemas que conviertan los hallazgos en una reducción de riesgo verificada.

De hecho, Fluid Attacks, con sus herramientas automatizadas, IA y evaluadores de penetración, está aquí para ayudarle a ir más allá de la simple detección de vulnerabilidades de seguridad. Contáctenos.