Basura de IA en bug bounty: cómo triar un VDP bajo presión

Para triar informes de bug bounty generados con IA, activa cinco palancas en este orden: (1) un primer filtrado asistido por IA que marque automáticamente funciones alucinadas y la falta de prueba de concepto antes de que un humano lea el informe, (2) limitación de tasa en la entrada para que un solo actor no pueda inundar la cola, (3) un sistema de reputación que penalice la basura confirmada, (4) seguimiento de SLA que proteja el escaso tiempo de los revisores y (5) recompensas que paguen por impacto, no por número de envíos. Los programas que murieron en 2026 no tenían un problema de basura. Tenían un problema de triaje.

Si gestionas un buzón security.txt, un programa de divulgación de vulnerabilidades (VDP) o un bug bounty, ya lo estás notando. El volumen de envíos sube y la tasa de informes válidos se desploma. Cada informe plausible pero falso le cuesta igual a un ingeniero senior entre 30 minutos y tres horas de desmentirlo. Este es el problema de operar bajo carga: no se trata de “¿deberíamos tener un VDP?” (deberías, y ya explicamos cómo montar uno), sino de “la cola se está ahogando, ¿cómo la mantenemos viva sin quemar a los revisores ni perder a los investigadores de verdad?”.

Las víctimas de 2026: curl, HackerOne y Nextcloud

En la primera mitad de 2026, tres de los nombres más respetados en divulgación de vulnerabilidades se vinieron abajo de forma visible ante el ruido generado por IA. No son programas de tres al cuarto. Son la implementación de referencia de cómo se hace bien la divulgación, y todos chocaron contra el mismo muro: el coste de producir un informe falso cayó casi a cero, mientras que el de desmentirlo siguió siendo humano y alto.

Por qué curl tiró la toalla

curl cerró su bug bounty en HackerOne con efecto desde el 31 de enero de 2026. Su fundador, Daniel Stenberg, llevaba meses documentando el declive. En su entrada de julio de 2025 “Death by a thousand slops”, informó de que alrededor del 20 % de todos los envíos de 2025 eran basura de IA y de que solo un 5 % aproximadamente de los envíos de 2025 resultaron ser vulnerabilidades reales, una caída en picado respecto a años anteriores (fuente: daniel.haxx.se).

A nivel humano, los números eran demoledores. Cada informe ocupaba a tres o cuatro personas de su equipo de seguridad de siete durante entre 30 minutos y unas tres horas de trabajo de validación, casi todo voluntario. El arranque de 2026 le tomó la decisión por él: en los primeros 21 días de 2026, curl recibió unos 20 envíos y confirmó cero vulnerabilidades, incluidos siete informes en HackerOne dentro de una sola ventana de 16 horas (fuente: daniel.haxx.se; BleepingComputer).

Desde el 1 de febrero de 2026, curl deriva los informes al sistema de informes privados de GitHub y a [email protected] sin recompensa económica, de forma explícita y, en palabras de Stenberg, para “eliminar el incentivo de enviar porquería”. A lo largo de su existencia, el programa pagó por 87 vulnerabilidades confirmadas y más de 100 000 dólares desde 2019. El bounty funcionó durante años. Lo que lo rompió fue la basura de IA.

El repunte del 76 % de HackerOne y la pausa del Internet Bug Bounty

HackerOne tomó dos decisiones distintas. Primero, su Internet Bug Bounty (IBB), el fondo común que paga por las dependencias open source críticas, pausó la admisión de nuevos envíos a finales de marzo de 2026, alegando un desequilibrio entre el descubrimiento asistido por IA y la capacidad humana de corrección (fuente: Privacy Guides; InfoWorld).

Segundo, en abril de 2026, junto con el lanzamiento de un servicio de validación de pago, HackerOne reveló el dato macro de titular: los envíos de vulnerabilidades crecieron un 76 % interanual y alcanzaron un récord en marzo de 2026, mientras que alrededor del 25 % de los hallazgos se confirmó como explotable, una tasa que se mantuvo más o menos estable (fuente: nota de prensa de HackerOne). Léelo con atención: el número absoluto de bugs reales sigue creciendo, pero el ruido a su alrededor también, y crece más rápido. En mayo de 2026, el IBB recortó drásticamente los importes de las recompensas en todos los niveles de severidad (fuente: The Register).

Es un problema de todo el ecosistema

Sería fácil despachar a curl como un proyecto open source con pocos recursos y a HackerOne como los dolores de crecimiento de una plataforma. El patrón es más amplio que eso.

Fuentes: heise; Computing.co.uk; Cointelegraph vía TradingView.

