Actualización de Project Glasswing: qué dice la evidencia sobre el descubrimiento de vulnerabilidades impulsado por IA

Qué cambió tras la primera actualización de Glasswing

La actualización inicial de Anthropic afirma que, después de aproximadamente un mes, Anthropic y cerca de 50 socios de Project Glasswing habían usado Claude Mythos Preview para identificar más de 10.000 vulnerabilidades de severidad alta o crítica en software considerado sistémicamente importante. Anthropic también reporta que varios socios aumentaron su tasa de detección de fallas de seguridad en más de un factor de diez.

Esas son afirmaciones de gran trascendencia y deberían leerse con la misma cautela con la que abordamos nuestro post anterior. Las estimaciones de severidad dependen del contexto; muchos hallazgos se sitúan dentro de ventanas 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 dashboard de divulgación y referencias a benchmarks que podrán inspeccionarse con el tiempo.

En un anuncio posterior sobre la ampliación de Project Glasswing, Anthropic indicó que el programa está yendo más allá de su grupo inicial de unos 50 socios para ampliar su acceso a aproximadamente 150 organizaciones adicionales. Según se informa, el nuevo grupo abarca más de 15 países e incluye sectores que estaban menos representados en el lanzamiento, como la energía, el agua, la salud, las comunicaciones y el hardware. Esta expansión cambia la escala de la ambición del proyecto: Glasswing ya no se presenta solo como un experimento defensivo con grandes empresas tecnológicas, sino como un intento de acercar las capacidades de su modelo a organizaciones cuyo software o infraestructura podrían afectar a poblaciones muy grandes si se vieran comprometidos.

Hasta ahora, las cifras públicas más interesantes se presentan en el trabajo de Anthropic con código abierto. Según la actualización, Mythos había escaneado más de 1.000 proyectos open source y generado 23.019 hallazgos candidatos, incluidos 6.202 estimados inicialmente como de severidad alta o crítica. Un subconjunto de 1.752 hallazgos de severidad alta o crítica había sido evaluado por firmas externas de seguridad o por personal de Anthropic; de esos hallazgos, el 90,6 % fue considerado verdadero positivo válido y el 62,4 % fue confirmado como de severidad alta o crítica después de la revisión.

Suena impresionante, pero la evolución de la cifra es más importante que el dato global. En el dashboard de divulgación coordinada de vulnerabilidades, el embudo se estrecha con rapidez: los hallazgos candidatos se convierten en hallazgos revisados externamente, los hallazgos revisados se convierten en vulnerabilidades confirmadas, las vulnerabilidades confirmadas se convierten en reportes para los mantenedores, y solo un conjunto mucho más pequeño se convierte en software parchado con avisos públicos. Esta disminución no significa, por supuesto, un fracaso del proyecto. Es evidencia del trabajo real que implica convertir el output de seguridad generado por IA en algo útil.

Quizá el dashboard sea más importante para AppSec que el anuncio en sí, porque convierte una afirmación sobre la capacidad de un modelo en un flujo de trabajo observable: candidato, priorizado, validado, reportado, reconocido, parcheado y divulgado públicamente. Esa es la clase de estructura que la industria necesitará si el descubrimiento asistido por IA se vuelve común. Sin un registro, una lista, revisión de severidad, comunicación con mantenedores y seguimiento de parches, "encontramos miles de vulnerabilidades" no se constituye en un resultado valioso para la seguridad; es simplemente una acumulación de tareas pendientes.

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

Una de las medidas responsables que ha adoptado Anthropic es publicar una política de divulgación coordinada para las vulnerabilidades descubiertas a través de Claude. La política busca seguir la norma conocida de divulgación a 90 días, o la divulgación pública después de que se revele un parche, con posibles extensiones cuando los mantenedores estén trabajando activamente en una corrección. Para vulnerabilidades críticas explotadas activamente, Anthropic describe una línea de tiempo mucho más corta, con un parche o una mitigación esperados en un plazo de 7 días, con posibilidad de una extensión breve.

