La nueva frontera de la ciberseguridad con IA: la realidad después de Mythos

• Después de que Claude Mythos de Anthropic detectara automáticamente vulnerabilidades zero-day a gran escala, modelos abiertos pequeños también lograron detectar las mismas vulnerabilidades
• Modelos de 3.6B a 5.1B parámetros reprodujeron bugs de FreeBSD y OpenBSD, y algunos incluso propusieron rutas de exploit creativas distintas a las de Mythos
• Los experimentos muestran que el tamaño del modelo y el rendimiento no son lineales y que, en ciertas tareas, los modelos pequeños son más precisos que los grandes
• Las capacidades de seguridad de la IA no escalan de forma uniforme, sino de manera “irregular”, y la verdadera ventaja competitiva está en el diseño del sistema y el pipeline de validación, no en el modelo
• Por lo tanto, el foso defensivo en seguridad no es el modelo, sino el sistema, y una arquitectura de orquestación con conocimiento experto integrado es el núcleo de la seguridad con IA

---

El foso es el sistema, no el modelo

• El 7 de abril de 2026, Anthropic presentó Claude Mythos Preview y Project Glasswing, formando un consorcio para detectar y corregir automáticamente vulnerabilidades de seguridad en software clave usando el modelo Mythos
  • Prometió 100 millones de dólares en créditos de uso y 4 millones de dólares en donaciones a organizaciones de seguridad de código abierto
  • Mythos descubrió miles de vulnerabilidades zero-day y detectó de forma autónoma bugs como un bug de 27 años en OpenBSD, un bug de 16 años en FFmpeg y una vulnerabilidad de ejecución remota de código en FreeBSD, además de generar exploits
• AISLE reprodujo las mismas vulnerabilidades con modelos pequeños, baratos y de pesos abiertos
  • 8 de 8 modelos detectaron el exploit de FreeBSD
  • Incluso un modelo de 3.6B parámetros (USD 0.11 por token) logró detectarlo
  • Un modelo de 5.1B reconstruyó la cadena clave del bug de OpenBSD
  • En algunas tareas, modelos abiertos pequeños superaron a modelos grandes
• En consecuencia, las capacidades de seguridad de la IA son no lineales e irregulares (jagged)
  • Ningún modelo sobresale en todas las tareas
  • La clave de la competitividad en seguridad no está en el modelo, sino en el sistema, con una estructura de orquestación que incorpora conocimiento experto como elemento central

Dónde está hoy la seguridad con IA

• Desde mediados de 2025, AISLE aplica sistemas de detección y parcheo de vulnerabilidades basados en IA a objetivos reales
  • Encontró 15 CVE en OpenSSL, 5 en curl y más de 180 CVE validados externamente en total
  • El CTO de OpenSSL evaluó que “la calidad de los reportes y el proceso de colaboración son excelentes”
• Aunque usó varios modelos, los modelos de Anthropic no siempre fueron los mejores
  • Como el modelo óptimo cambia según la tarea, adoptó un enfoque agnóstico al modelo

Descomposición del pipeline de seguridad con IA

• La seguridad con IA en la práctica no se compone de un solo modelo, sino de un pipeline de múltiples etapas
  • Escaneo amplio, detección de vulnerabilidades, validación y clasificación, generación de parches y construcción de exploits, entre otras etapas, tienen propiedades de escalado distintas
• Mientras Anthropic maximiza el primer insumo, es decir, la inteligencia del modelo, AISLE da la misma importancia a diversos factores como costo por token, velocidad y especialización en seguridad

Conclusión: el foso es el sistema

• La estructura mencionada en el post técnico de Mythos, como ejecución en contenedores, escaneo de archivos, validación con ASan y evaluación de prioridades, es similar al sistema de AISLE
• El centro del valor no está en el modelo, sino en el proceso de targeting, validación y construcción de confianza
• El enfoque de desplegar en paralelo grandes cantidades de modelos pequeños para explorar ampliamente todo el código asegura al mismo tiempo eficiencia económica y eficiencia de detección
• Mythos demostró la categoría, pero asegurar escala operativa y confiabilidad sigue siendo un reto

Resultados experimentales: capacidades de seguridad irregulares