La frase de Nextcloud es la más reveladora. No cerraron la admisión. Mantuvieron el canal abierto y dejaron de pagar hasta poder filtrar como es debido. Ese hueco —“queremos los informes pero no podemos permitirnos triarlos”— es exactamente el problema que aborda este artículo.

Por qué la basura de IA rompe la economía del bug bounty

Un bug bounty es un mecanismo de señal costosa. La premisa original: una persona invirtió esfuerzo real en encontrar un bug, así que produce un informe específico y reproducible, y triarlo merece el tiempo del revisor. Todo el modelo se sostiene sobre que el esfuerzo de enviar sea lo bastante caro como para filtrar el ruido en origen.

La IA hace saltar esa premisa por los aires. Convierte la producción de un informe de aspecto plausible en algo casi gratis, mientras que el coste de desmentirlo sigue siendo tercamente humano. Un informe generado puede citar un CVE de aspecto real, describir una función de aspecto real y exponer pasos de reproducción con total seguridad, todo alucinado. El revisor aun así tiene que abrir el código, rastrear la afirmación y demostrar la negativa. Demostrar que un bug es real es rápido. Demostrar que un falso convincente no lo es resulta lento.

Y va a peor. La IA tiende a sacar a la superficie muchas instancias del mismo problema de fondo —el mismo patrón de cross-site scripting con veinte payloads distintos— y a enviar cada una como un hallazgo aparte. El volumen se infla sin que la seguridad mejore. El cuello de botella se traslada por completo a la validación, que es la única parte del proceso que, por defecto, no puedes automatizar a bajo coste (fuente: Pen Test Partners).

Conviene no perder la perspectiva: los VDP y los bounties históricamente ya manejaban entre un 60 y un 80 % de envíos inválidos incluso antes de la IA (fuente: Yogosha). El impuesto del triaje siempre existió. La IA no inventó el problema. Eliminó el límite natural de tasa que lo hacía soportable.

El manual de triaje: cinco palancas que mantienen vivo un VDP

Esto no se arregla con una sola herramienta. Se arregla cambiando de nuevo la economía: subiendo el coste de enviar basura y bajando el de filtrarla. Aquí van las cinco palancas, ordenadas por apalancamiento.

1. Primer filtrado asistido por IA en la entrada. Clasifica automáticamente la basura evidente (funciones alucinadas, CVE inventados, sin prueba de concepto, lenguaje de plantilla) antes de que un humano le dedique una hora.
2. Limitación de tasa y control de spam. Un acelerador de ventana deslizante para que un solo actor no pueda inundar la cola en una ráfaga de 16 horas.
3. Sistema de reputación que penalice la basura. Haz que la basura confirmada le cueste algo al remitente, de modo que los reincidentes se autoexcluyan.
4. Seguimiento de SLA que proteja el tiempo del revisor. Acusa recibo y resuelve contra reloj para que los investigadores legítimos no se vayan a hacerlo público por frustración.
5. Recompensas por impacto, no por volumen. Paga por severidad, fija en cero los hallazgos meramente informativos y exige consolidación para que mil hallazgos idénticos se paguen una sola vez.

1. Primer filtrado asistido por IA en la entrada

El movimiento de mayor apalancamiento es dejar de permitir que los envíos en bruto lleguen primero a un humano. Una pasada de cribado con un LLM puede detectar las señales que comparten casi todos los informes basura: referencias a funciones o elementos de código que no existen, CVE citados como nuevos cuando tienen años o son inventados, plantillas genéricas de remediación y la ausencia de cualquier prueba de concepto específica y ejecutable.

La decisión de diseño clave es que esto sea asistencia, no rechazo automático. La primera pasada debe recomendar, no decidir: aprobado con alta confianza, requiere revisión o marcado. Un humano sigue dictaminando cualquier caso dudoso. No estás construyendo un robot portero. Estás construyendo un sombrero seleccionador que aparta la basura evidente de la atención de tus ingenieros senior.

2. Limitación de tasa y control de spam

curl recibió siete informes en 16 horas. Ningún equipo humano tria eso en tiempo real. Un sencillo acelerador de ventana deslizante —pongamos cinco informes por actor cada cinco minutos antes de un bloqueo temporal— neutraliza el patrón de ráfaga sin tocar a los investigadores legítimos, que casi nunca envían en sucesión rápida. Es la palanca más barata de implementar y una de las más eficaces contra la forma de ataque concreta de 2026.

3. Sistema de reputación que penalice la basura

