El Bug bounty ha sido un tema muy candente últimamente.
Estamos viendo programas de alto perfil dejar de funcionar o cambiar fundamentalmente: el IBB (uno de los programas más importantes para proyectos de código abierto) está pausando las entregas, curl está eliminando los pagos y Node.js está eliminando por completo su programa de recompensas. Eso no es ruido, es una señal.
Quería entender hacia dónde se dirige realmente el Bug bounty, así que me senté con dos de las voces más creíbles en lados opuestos de esta conversación:
- Daniel Stenberg, creador de curl, quien está viviendo la realidad del mantenedor y recientemente detuvo los pagos de recompensas por errores
- Casey Ellis, el fundador de Bugcrowd, una de las personas que ayudó a establecer el modelo.
Lo que descubrí fue que el modelo de Bug bounty está en una encrucijada, y estamos en medio de un gran cambio.
Por qué el bug bounty funcionó tan bien
Antes de adentrarnos en la dirección que toma el modelo, retrocedamos y comprendamos por qué ha sido una de las ideas más efectivas en seguridad durante la última década.
Todo se basa en la idea de permitir que internet intente vulnerar sus sistemas antes de que lo hagan los atacantes. Y funcionó porque proporcionó a las empresas una escala que nunca podrían haber logrado contratando personal.
Como Casey lo expresó:
“Si intentas ser más astuto que un grupo global de atacantes con alguien que trabaja de 9 a 5, las cuentas no salen.”
Esa es la magia del bug bounty. En lugar de depender de un puñado de personas internas, accedes a un grupo global con diferentes conjuntos de habilidades, perspectivas y motivaciones, todos atacando tu sistema de formas que tu equipo interno simplemente no había considerado. Y todo ello sin los importantes costes generales que implica contratar expertos especializados internamente.
Por eso se convirtió en algo fundamental para los programas de seguridad modernos.
Qué está fallando ahora
Lo que está cambiando no es la demanda de seguridad, sino la economía de cómo opera el bug bounty.
La IA ha alterado el equilibrio, y no para bien. Encontrar errores es ahora más barato que nunca, redactar informes es aún más fácil, y enviarlos se ha vuelto prácticamente sin fricción. Mientras tanto, el coste de validar esos informes y de solucionar realmente los problemas no ha cambiado en absoluto.
- Encontrar errores → barato
- Redactar informes → más barato
- Enviar informes → prácticamente gratis
- Validarlos → sigue siendo caro
- Solucionarlos → muy caro
Estamos viendo cómo esto se desarrolla en la práctica. Hay tres tipos de remitentes de informes. Están las empresas que utilizan un nuevo enfoque para informes legítimos. Estos son informes que emplean enfoques de IA por capas que combinan las fortalezas de múltiples modelos de IA, guardrails, orquestación y contexto, como las propias capacidades de pentesting de IA de Aikido. Luego están los individuos que intensifican su investigación y redacción de informes con la IA como herramienta. Y, por último, hay individuos que son capaces de mejorar sus habilidades gracias a estos modelos de IA para generar informes que parecen técnicamente plausibles, pero que son completamente erróneos.
Daniel lo describió a la perfección: la basura más convincente es peor que la basura obvia.
No puedes descartarlo rápidamente, tienes que investigarlo, y pierdes tiempo real demostrando que es una tontería.
A escala, esto deja de parecer un modelo de contribución externa útil y empieza a asemejarse más a un ataque de denegación de servicio contra las personas responsables de la seguridad.
Y el impacto es devastador:
- El Internet Bug Bounty (IBB) pausó las nuevas entregas porque la IA ha aumentado drásticamente el volumen de descubrimientos más allá de lo que los mantenedores pueden gestionar.
- Node.js perdió su recompensa cuando la financiación desapareció; los informes siguen llegando, pero los pagos han cesado.
- curl eliminó las recompensas económicas después de ser inundado con informes generados por IA.
Este es un problema antiguo, amplificado
Casey enfatizó que este no es un problema nuevo, sino uno antiguo, solo que masivamente acelerado.
“Estamos haciendo cosas estúpidas más rápido y con más energía.”
Los programas de recompensas por errores (bug bounty) siempre han tenido un problema con la igualdad de condiciones: una persona envía un informe y otra tiene que validarlo. Esto suena equitativo sobre el papel, pero en la práctica, siempre ha sido difícil para una sola persona mantenerse al día con la validación, incluso antes de la existencia de la IA. Ahora, es prácticamente imposible.
Ahora estamos en un mundo donde cualquiera puede generar docenas de informes, hacer que parezcan creíbles y enviarlos al instante. Sin embargo, en el lado de la recepción, las limitaciones no han cambiado. Siguen siendo humanos quienes revisan, priorizan y toman decisiones.
Open source es el primero en sentir el impacto
El open source es donde esta presión se manifiesta primero, en gran parte porque ya operaba cerca de sus límites. La mayoría de los proyectos son mantenidos por pequeños equipos, a menudo voluntarios, con tiempo y recursos limitados, pero sustentan gran parte de internet.
Si añadimos incentivos financieros, participación global y ahora envíos generados por IA, el sistema se satura.
El programa IBB lo dijo directamente:
El descubrimiento asistido por IA ha alterado el equilibrio entre los hallazgos y la capacidad de remediación
Traducción:
Estamos encontrando más errores de los que podemos gestionar.
Así que ahora la recompensa ha desaparecido, y sin embargo la expectativa de informar persiste. Pero la pregunta es: ¿sigue siendo viable la forma en que se han utilizado los programas de recompensas por errores para escalar eficazmente los equipos de seguridad y mejorar la postura de seguridad sin incentivos financieros?
Casey no lo cree necesariamente así:
Toda organización debería tener un programa de divulgación de vulnerabilidades, porque si estás en internet, la gente encontrará problemas. Pero no todas las organizaciones están en posición de ejecutar un programa de recompensas público y basado en incentivos.
Según sus palabras, curl probablemente no debería haber tenido uno para empezar:
“No creo que todas las organizaciones deban [ejecutar un programa de recompensas]... el programa curl no debería haber sido un programa de recompensas en primer lugar.”
Y sin embargo, la experiencia de Daniel muestra algo más matizado. Daniel considera el programa de recompensas un éxito, porque incentivó un escrutinio real del código:
“Siempre lo he considerado un éxito porque es una excelente manera de animar a la gente a examinar el código…”
¿Qué ocurre cuando se eliminan los incentivos financieros?
Se podría suponer que al eliminar los incentivos financieros, se eliminaría el contenido de baja calidad generado por IA, pero también se reduciría la probabilidad de que se divulgaran vulnerabilidades genuinas.
Pero cuando curl eliminó los incentivos financieros, ocurrió algo interesante. El ruido de baja calidad generado por IA desapareció en gran medida.
Daniel dijo: “Hemos dejado de recibir informes de seguridad de baja calidad generados por IA… En su lugar, recibimos una cantidad cada vez mayor de informes de seguridad realmente buenos… enviados con una frecuencia nunca antes vista y que nos someten a una carga considerable.”
En lugar de ahogarse en informes de baja calidad, los mantenedores ahora se enfrentan a un gran volumen de hallazgos genuinamente útiles, muchos de los cuales están impulsados por investigación asistida por IA. La barrera de entrada ha disminuido, no solo para los informes malos, sino también para los buenos.
Lo que crea un nuevo tipo de presión.
Incluso los informes de alta calidad requieren tiempo para comprender, validar y corregir. Y muchos de estos hallazgos «buenos» aún caen en áreas grises, errores que quizás no cumplan los umbrales de seguridad, pero que aún requieren atención. El resultado es una carga sostenida y, en cierto modo, aumentada para equipos ya limitados.
Así, de una manera extraña, el sistema no se ha aliviado. Se ha refinado.
Romper el sistema para mejorarlo
Y aquí es donde se pone interesante. Porque si bien esto es claramente doloroso a corto plazo, en realidad podría ser un paso en la dirección correcta.
Al eliminar los incentivos financieros, eliminamos una gran parte del ruido. Lo que queda es una señal que es, en promedio, de mayor calidad, más intencionada y más alineada con los resultados de seguridad reales.
Al mismo tiempo, la IA está reduciendo la barrera para que los investigadores realicen un trabajo significativo. Está permitiendo que más personas encuentren problemas reales, más rápido que nunca. Esa combinación: menos ruido, más señal, pero aún un volumen abrumador, sugiere que estamos en una fase de transición.
El modelo actual se está rompiendo bajo la presión. Pero lo que está emergiendo debajo podría ser mejor.
Un sistema donde:
- la divulgación es esperada, no incentivada
- las recompensas son más específicas, no amplias
- y el enfoque cambia de más informes a mejores resultados
Todavía no hemos llegado. Ahora mismo, estamos en un punto intermedio caótico, donde el modelo antiguo ya no funciona y el nuevo aún no se ha formado completamente.
Pero si esto se desarrolla correctamente, no terminamos con menos bug bounty.
Terminamos con una versión más sostenible de ello.
Los hackers no van a desaparecer
Uno de los mayores conceptos erróneos en todo esto es la idea de que si el bug bounty tiene dificultades, los hackers de alguna manera desaparecen con él.
Así no es como funciona esto.
Los hackers no se detienen, se mueven. Siguen la oportunidad, la complejidad y las lagunas en el conocimiento. Cuando un área se satura, se trasladan a otra, ya sean APIs, cadenas de suministro, o ahora cada vez más sistemas de IA y fallos de lógica complejos.
Como señaló Casey, incluso si resolviéramos los problemas que tenemos hoy, los atacantes no simplemente harían las maletas y se irían a casa. Siempre habrá nuevas tecnologías, nuevos sistemas y nuevos errores que explotar.
Mientras los humanos construyan software, habrá vulnerabilidades.
Lo que significa que la necesidad de que las personas los encuentren no desaparece.
Sin embargo, los Hunters de bug bounty se están alejando del trabajo, en parte debido a la frustración que les causa tratar con triagers agotados, y en parte debido a la eliminación del incentivo financiero. En su lugar, se están trasladando a roles de consultoría y puestos de investigación interna.
Qué sucede a continuación
El bug bounty no desaparece de aquí, pero sí evoluciona.
Lo que probablemente estamos encaminándonos es un modelo donde la divulgación de vulnerabilidades se convierte en una expectativa básica en toda la industria, en lugar de algo opcional o incentivado. Los programas de recompensas públicos no desaparecen, pero se vuelven más controlados, más específicos y más alineados con la madurez organizacional.
Al mismo tiempo, la IA inevitablemente desempeñará un papel más importante en el filtrado y la clasificación del creciente volumen de informes. No resolverá el problema por completo, pero se convertirá en parte de cómo lo gestionamos.
También veremos un cambio en lo que realmente se recompensa. A medida que los sistemas automatizados mejoren en la detección de problemas de bajo nivel, el valor de esos hallazgos disminuirá. En su lugar, los incentivos se orientarán hacia trabajos de mayor impacto: aquellos que requieren creatividad, contexto y una comprensión más profunda de los sistemas.
Esto significa que los investigadores se centrarán cada vez más en áreas como el encadenamiento de vulnerabilidades, la explotación de la lógica de negocio y la ruptura de tecnologías complejas o emergentes donde la automatización aún presenta dificultades.
En otras palabras, el listón está subiendo, los investigadores no desaparecerán, pero las recompensas deben expandirse de igual manera.