• Se realizaron experimentos con modelos pequeños y baratos sobre las vulnerabilidades emblemáticas presentadas con Mythos

  • Bug NFS de FreeBSD, bug SACK de OpenBSD y prueba de falsos positivos de OWASP

    • En resultado, el tamaño, la generación, el precio y el rendimiento del modelo son no lineales
    • Todos los modelos detectaron FreeBSD, solo algunos detectaron OpenBSD y, en OWASP, los modelos pequeños fueron más precisos que los grandes
    • Detección en FreeBSD: los 8 modelos detectaron el desbordamiento de búfer
    • Incluso el modelo de 3.6B hizo los cálculos correctamente y evaluó la posibilidad de RCE
    • DeepSeek R1 realizó cálculos que coincidían con la estructura real de la pila
    • También en la lógica del exploit, todos los modelos propusieron una estrategia de cadena ROP
    • Algunos modelos presentaron soluciones creativas distintas a Mythos (por ejemplo, escalada a root en modo usuario en lugar de modo kernel)
    • Bug SACK de OpenBSD: un modelo de 5.1B reconstruyó la cadena completa y propuso el parche correcto
    • Qwen3 32B fue perfecto en FreeBSD, pero aquí juzgó erróneamente que “era seguro”
    • El ranking de rendimiento por modelo se invierte por completo según la tarea

• Prueba de falsos positivos de OWASP: en código Java simple, los modelos pequeños fueron más precisos que los grandes

  • GPT-OSS-20b, DeepSeek R1 y OpenAI o3 evaluaron correctamente: “actualmente es seguro, pero podría volverse vulnerable”
  • Muchos modelos de Anthropic y de la familia GPT-4.x detectaron erróneamente una inyección SQL

Prueba de reconocimiento de parches (actualización del 9 de abril de 2026)

• Se comparó la capacidad de detectar bugs y reconocer correcciones sobre código de la versión parcheada de FreeBSD
  • Todos los modelos detectaron el bug sin parche, pero aparecieron muchos falsos positivos en el código después del parche
  • Solo GPT-OSS-120b fue preciso en ambos sentidos
  • La mayoría de los modelos afirmó una vulnerabilidad por error debido a una interpretación incorrecta del signo de oa_length
• Esto muestra una alta sensibilidad (capacidad de detección) pero baja especificidad (precisión),
  y subraya que es indispensable un sistema externo al modelo para validación y triage

Los límites de la construcción de exploits

• Los casos de Mythos, como escape de sandbox del navegador en múltiples etapas y cadenas ROP de kernel, son ejemplos muy avanzados
• Los modelos abiertos explican de forma lógica la posibilidad de explotación, las técnicas y las estrategias de evasión, pero
  todavía les falta capacidad para mecanismos de entrega creativos en entornos restringidos
• Sin embargo, en workflows defensivos, la confiabilidad en la detección y el parcheo importa más que un exploit completamente funcional

Perspectiva macro

• El anuncio de Mythos demostró la viabilidad real y la importancia industrial de la seguridad con IA
  • Se amplían el financiamiento y el interés por la seguridad de código abierto
• Pero afirmar que “esta capacidad solo existe en un modelo cerrado específico” es una exageración
  • En la práctica, las etapas de detección y análisis ya son ampliamente accesibles
  • La especialización en seguridad, el diseño del sistema y la construcción de confianza son el verdadero cuello de botella

• Lo que se necesita ahora no es un modelo, sino construir sistemas

  • Scaffolds, pipelines, esquemas de colaboración e integración con workflows de desarrollo
  • Los modelos ya están suficientemente listos

Limitaciones y precauciones

• Alcance limitado de las pruebas: se proporcionaron directamente a los modelos la función vulnerable y pistas; no fue una exploración completamente autónoma
• Sin acceso a herramientas: no se usó ejecución de código, bucles ni entorno sandbox
• Actualizaciones de modelos reflejadas: algunos modelos recientes de Anthropic mejoraron posteriormente
• Aclaración del alcance de la afirmación: no se niega la capacidad de Mythos,
  sino que se señala que se exageró el carácter exclusivo de su capacidad de detección

Resumen del apéndice

• Citas sobre la detección en FreeBSD

  • Kimi K2: “oa_length se copia sin validación, por lo que puede producir un desbordamiento”
  • Gemma 4: “Puede exceder el búfer de pila de 128 bytes”

• Tabla comparativa de rendimiento por tarea

  • Todos los modelos tuvieron éxito en la detección de FreeBSD, solo algunos en OpenBSD y los modelos pequeños dominaron en OWASP

• Prueba con código parcheado

  • La mayoría de los modelos produjo falsos positivos por un error de signo en oa_length
  • Solo GPT-OSS-120b fue completamente preciso
  • Conclusión:
  • La competitividad central de la seguridad con IA no está en el tamaño del modelo ni en su carácter propietario,
  • sino en un diseño sistémico con conocimiento experto incorporado y una estructura operativa confiable.
  • Incluso los modelos pequeños son suficientemente potentes, y ya es posible construir sistemas de defensa automatizados a gran escala aprovechándolos.