La política también dice algo importante sobre el ritmo: Anthropic pretende entregar reportes revisados por humanos, con correcciones sugeridas cuando sea posible, y regular el volumen de envíos según lo que los mantenedores puedan manejar. Este último aspecto no es baladí. Si los sistemas de IA aumentan el descubrimiento mucho más rápido de lo que los mantenedores pueden priorizar y parchar, la divulgación no coordinada puede convertirse en otra forma de presión sobre el ecosistema.

Por lo tanto, Project Glasswing opera en un punto medio difícil. Por un lado, retrasar demasiado la divulgación deja a los usuarios expuestos a vulnerabilidades que otros podrían descubrir de forma independiente. Por otro lado, divulgar demasiado pronto puede saturar a los mantenedores y proporcionar a los atacantes detalles útiles antes de que las correcciones estén listas y desplegadas. Este no es un problema que Mythos resuelva. Es un problema que Mythos hace visible a escala.

La expansión de Anthropic también deja claro que el acceso sigue siendo un tema fundamental en materia de gobernanza. La compañía afirma que está trabajando para lograr el acceso generalizado a las capacidades de nivel Mythos, pero solo después de desarrollar medidas de seguridad lo suficientemente sólidas como para evitar el uso indebido, un problema que, según admite, aún no ha sido resuelto por Anthropic ni, según su conocimiento, por otros desarrolladores de IA. Mientras tanto, planea expandir aún más Project Glasswing y escalar un programa de verificación cibernética que pondría a disposición de más organizaciones su modelo para tareas defensivas específicas.

El armazón importa tanto como el modelo

Varios reportes de socios de Anthropic dentro de Glasswing convergen en una lección que debería resultar familiar para los equipos de AppSec: un modelo potente no basta; este necesita un buen armazón.

El análisis de Cloudflare es uno de los ejemplos más claros. Este describe un pipeline que no se limita a asignar un agente genérico de programación a un repositorio y pedirle que encuentre errores. En cambio, el proceso crea contexto de arquitectura, divide el trabajo en tareas estrechas, ejecuta múltiples agentes en paralelo, valida los hallazgos de forma adversarial, descarta las causas raíz duplicadas, rastrea si una falla es alcanzable desde fuera del sistema y convierte el output en reportes estructurados.

Esto es importante porque los agentes genéricos de programación están optimizados para un modo de trabajo distinto. Son buenos para mantener un flujo de contexto enfocado mientras construyen, reparan o refactorizan. La investigación de vulnerabilidades, en cambio, suele requerir muchas hipótesis estrechas a través de numerosos archivos, límites de confianza y clases de ataque. Un solo agente de larga duración que "busca vulnerabilidades" en un repositorio grande puede generar ideas interesantes, pero no ofrecerá una cobertura significativa. Un armazón le da forma al trabajo.

La experiencia de Mozilla al fortalecer Firefox cuenta una historia similar. Experimentos anteriores con auditorías de código basadas en LLMs mostraron potencial, pero generaron demasiados falsos positivos como para poder ampliarse a gran escala. Según Mozilla, los armazones agénticos cambiaron ese panorama porque podían crear y ejecutar casos de prueba reproducibles, probando hipótesis de forma dinámica en lugar de dejar reportes especulativos en la cola de triaje. Luego, Mozilla construyó su propio pipeline sobre su infraestructura existente de fuzzing, paralelizó los trabajos en máquinas virtuales efímeras e integró los resultados en el ciclo de vida de los errores de seguridad de Firefox: descarte de duplicados, seguimiento, priorización, corrección, pruebas y gestión de lanzamientos.

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

Anthropic también ha dicho que está ampliando los casos de uso defensivos asociados a modelos como Mythos, incluyendo la redacción de parches, las comprobaciones previas al lanzamiento, las pruebas de penetración, la detección y respuesta automatizadas de amenazas, e incluso la reconstrucción de código heredado en lenguajes seguros para la memoria. Estas tareas no deben considerarse como una única capacidad genérica de seguridad basada en IA; cada una requiere su propio entorno de ejecución, controles, métricas de éxito y revisión humana.

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

