Después de Mythos: por qué los bug bounties necesitan pruebas más duras

Hace unas semanas escribí sobre Anthropic Mythos y Project Glasswing. Entonces me interesaba sobre todo la línea grande: si los modelos se vuelven realmente mejores encontrando vulnerabilidades antiguas, combinando rutas de explotación y entendiendo bases de código completas, la investigación de vulnerabilidades cambia.

El nuevo artículo de Sophos sobre bug bounties en la era de Mythos muestra ahora la parte operativa de ese cambio.

Ya no se trata solo de preguntar si la IA encuentra mejores vulnerabilidades. Se trata de si los programas de bug bounty, los equipos de seguridad y las organizaciones de ingeniería pueden distinguir con suficiente rapidez entre basura, afirmaciones plausibles y problemas reales de seguridad.

El problema real no es solo el slop de IA

Cuando hoy se habla de IA y bug bounties, se piensa rápido en slop: informes generados automáticamente, errores medio entendidos, cadenas de explotación inventadas, afirmaciones que no se reproducen y mucho texto con poca sustancia.

Eso es real. Y para mantenedores, equipos de product security y personas de triage, es brutalmente molesto.

Pero solo es una parte.

La otra parte es más peligrosa: buenos investigadores pueden usar los mismos modelos para encontrar vulnerabilidades reales más rápido, probar hipótesis en bases de código más grandes y recorrer variantes de un patrón de forma sistemática. Lo que antes requería días o semanas de trabajo manual puede acabar en la cola en cuestión de horas.

Así cambia la pregunta. Antes era: ¿recibimos suficientes hallazgos externos buenos? Ahora se convierte en: ¿podemos reconocer, validar, priorizar y convertir en fixes los hallazgos reales con suficiente rapidez mientras el ruido aumenta?

Por qué Sophos es una fuente interesante

El artículo de Sophos no es un comentario genérico sobre IA. Sophos mira su propio programa de bug bounty y da números concretos.

Según Sophos, su programa público funciona en Bugcrowd desde diciembre de 2017. La empresa escribe que, hasta el momento del artículo, se habían recompensado 1.343 vulnerabilidades, con 7.091 envíos totales y 599.695 dólares pagados.

Para 2025 Sophos menciona, entre otras cosas:

• 59.400 dólares pagados por más de 52 informes
• unos 420 investigadores participantes
• hasta 80.000 dólares por Intercept X Endpoint bajo ciertas condiciones
• hasta 50.000 dólares por Sophos Central
• hasta 50.000 dólares por Sophos Firewall
• 13 bugs válidos de Sophos Firewall en 2025 con 21.500 dólares de pago total
• 13 bugs válidos de Sophos Central en 2025 con 11.650 dólares de pago total

No son cifras astronómicas, y precisamente por eso son interesantes. Muestran cuánto trabajo de clasificación hay detrás de un programa relativamente maduro. Miles de envíos no significan automáticamente miles de problemas relevantes. Y la IA probablemente no relajará esa relación.

La hará más dura.

La reproducibilidad se convierte en la entrada

La consecuencia más importante, en mi opinión, es banal pero incómoda: un informe de seguridad sin reproducibilidad limpia pierde valor.

No porque los equipos de triage sean perezosos. Porque su tiempo será más escaso.

Si un informe afirma mostrar ejecución remota de código, un bypass de autenticación o una exposición crítica de datos, tiene que demostrar con claridad:

• qué versión está afectada
• qué configuración es necesaria
• qué permisos necesita el atacante
• qué pasos llevan de forma reproducible al resultado
• qué logs, requests, trazas o capturas respaldan la afirmación
• qué impacto se ha demostrado realmente
• dónde termina la hipótesis y empieza la prueba

Suena estricto. Lo es. Pero será necesario si los equipos de seguridad no quieren ahogarse en textos que suenan plausibles.

Un informe generado por IA puede parecer muy convincente. Puede citar código, escribir con tono de CVE y simular una estructura limpia. Eso no lo hace cierto. A la inversa, un informe corto y seco con un buen proof of concept puede ser extremadamente valioso.

La nueva moneda no es la redacción. La nueva moneda es la evidencia.

La IA vuelve especialmente incómodos los bugs de autorización

Un punto del artículo de Sophos me parece muy práctico: la IA puede ayudar a escalar un bypass de autorización encontrado sobre superficies de alcance más grandes.

Eso encaja con lo que se ve en entornos SaaS reales. La autorización rara vez es un único interruptor. Vive en roles, tenants, IDs de objeto, subdominios, versiones de API, superficies de administración, endpoints móviles, rutas legacy y features medio migradas.

Si un investigador encuentra un patrón, la IA puede ayudar a probar variaciones:

• ¿El bypass afecta a un endpoint o a toda una familia?
• ¿Funciona solo dentro de un tenant o entre tenants?
• ¿Existe la misma lógica en APIs viejas y nuevas?
• ¿Están separadas de verdad las funciones de admin y usuario?
• ¿Se puede cargar un objeto por ID directo aunque la UI no lo mostraría?

Ahí la IA se vuelve peligrosamente útil. No como hacker mágico, sino como acelerador de pruebas aburridas, amplias y sistemáticas.

Y eso es malo para organizaciones cuya seguridad depende de que nadie tenga tiempo suficiente para probar las variantes aburridas.

Bug bounty no es un buzón de PR

Muchas empresas siguen tratando los bug bounties casi como un tema de imagen: tenemos un programa, luego somos abiertos, modernos y conscientes de la seguridad.

Eso ya no basta.

