Anthropic lleva siete meses dejando que su modelo Claude Mythos busque bugs de seguridad en software open source, gratis, sin que nadie se lo pida dos veces. El resultado al 2 de noviembre: 37,966 hallazgos en su "ledger" público de vulnerabilidades. De esos, apenas 217 están arreglados. Esa brecha —entre lo que una IA puede encontrar y lo que los humanos pueden confirmar y parchar— es el problema real que está exponiendo este experimento, y es uno que le toca directo a cualquier agencia o equipo de producto que corre sobre dependencias open source (que, seamos honestos, es prácticamente todo el software que existe).
Qué es Glasswing y qué dice haber encontrado
El programa se llama Glasswing, lo lanzó Anthropic el 7 de abril, y la promesa inicial fue identificar "miles de vulnerabilidades adicionales de severidad alta y crítica" para reportarlas de forma responsable a los proyectos afectados. El 8 de octubre, Anthropic abrió además un OSS Scanner opt-in: revisiones de código recurrentes y gratuitas con sus modelos más capaces, incluyendo Mythos, para cualquier proyecto open source elegible que quiera inscribirse.
Los números al día de hoy, según el propio ledger de Anthropic:
- 37,966 hallazgos totales (subieron desde 23,019 en el lanzamiento de mayo).
- 7,349 hechos públicos (19.4% del total).
- 217 arreglados y 419 retirados.
- Anthropic afirma una tasa de 94.2% de verdaderos positivos — subió desde el 90.8% original.
VulnCheck, que lleva su propio conteo independiente cruzando CVEs reales, le atribuye a Anthropic 442 CVEs en siete meses (unos 63 al mes), apenas 0.5% de los 93,450 CVEs publicados este año. De esos 442, solo 2 (0.45%) aparecen explotados activamente según el catálogo KEV. Es decir: el volumen es enorme, pero la urgencia real —medida en explotación confirmada— es baja.
El problema no es encontrar bugs, es confirmarlos
Aquí está el dato que de verdad importa para cualquiera que trabaje con código: en septiembre, Claude calificó 91.5% de sus propios hallazgos como críticos o altos. Los mantenedores humanos que revisaron esos mismos reportes solo coincidieron en 51.3% de los casos. La IA sobreestima la severidad casi dos a uno.
El caso de curl lo ilustra perfecto. Daniel Stenberg, su creador, recibió un lote de 45 reportes de Mythos. De los 34 ya evaluados: 19 (55.9%) no eran vulnerabilidades reales, 6 (17.6%) se confirmaron como severidad baja, y 9 siguen en evaluación. Nada de severidad alta o crítica, pese a que Anthropic había calificado casi todo el lote con prioridad alta.
Con el OSS Scanner pasa algo parecido a mayor escala: 29,432 vulnerabilidades candidatas encontradas, pero solo 6,123 revisadas manualmente y 513 parchadas. El resto —unas 23,000— sigue sin validar. La propia Anthropic lo dijo sin rodeos cuando lanzó el scanner: están "bottlenecked on our human capacity to validate these findings" (limitados por la capacidad humana para validar los hallazgos). Cuando un tercero independiente —pentesters que revisaron 97 hallazgos críticos y altos en 48 proyectos— hizo la prueba, 88% sí cumplía el estándar para divulgación. No es que el modelo esté inventando todo; es que la proporción de ruido sigue siendo alta y el cuello de botella se movió de "quién encuentra el bug" a "quién tiene tiempo de confirmarlo".
Los mantenedores ya están respondiendo (como pueden)
OpenSSL es de los pocos proyectos con presupuesto para absorber el golpe. Anton Arapov, director de OpenSSL Corporation, lo puso así: "We had to grow the [security] team to keep up" (tuvimos que crecer el equipo de seguridad solo para mantener el ritmo), y por eso decidieron inscribirse de lleno al OSS Scanner. Pero OpenSSL es la excepción: la mayoría de los proyectos open source críticos los mantiene un puñado de voluntarios sin ese colchón.
Krishna Shakula, ingeniero de IA que ha seguido el programa, lo resume con una frase que debería colgarse en la pared de cualquier equipo que use herramientas de IA para QA o seguridad: "The scan is free, but the time needed to deal with its findings isn't" (el escaneo es gratis, pero el tiempo para procesar sus hallazgos no lo es). Paul Nashawaty, analista de TheCube Research, va más allá: advierte que automatizar el descubrimiento de vulnerabilidades sin automatizar también la remediación es, en sus palabras, apostarle a la parte más fácil del problema mientras se ignora la más cara.
Lo que esto significa para agencias, developers y tu producto
Esto no es un reporte abstracto sobre un programa de Anthropic. Si tu stack —el de tu agencia o el de cualquier cliente— corre sobre dependencias open source (spoiler: corre), esto cambia cómo deberías leer una alerta de seguridad a partir de hoy:
- No le des prioridad automática a un hallazgo solo porque dice "crítico". Con una tasa de acierto de severidad de apenas 51.3% según mantenedores humanos, un "crítico" generado por IA necesita verificación antes de interrumpir un sprint.
- Si mantienes o contribuyes a un proyecto open source propio, presupuesta tiempo de triage, no solo de desarrollo. El cuello de botella ya no es técnico, es de capacidad humana para revisar.
- Auditar las dependencias de un cliente ya no es opcional, es un servicio que vale la pena ofrecer. Con miles de reportes sin validar circulando por el ecosistema, saber cuáles aplican a tu stack específico es trabajo real y facturable.
- Si usas IA para generar reportes de seguridad o QA internamente, mide la tasa de falsos positivos, no solo el volumen de hallazgos. El caso de curl —55.9% de "vulnerabilidades" que no lo eran— es la advertencia más clara que vamos a ver este año sobre qué pasa cuando se optimiza por cantidad.
- Esto también es una oportunidad de producto: quien construya la capa de triage —la herramienta que separa el ruido real del falso positivo antes de que llegue a un humano— va a tener demanda garantizada mientras este patrón se repita en cada vertical de IA aplicada a código.
Nada de esto significa que Glasswing sea un fracaso. 217 vulnerabilidades reales arregladas, y potencialmente miles más en camino, es un resultado neto positivo para la seguridad del software que todos usamos. Pero la lección para cualquiera que esté pensando en meter IA a su flujo de trabajo —de seguridad, de QA, de lo que sea— es la misma: la parte difícil nunca fue generar el output. Siempre fue construir el proceso humano que lo valida.
¿Tu equipo ya tiene un proceso para triar lo que la IA le entrega, o todavía confía ciegamente en la etiqueta "crítico"? Si quieres que lo revisemos juntos, escríbenos a hello@geekvibes.agency.