La evaluación de XBOW añade otra distinción útil. Esta compañía encontró que Mythos es particularmente fuerte en auditoría de código fuente y en razonamiento técnico, especialmente cuando el código fuente está disponible. Pero también enfatizó que la validación en sitios vivos sigue siendo complicada. Muchos problemas explotables no son evidentes solo en el código de la aplicación; surgen de decisiones de despliegue, configuraciones, dependencias, permisos y la manera en que componentes aparentemente seguros interactúan en producción.

La misma evaluación también señala el juicio de los modelos como un ámbito con resultados mixtos. Mythos puede reducir los falsos negativos en algunos escenarios y producir análisis técnicos precisos, pero aún puede ser demasiado conservador, demasiado literal o inconsistente en el razonamiento sobre la seguridad de los comandos. Esto no es de extrañar. El trabajo en materia de seguridad está lleno de decisiones de criterio: si una vulnerabilidad es alcanzable, si es seguro ejecutar una prueba de concepto, si una calificación de severidad se ajusta al modelo de amenazas del proyecto y si una corrección modifica el comportamiento de formas inaceptables. Un modelo puede ser bastante útil, pero no puede reemplazar una revisión responsable.

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

Uno de los avances más relevantes para los defensores de ciberseguridad es la aparición de benchmarks más sólidos respecto al desarrollo de exploits. El blog Frontier Red Team de Anthropic habla de ExploitBench y ExploitGym, siendo el primero especialmente útil porque no trata la explotación como un evento binario de éxito o fracaso. Por el contrario, la divide en etapas: alcanzar el código vulnerable, reproducir la vulnerabilidad, construir primitivas de explotación específicas para el 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 es importante: una falla no es lo mismo que un exploit. Llegar a 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 demostrar que un atacante pueda convertirlo en un impacto significativo. ExploitBench intenta medir todo el proceso, en lugar de solo un paso.