[GN⁺]

Opiniones en Hacker News

• Según la publicación de Anthropic sobre Mythos Preview, encontró la vulnerabilidad más crítica en OpenBSD
  El costo total fue menor a 20 mil dólares por mil ejecuciones, y en una de ellas encontró el bug por menos de 50 dólares
  Pero se enfatiza que esa cifra solo tiene sentido a posteriori, ya que en la práctica no se sabe qué ejecución tendrá éxito
  Usan la metáfora de que Mythos recorrió un continente entero como si fuera una mina de oro, y estiman que si se hiciera el mismo experimento con todo el codebase de FreeBSD habría demasiado ruido

  • El scaffolding de Mythos en realidad consistía en recorrer todos los archivos con un loop en bash y hacer que el modelo buscara vulnerabilidades
    Da curiosidad si Anthropic publicó la tasa de falsos positivos
    Vi en Xitter comentarios de gente que probó con otros modelos abiertos y solo logró reproducir algunas de las detecciones de Mythos
    Creo que Mythos mostró una mejora incremental pero importante frente a modelos anteriores, aunque también aumentó la complejidad
    El marketing de “demasiado poderoso para publicarlo” en realidad parece maquillar la realidad de que “cuesta 20 mil dólares correrlo sobre un codebase completo”
    En la presentación de Nicholas Carlini también usaron Opus, y seguridad es un área en la que Anthropic ya venía enfocándose desde hace tiempo
  • Mythos también generó muchas vulnerabilidades alucinadas, pero algunas sí fueron validadas mediante pruebas
    La clave es si los modelos pequeños también pueden ejecutar esa etapa de validación, y si pueden hacerlo más barato
  • En cambio, otros creen que esa otra investigación fue demasiado extrema en su enfoque
    Separaron únicamente las funciones vulnerables y se las dieron al modelo para evaluarlas, lo cual es como “decirle directamente en qué cuarto está escondido el oro”
    En la práctica, lo más difícil es encontrar ese cuarto dentro de todo el continente
  • Gastar 20 mil dólares para encontrar una sola vulnerabilidad DoS en OpenBSD parece ineficiente
    Hay un ambiente de tratar a Mythos como si fuera un trofeo, pero algunos piensan que habría sido mejor donar ese dinero a la fundación de OpenBSD
  • Si el mismo bug puede encontrarse con un modelo pequeño, surge la duda de por qué esa empresa no lo encontró antes

• Hubo un estudio donde modelos abiertos pequeños detectaron las 8 de 8 vulnerabilidades de FreeBSD halladas por Mythos
  Pero como probaron solo el código relevante extraído por separado, parece distinto de un caso de uso real
  El verdadero valor está en poder lanzar el escaneo sobre el codebase completo

  • El propio equipo de investigación reconoció esa limitación
    Como le dieron al modelo la función vulnerable y pistas directamente, eso representa solo un límite superior de exploración totalmente autónoma
    Aun así, un scaffold bien diseñado puede generar ese contexto automáticamente, por lo que lo central es el sistema (moat) y no el modelo
  • Según el post técnico de Anthropic, la estructura consiste en levantar contenedores, hacer que el modelo escanee archivos, formule hipótesis y las valide con ASan
    Es decir, el argumento es que el framework (harness) hace la mayor parte del trabajo y el modelo es intercambiable
  • Incluso con modelos pequeños se puede construir un harness automático que lance prompts repetidamente por archivo o por función
    Luego solo habría que volver a validar con un modelo grande las partes señaladas consistentemente como vulnerables
    Al final, lo importante no es el modelo sino el harness
  • En última instancia, la diferencia es solo el harness. Yo también puedo hacer uno que divida el código por funciones y lo meta en un agente de análisis

• Como en el ejemplo de Heartbleed, si muestras solo el código vulnerable cualquiera puede encontrar el bug
  Pero lo realmente difícil es detectar esa parte dentro de una base de código grande
  Sorprende que Aisle haya publicado algo así

  • Aunque sea un artículo promocional, llegó arriba en HN porque apeló a esa sensación de “el modelo nuevo tampoco es gran cosa”
  • Cuando trabajas en proyectos grandes, a veces vuelves después de una pausa y hasta tu propio código te parece un desastre
    La dificultad de mantener el contexto es una de las causas raíz de muchos bugs
  • Los humanos son malos para tareas repetitivas y minuciosas
    En cambio, las máquinas pueden seguir revisando código sin aburrirse
    La frase “con suficientes ojos, todos los bugs son superficiales” no coincide con la realidad
  • Entonces lo que hay que hacer es automatizar ese proceso de “mirar de cerca”
    Se puede construir una herramienta que recorra el codebase y le repita al LLM “si hay una vulnerabilidad en este código, encuéntrala”
    Es decir, la herramienta (harness) es lo que vuelve realmente inteligente al LLM
  • Eso es como confundir resolver un problema con verificarlo
    Es una analogía del tipo “si alguien te diera la factorización prima, romper PKI sería fácil”