Los sistemas de karma son viejos conocidos en el mundo de los bounties, pero la mayoría solo premia el trabajo válido. El entorno de 2026 exige lo contrario: la basura confirmada y el spam descartado deberían restar puntos. Cuando la reputación de un remitente cae, puedes condicionar sus futuros envíos o despriorizarlos de forma automática. La idea es que la basura cueste algo, para que a quien juega a inflar volumen deje de salirle a cuenta.

4. Seguimiento de SLA que proteja el tiempo del revisor

Aquí está la conexión que la gente pasa por alto: el seguimiento de SLA no va solo de responder rápido. Va de no perder a los buenos investigadores. Los investigadores de verdad acaban haciéndolo público cuando se retrasan los acuses de recibo, cuando las correcciones se publican en silencio o cuando la severidad se rebaja a la chita callando, que es justo el fallo que analizamos en cuando los investigadores lo hacen público. Bajo la carga de basura, los tiempos de acuse de recibo son lo primero que se resiente, y es precisamente cuando menos te puedes permitir ahuyentar a quienes informan de verdad enterrados en el ruido. Un reloj de acuse de recibo (por ejemplo, 72 horas) más objetivos de resolución por severidad mantiene coordinados contigo a quienes más te interesa conservar.

5. Recompensas por impacto, no por volumen

Si tu bounty paga por hallazgo aceptado sin importar la severidad, estás pagando a la gente por enviar volumen, y la IA encantada de complacerte. Vincula los pagos a una matriz de severidad en la que los hallazgos informativos paguen 0 $ y solo el impacto real pague dinero real. Acompáñalo de deduplicación para que mil instancias de un mismo bug de raíz se resuelvan en un solo ticket y un solo pago. Esta es exactamente la palanca que curl accionó al final: quitar el incentivo económico de enviar porquería. No tienes que llegar hasta el cero como hizo curl, pero sí tienes que dejar de premiar la cantidad.

No tires por la borda a los buenos investigadores asistidos por IA

El enemigo es el volumen sin validar, no la IA. Esta distinción importa, porque la reacción perezosa —“prohibamos los informes asistidos por IA”— descartaría a tus mejores colaboradores.

El contraejemplo más claro es Joshua Rogers, cuyo trabajo asistido por IA sacó a la luz unos 50 bugs reales en curl, cada uno validado por un humano antes de enviarlo. Las mismas herramientas que los vendedores de basura, el resultado opuesto, porque entre el modelo y el botón de enviar había una persona competente. Stenberg ha sido explícito en que la investigación responsable asistida por IA es bienvenida; lo que no puede sostener es la avalancha de resultados sin revisar.

Así que el cometido del manual es preciso: filtrar por evidencia y validez, no por si hubo IA de por medio. Un informe con una prueba de concepto que funciona y una referencia de código real pasa, lo haya redactado un humano o un modelo. Un informe con funciones alucinadas y sin PoC suspende por el mismo motivo, sea quien sea su autor. Criba la señal, no la herramienta.

Cómo lleva Kit el manual a la práctica

Aquí va la verdad incómoda para cualquier equipo que se plantee construir esto en casa: las cinco palancas de arriba son más o menos seis meses de tooling interno. La vertical Csirt:: de Kit las implementa como configuración. La correspondencia es casi de uno a uno.

Una precisión sobre el cribado con IA: es triaje asistido —una recomendación más una puntuación de confianza—, no un rechazo automático. Los humanos siguen dictaminando cada flag y cada review. Kit no pretende bloquear toda la basura. Filtra la primera pasada y vuelve a fijar el precio de los incentivos para que las horas de tus revisores vayan a bugs reales, de modo que un informe tipo Joshua Rogers con una PoC funcional pase de largo mientras uno alucinado queda atrapado.

La conclusión: un problema de basura es en realidad un problema de triaje

Los programas que murieron en 2026 no los venció la IA. Los venció una canalización de entrada construida para un mundo de señal costosa que ya no existe. La basura no es más que volumen. El fallo fue estructural: ni primera pasada automatizada, ni límite de tasa, ni penalización de reputación, y un bounty que pagaba por cantidad.

Cada uno de esos puntos tiene arreglo, y cada uno es un ajuste antes que un proyecto de investigación. Si vas a montar un programa desde cero, empieza por la guía de configuración de un VDP. Si ya estás con el agua al cuello, el movimiento es volver a cambiar la economía: automatiza la primera pasada, frena las inundaciones, haz que la basura cueste algo, protege el tiempo de tus revisores con SLA y paga siempre y solo por impacto real. Deja fuera los informes que mataron a curl y dentro los del tipo de Joshua Rogers.

Eso es exactamente para lo que está hecho el módulo CSIRT de Kit. Empieza una prueba gratuita y convierte un buzón desbordado en una cola filtrada, con límite de tasa y respaldada por SLA.