En el benchmark V8 de ExploitBench, Anthropic reporta que Mythos logró la ejecución arbitraria de código en 21 de 41 entornos de CVE al combinar la variante de referencia (sin indicaciones adicionales específicas sobre la vulnerabilidad) y la variante "nudged" (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 dos variantes, salvo mediante un andamiaje (scaffold) propietario que logró ese resultado en dos casos. El análisis de las evaluaciones de exploits de Anthropic enmarca esto como parte de una necesidad más amplia: medir hasta dónde pueden avanzar los modelos desde el descubrimiento de vulnerabilidades 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. Da a entender que la brecha de capacidades no se limita a la detección de fallas, sino que abarca también el avance desde las fallas hasta los exploits. Para los defensores, esto comprime el tiempo disponible entre la publicación de un parche, la comprensión de la vulnerabilidad subyacente por parte de un atacante y la viabilidad práctica del código de explotación. También refuerza por qué los tiempos de prueba y despliegue de parches importan; si construir exploits se vuelve más barato, el costo de una remediación lenta aumenta.

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

El AI Security Institute del Reino Unido aporta una perspectiva más amplia sobre las capacidades. Su suite de tareas cibernéticas estima la extensión de las tareas que los modelos de frontera pueden completar de forma autónoma, con un umbral de confiabilidad. En febrero de 2026, AISI estimó que el “horizonte temporal” cibernético con un 80 % de confiabilidad se había duplicado cada 4,7 meses desde finales de 2024. Mythos Preview y GPT-5.5 superaron significativamente esa tendencia en las pruebas de AISI.

AISI es cuidadoso con la incertidumbre. Sus tareas no son intrusiones reales completas contra sistemas defendidos. Las tareas más largas son escasas, las líneas base humanas (los resultados de referencia obtenidos cuando las personas realizan las mismas pruebas de rendimiento) 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 general de AISI es difícil de ignorar: la capacidad cibernética autónoma avanza a un ritmo significativo mensual, no solo anual.

Esto no significa que toda organización deba entrar en pánico. Significa que los equipos de seguridad deberían dejar de considerar la explotación asistida por IA como una preocupación distante. Aunque las capacidades actuales sigan siendo desiguales, su ritmo de mejora es lo suficientemente rápido como para influir en la forma en que los equipos planifican las pruebas, la remediación de vulnerabilidades y la respuesta ante incidentes.

Los resultados de los socios muestran capacidad de parcheo, no solo descubrimiento

Los reportes de socios importan porque revelan qué ocurre después de que el modelo encuentra problemas. Palo Alto Networks reportó que su aviso “Patch Wednesday” de mayo incluyó 26 CVEs que representaban 75 problemas, en comparación con su volumen mensual habitual de menos de cinco CVEs, después de un escaneo inicial de más de 130 productos. También enfatizó que los resultados de alta fidelidad requieren armazones, contexto, controles de seguridad, inteligencia de amenazas y un enfoque multimodelo. Esta es una corrección útil a la versión más simple de la historia de Mythos. La IA de frontera puede encontrar problemas importantes, pero ningún modelo o prompt por sí solo basta para identificar el conjunto completo de vulnerabilidades.

La actualización de Oracle es útil por otra razón: separa los entornos administrados por el proveedor de los administrados por el cliente. En los servicios de nube administrados por Oracle, el proveedor puede aplicar parches de forma continua. En despliegues administrados por el cliente, Oracle puede entregar correcciones, pero los clientes aún deben planearlas, probarlas y aplicarlas. Oracle también anunció Critical Security Patch Updates mensuales para correcciones críticas específicas, en lugar de depender únicamente de ciclos trimestrales.

Esa distinción va mucho más allá de Oracle. Si el descubrimiento asistido por IA aumenta el número de hallazgos urgentes, las organizaciones que puedan reparar de forma centralizada se moverán más rápido. Aquellas con entornos on-premises, administrados por el cliente o altamente integrados enfrentarán más fricción. Aquí es donde AppSec, infraestructura, operaciones y gestión de cambios se vuelven inseparables.

Mozilla ofrece otro ejemplo práctico: la corrección de 271 errores de Firefox identificados a través de Mythos no solo requirió los resultados del modelo, sino también la intervención de personas, es decir, ingenieros que escribieron y revisaron parches, equipos escalando el pipeline, priorizando reportes, probando correcciones y gestionando despliegues. Más de 100 personas contribuyeron con código a esta iniciativa. Así es como se ve en la práctica un programa de seguridad impulsado por la IA: un modelo en el centro del proceso de detección, rodeado de humanos, herramientas y una disciplina de lanzamientos.

Claude Security: la productización del flujo de trabajo

El producto Claude Security de Anthropic es otra señal de hacia dónde va esto. Actualmente se encuentra en beta pública para clientes de Claude Enterprise y se presenta como una herramienta que escanea bases de código, valida los hallazgos y sugiere parches para su revisión. Anthropic afirma que cada hallazgo pasa por una verificación adversarial, 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 para auditoría.

Esto es relevante incluso si no tratamos a Claude como la respuesta definitiva. La existencia de dicho producto muestra cómo las lecciones de Glasswing están pasando de un programa de investigación controlado a herramientas empresariales de seguridad. El lenguaje del producto también es revelador: escanear, validar, parchar, revisar, aprobar. La propuesta de valor, como reconocemos desde hace años en Fluid Attacks, no es solo "encontramos vulnerabilidades." Es "ayudamos a pasar del hallazgo a la remediación manteniendo a los humanos en control."

Para las compañías de AppSec, esto les recuerda que el mercado normalizará rápidamente la detección asistida por IA. Un escáner que solo produce una lista cada vez más extensa de hallazgos será cada vez menos convincente. El diferenciador estará en qué tan bien una plataforma valida hallazgos, les asigna prioridades, los conecta con la exposición al riesgo del negocio, propone rutas seguras de remediación, verifica las correcciones y se integra en la forma en que los desarrolladores ya trabajan.

Qué les enseña el dashboard a los equipos de AppSec

El dashboard de divulgación coordinada de vulnerabilidades de Anthropic merece atención especial 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 captura del dashboard, se habían divulgado 1.596 vulnerabilidades en 281 proyectos open source; 97 habían sido parchadas y 88 habían recibido un CVE o un GitHub Security Advisory.

Esos números muestran que, efectivamente, la identificación de vulnerabilidades puede escalar más rápido que la remediación y que esta no es un evento único. Incluye reproducción, evaluación de la severidad, comunicación con mantenedores, diseño, revisión y lanzamiento de parches, publicación de avisos y despliegue por parte de los usuarios finales.

El dashboard también nos recuerda que "verdadero positivo" no equivale a "alto impacto de negocio." Anthropic señala que las tasas de verdaderos positivos incluyen hallazgos que pueden ser reales pero que están fuera del modelo de amenazas de un proyecto, afectan código que normalmente no es alcanzable o son tratados de forma distinta posteriormente por los mantenedores. La concordancia en cuanto a la severidad también es imperfecta; en la captura pública, Anthropic reportó un 58,7 % de coincidencia exacta entre la evaluación inicial de severidad de Claude y las evaluaciones de empresas externas de seguridad y un 94,4 % de coincidencia dentro de un nivel de severidad.

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

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

Vale la pena mencionar el análisis de AISLE porque cuestiona una interpretación excesivamente centrada en el modelo. Dicha compañía probó si modelos más pequeños y baratos podían redescubrir hallazgos conocidos de Mythos, incluido CVE-2026-4747 en FreeBSD, y reportó 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 parte de las brechas de capacidad del modelo.

Esta es, tal vez, una forma de dar cuenta de que el modelo de frontera es solo una parte de la ecuación. La pregunta práctica para los defensores quizá no sea "¿tenemos el modelo más potente?", sino "¿tenemos el sistema adecuado alrededor de los modelos a los que podemos acceder?" Ese sistema debería incluir: selección de objetivos, contexto de la base de código, diseño de armazón, validación, descarte de duplicados, 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 un lanzamiento de nivel Mythos no es una estrategia. Construir la capacidad operativa para usar los modelos actuales de forma segura y efectiva sí lo es.

Qué significa esto para AppSec

Para reiterar, el primer mes de Project Glasswing demuestra 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 cuantificables. La consecuencia no es que el trabajo humano en materia de seguridad desaparezca, sino que se reorienta hacia la coordinació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 con rapidez, los ciclos anuales o trimestrales de evaluación se verán cada vez más desalineados con la velocidad tanto del desarrollo como de la explotación.

Segundo, los hallazgos deben vincularse con la alcanzabilidad y la explotabilidad. Un error teórico, una falla reproducible y una vulnerabilidad alcanzable en producción son cosas distintas. Las plataformas que no puedan distinguirlas desperdiciarán el tiempo de analistas y desarrolladores.

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

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

Por último, los programas de seguridad requieren flujos de trabajo auditables. A medida que los hallazgos generados por IA se integren en 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 posición que hemos sostenido durante años: la detección de vulnerabilidades es solo una fase inicial de 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, apoyo constante en la 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 a su alrededor y las organizaciones necesitan gobernanza sobre sus resultados. De lo contrario, la IA simplemente aumenta la velocidad con la que la incertidumbre entra en la lista de asuntos pendientes.

Los programas de AppSec más sólidos combinarán automatización, experiencia humana y disciplina de plataforma. La automatización aumenta el alcance; los expertos aportan criterio; 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 de Project Glasswing nos reafirma la idea de que la identificación de vulnerabilidades se está abaratando, la construcción de exploits se está volviendo más accesible, las colas de divulgación son cada vez más difíciles de manejar 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 perderán de vista lo esencial: el verdadero desafío es construir sistemas que conviertan los hallazgos en una reducción verificada del riesgo.

De hecho, Fluid Attacks —con sus herramientas automatizadas, su IA y sus pentesters— está aquí para ayudarte a ir más allá de la mera detección de vulnerabilidades de seguridad. Ponte en contacto con nosotros.