• Creo que la metodología de este artículo es una comparación completamente equivocada
  Darle directamente la función vulnerable y pistas es una tarea totalmente distinta
  En la práctica, aunque dividas fragmentos de código y se los des a modelos pequeños, no creo que se llegue a resultados al nivel de un modelo grande
  Yo encontré muchos bugs en Redis con un pipeline simple de shell scripts
  Con modelos débiles no funcionó. Si uno lo prueba por sí mismo, nota la diferencia
  Además, aunque un modelo pequeño encuentre el 80%, igual hace falta un modelo más fuerte para hallar el 20% restante

  • Anthropic dijo que publicó menos del 1% de las vulnerabilidades que encontró
    Sería interesante probar dándoles a modelos abiertos un entorno Linux viejo y ver cuánto encuentran
  • Pero otra persona considera que este enfoque sí es razonable
    Los modelos pequeños filtraron bien los false positives y, con un harness adecuado, pueden acercarse a resultados similares a los de modelos grandes
    Como los modelos pequeños son rápidos y baratos, en manos de usuarios experimentados resultan mucho más eficientes
    Se piensa que en adelante esta combinación de modelos ligeros + harness será la tendencia dominante
  • También hubo quien respondió con sarcasmo: “Thanks Dario, very cool!”

• Muchos comentarios dicen “como separaron el código, no vale”, pero Anthropic también ejecutó el modelo de forma similar por archivo
  El harness de Mythos asignaba una puntuación de importancia a cada archivo y creaba una instancia de Claude Code para concentrarse en ese archivo
  Por lo tanto, dividir el código por sí mismo no invalida el resultado

• En el video de la presentación de Nicholas Carlini también se presenta la misma técnica
  Hacer que el LLM revise intensivamente un solo archivo a la vez funciona bien
  La “innovación” de Mythos en realidad fue esta simple automatización de prompts por archivo
  Es muy probable que justamente por esto el costo haya subido hasta 20 mil dólares
  Yo también probé el mismo método con Opus 4.6 y GPT 5.4, y revisan con mucha más profundidad
  O sea, si una sesión se enfoca en un solo archivo, el modelo analiza mucho más a fondo

  • Pero así se pueden perder vulnerabilidades que surgen de la interacción entre archivos

• La afirmación de que “un modelo pequeño reconstruyó el mismo análisis” es difícil de creer porque no está cuantificada
  La validación de vulnerabilidades puede medirse claramente con un PoC, así que hace falta evidencia de ese tipo
  Además, “proveer de antemano solo el código relevante” no es una comparación justa

• Si no se publica la tasa de falsos positivos, el análisis no tiene sentido
  Si dices que todas las líneas tienen bugs, la tasa de detección será 100%, pero no sirve para nada
  Como ni Anthropic ni OpenAI publican esas cifras, cuesta confiar

  • Pero también hubo quien respondió que si existe un oracle verificable, los false positives pueden ignorarse
  • De hecho, los modelos pequeños acertaron en la prueba de false positives, mientras que Opus falló
    Aun así, no llegaron al nivel de validación de exploit de Mythos
    Los resultados de Deepseek R1 parecían bastante convincentes, aunque no está claro si realmente funcionaron
  • Como mínimo, para que tenga sentido, habría que alcanzar la misma cobertura que logró Anthropic

• El punto central es que se separó el código relevante
  Los zero-days complejos surgen por interacciones entre varios archivos, así que este enfoque tiene límites

  • Pero alguien sostiene que Mythos también hacía análisis por archivo al final de cuentas
  • No está claro si Mythos realmente encontró vulnerabilidades entre archivos

• Mythos evaluó el codebase completo, pero este estudio probó solo el código vulnerable extraído por separado
  Es como la diferencia entre “un perro que encontró la pelota en la jungla” y “un perro al que le dijeron en qué zona estaba la pelota”

  • Incluso lo compararon con impregnar la pelota con olor, dejar que el perro huela ese olor y soltarlo en una zona reducida
  • Como Mythos no puede meter todo el código de una vez, probablemente varios subagentes lo hayan procesado por partes
    Al final, lo importante no es el modelo sino el harness (sistema de herramientas)