Un programa de bug bounty es un sistema de producción. Necesita reglas claras, buen triage, reproducción técnica, cercanía al producto, responsabilidad de ingeniería e integración con incident response. Si no, se convierte en un buzón público donde investigadores externos, slop de IA y atacantes reales comparten la misma entrada.

Sophos une dos puntos incómodos.

Primero: los buenos investigadores ayudan. La mirada externa, otros patrones mentales y la presión continua son valiosos.

Segundo: un sistema con dinero y confianza también puede abusarse. Sophos menciona experiencias alrededor de Pacific Rim, Asnarök y Personal Panda, donde la cercanía temporal entre explotación activa y reportes posteriores de bug bounty al menos planteó preguntas. Sophos no dice que todos esos reportes fueran maliciosos. Pero el punto operativo queda: un programa de bug bounty no puede construirse con ingenuidad.

En concreto:

• Los reportes deben correlacionarse con telemetría.
• Un nuevo hallazgo debería poder activar threat hunts retrospectivos.
• Triage debe saber si ya hubo intentos de explotación parecidos.
• La reputación del investigador ayuda, pero no sustituye la verificación técnica.
• Safe harbor es importante, pero no reemplaza la detección de abuso.

La realidad sobria es esta: los bug bounties forman parte de Secure by Design, no lo reemplazan.

Pruebas más duras también significan más responsabilidad

Aquí hay una tensión que no conviene suavizar.

Históricamente se pide a los investigadores: parad lo bastante pronto. Mostrad el bug, pero no vayáis demasiado lejos. No toquéis datos de clientes. No hagáis movimiento lateral. No ejecutéis acciones destructivas.

Eso es correcto.

Al mismo tiempo, la carga de prueba aumentará. Si la IA genera masas de informes plausibles pero falsos, los programas pedirán más evidencia. Entonces aparece la pregunta difícil: ¿cómo puede un investigador demostrar mejor el impacto sin entrar en comportamiento peligroso?

La respuesta no puede ser: “haced más”. Debe ser más controlada:

• reglas de engagement más claras
• entornos de prueba dedicados
• rutas de reproducción seguras
• límites acordados para probar impacto
• mejores sandboxes y laboratorios
• replays automatizados de proofs of concept

Para fabricantes grandes esto será casi obligatorio. Quien paga bounties altos en serio debería tener infraestructura para validar reportes con limpieza y rapidez.

Para proyectos pequeños es más amargo. Reciben la misma ola de slop, pero no los mismos recursos. Por eso algunos reducirán sus bug bounties financieros o los cerrarán. No porque no se tomen la seguridad en serio, sino porque operar el programa se convierte en una carga.

Qué pueden aprender admins y MSPs

Se podría decir que esto solo afecta a fabricantes y programas en Bugcrowd.

No lo creo.

El mismo mecanismo afecta a MSPs, equipos internos de IT y responsables de seguridad. Allí donde se evalúan hallazgos externos o internos, sube la presión:

• Los scanners entregan más findings.
• Los asistentes de IA los explican de forma más convincente.
• Los desarrolladores traen notas de seguridad generadas por IA.
• Los clientes preguntan por CVEs antes de entender el contexto.
• Management quiere saber si un riesgo es real o solo ruidoso.

La respuesta práctica no es ignorarlo todo. Es un proceso de validación más duro.

Para mí, al menos incluye estas preguntas:

1. ¿El problema es reproducible?
2. ¿El alcance afectado está claro?
3. ¿Existe una ruta de atacante realista?
4. ¿El impacto está probado técnicamente o solo afirmado?
5. ¿Hay logs o telemetría que puedan mostrar explotación?
6. ¿El fix es un parche, una configuración, un workaround o solo un vendaje?
7. ¿Hay que buscar retrospectivamente si ya fue explotado?

Suena a más trabajo. Lo es. Pero es mejor trabajo que reaccionar con pánico a cada informe bien escrito.

Por qué esto encaja con Mythos

Para mí, el punto decisivo de Mythos nunca fue solo: “wow, un modelo encuentra bugs”.

El punto era: si estas capacidades se vuelven más reales, baja el tiempo entre encontrar, entender, reproducir y explotar. Ahí golpea a los bug bounties. Están en la intersección entre investigación, potencial ofensivo, ingeniería y responsabilidad.

Sophos lo formula de forma parecida: la pregunta no es cómo detener submissions de IA. La pregunta es cómo mantener confianza y señal cuando buena investigación y ruido pueden producirse a velocidad de máquina.

Esa es, para mí, la mejor síntesis del problema.

No toda organización necesita un gran programa de bug bounty. Pero toda organización necesita mejores mecanismos para comprobar afirmaciones técnicas. La avalancha de información de seguridad no será menor. Será más rápida, más ruidosa y mejor redactada.

Mi valoración

Creo que el artículo de Sophos es un buen follow-up de Mythos porque saca el debate de la sala del modelo y lo lleva a la sala de operaciones.

Mythos es la señal espectacular. El triage de bug bounty es el banco de trabajo donde se ve si los procesos de seguridad aguantan.

Mi tesis es sencilla:

• Quien solo acumule más reportes perderá.
• Quien exija evidencia reproducible priorizará mejor.
• Quien conecte bug bounty, telemetría, ingeniería e incident response reaccionará más rápido.
• Quien vea la IA solo como generador de texto subestima su valor para el trabajo de seguridad sistemático.
• Quien no filtre el slop de IA quemará el tiempo de quienes deberían resolver problemas reales.

Suena menos glamuroso que un frontier model encontrando zero-days. Pero ahí se decide si la mejora de seguridad llega a los defensores o si todos se ahogan en más ruido.

Hasta la próxima,
Joe