Niveles de recompensa de bug bounty en los que los investigadores confían de verdad

Para definir niveles de recompensa de bug bounty en los que los investigadores confíen, haz cuatro cosas: asigna cada nivel de severidad a un modelo de puntuación (CVSS u otro específico para tu contexto), ancla cada nivel a datos de referencia con rangos mínimo y máximo en lugar de una cifra única, publica y bloquea la tabla y el alcance para que no puedan cambiar en silencio tras el envío, y reserva el dinero para el impacto reconociendo el trabajo de bajo impacto en un carril aparte. El error que destruye la confianza no es pagar poco. Es volver a tasar un trabajo ya terminado después de que el investigador lo envió, lo arreglaron y se le acreditó bajo las cifras antiguas.

Esa distinción es la historia completa de la primera mitad de 2026. En mayo, HackerOne le metió el hacha al Internet Bug Bounty (IBB), recortando las recompensas en todos los niveles de severidad, y buena parte de la reacción se centró en el momento, no en la cantidad. Si gestionas un programa de divulgación de vulnerabilidades (VDP) o un bug bounty joven y ves cómo se acumulan en tu bandeja los informes generados por IA, tienes dos miedos a la vez: ahogarte en basura y fijar cifras que más tarde tengas que recortar, quemando tu reputación ante la comunidad de investigadores. Ambos miedos son legítimos. Solo uno de ellos se resuelve recortando recompensas.

HackerOne recortó hasta un 89% las recompensas de bug bounty sobre trabajo que los investigadores ya habían hecho

En mayo de 2026, HackerOne redujo los niveles de recompensa del Internet Bug Bounty entre aproximadamente un 76% y un 89% en todos los frentes, y luego pausó el programa mientras evaluaba más ajustes. El IBB es el fondo común que paga por vulnerabilidades en dependencias de código abierto fundamentales, y había repartido más de 1,5 millones de dólares desde 2012, con un reparto 80/20 entre descubrimiento y apoyo a la remediación (fuente: InfoWorld / CSO).

Las cifras

No fueron ajustes menores. Aquí tienes la tabla de niveles antes y después, según el 18 de mayo de 2026:

Fuente: The Register, 21 de mayo de 2026. Un hallazgo de severidad media que antes valía casi dos mil dólares ahora paga menos de trescientos. HackerOne lo plantea así: el IBB es “un programa único y dinámico donde los niveles de recompensa se ajustan automáticamente en función de las contribuciones de los patrocinadores activos que participan”. Sobre la causa relacionada con la IA, la empresa dijo que “la investigación asistida por IA está ampliando el descubrimiento de vulnerabilidades en todo el ecosistema, aumentando tanto la cobertura como la velocidad. El equilibrio entre hallazgos y capacidad de remediación en el código abierto ha cambiado sustancialmente”.

Por qué es una cuestión de confianza, no de presupuesto

Un programa puede quedarse sin dinero. Un programa puede decidir que un nivel estaba sobrevalorado. Lo que indignó a los investigadores fue que el cambio se aplicara a trabajo que ya estaba terminado. Como lo expresó el investigador de seguridad Jakub Ciolek: “El problema de confianza aquí es que el cambio se aplicó en la práctica mucho después de que el trabajo ya estuviera hecho, arreglado y acreditado públicamente bajo una expectativa distinta” (fuente: The Register).

Un investigador recibió un pago de 297 dólares frente a una expectativa previa mucho más alta. El propio Ciolek seguía esperando el pago por unas vulnerabilidades de Argo CD reportadas en otoño de 2025 cuando llegaron los nuevos niveles. Su diagnóstico del momento más amplio es la tesis de todo este artículo: “El pago reducido es un síntoma. La economía del reporte de vulnerabilidades está cambiando muy rápido”. La lección no es dejar de pagar. Es cambiar las reglas hacia adelante, no hacia atrás.

La presión real: la IA no bajó la calidad de los bugs, subió el volumen de informes

La lectura honesta de 2026 es que la presión de la basura generada por IA es real y está documentada, pero el problema duradero es el volumen, no la IA en sí. Los programas no se ahogan porque la IA escriba bugs malos. Se ahogan porque la IA escribe muchos informes, y refutar uno verosímil pero falso le sigue costando tiempo real a un ingeniero senior.

El bandazo de curl: matar el programa y luego recuperarlo

curl es el caso documentado más claro, y corta por los dos lados. El mantenedor Daniel Stenberg cerró el programa con efecto a partir de febrero de 2026, diciendo: “El torrente actual de envíos pone una carga alta sobre el equipo de seguridad de curl, y esto es un intento de reducir el ruido” (fuente: The Register, 21 de enero de 2026). Durante años, los envíos asistidos por IA a curl no habían descubierto prácticamente nada genuino durante la era de la basura.

Luego la tendencia se dio la vuelta. En marzo de 2026, curl volvió a HackerOne porque la calidad de los informes de IA había mejorado hasta el punto de que “casi todos” sus informes —ahora buenos— eran asistidos por IA, aunque el volumen bruto se había duplicado más o menos año contra año (fuente: The New Stack). La conclusión: la IA no es enemiga permanente de la calidad de los informes. El cambio permanente es el volumen. Tu estructura de recompensas tiene que sobrevivir a una bandeja de alto volumen sin castigar a los investigadores que producen bugs reales.

El movimiento más discreto de GitHub: merchandising en lugar de dinero para bugs de bajo impacto

El 15 de mayo de 2026, GitHub anunció que los hallazgos válidos pero de bajo impacto recibirían reconocimiento en lugar de un pago: “Los envíos que no demuestren un impacto de seguridad significativo, pero que sí den lugar a una corrección en el código o la documentación, se reconocerán con merchandising de GitHub en lugar de un pago de recompensa”. La justificación fue explícita: “Preferimos que los investigadores inviertan su tiempo en investigación más profunda y de alto impacto, y que se les compense en consecuencia, antes que optimizar por volumen en hallazgos de bajo riesgo” (fuente: Blog de GitHub).

Ese es el mismo instinto económico que el recorte del IBB: reservar el dinero para el impacto, amortiguar el incentivo de volumen. Pero cayó de forma muy distinta, y esa diferencia lo es todo.

Cómo se ve algo “bien hecho”: la diferencia entre GitHub y el IBB

El movimiento constructivo y el polémico son mecánicamente parecidos. Ambos reducen lo que gana el trabajo de bajo impacto. Lo que los separa es el momento y el aviso.

GitHub cambió las reglas hacia adelante y publicó la justificación antes de que nadie enviara nada bajo los nuevos términos. Quien presenta un informe hoy sabe que un hallazgo de nivel “corrección de documentación” gana merchandising, no dinero, y se apunta con ese conocimiento. El recorte del IBB golpeó trabajo ya enviado y acreditado bajo las cifras antiguas. Misma dirección, resultado opuesto en términos de confianza.

No es una lección nueva. Allá por 2020, Bountysource anunció que “retendría” las recompensas no reclamadas mediante un cambio silencioso en sus términos de servicio, lo revirtió tras la reacción y vio cómo proyectos como elementary OS publicaban entradas tituladas “Adiós, Bountysource”. Los cambios retroactivos a un acuerdo de recompensa son el movimiento arquetípico para destruir la confianza. La plataforma de bug bounty de cripto Immunefi cristalizó el principio contrario en un texto titulado “The Bug Bounty Program Is Law” (el programa de bug bounty es ley): la página publicada del programa es vinculante, y un proyecto no puede renegociar retroactivamente un informe que ya se envió bajo ella.

La expectativa en el momento del envío debe ser igual a la expectativa en el momento del pago. Todo lo demás es negociable. Eso no.

Así que el marco que viene a continuación no va realmente de cifras. Va de hacer que tus términos publicados sean estructuralmente incapaces de traicionar a un investigador a posteriori.

Cómo definir niveles de recompensa de bug bounty que sobrevivan a la basura generada por IA

Define los niveles en cuatro pasos: áncalos a datos, publícalos y bloquéalos, haz que cada pago sea auditable y recompensa el esfuerzo con reconocimiento en vez de con un recorte de pago encubierto. Ninguno de estos pasos requiere un presupuesto a escala de HackerOne. Requieren disciplina, y son lo que separa a un programa en el que los investigadores confían del próximo titular de advertencia.

Paso 1: ancla los niveles a datos, no a intuiciones

Empieza por asignar cada severidad a un modelo de puntuación para que “crítico” signifique lo mismo siempre. CVSS es la opción habitual; un modelo específico para tu contexto funciona si tus activos no encajan limpiamente en CVSS. Después, tasa cada nivel a partir de datos reales de distribución en lugar de un número redondo que adivinaste.

Importan dos anclas:

• Referencias externas, sobre todo cuando empiezas. Las tablas de recompensas publicadas por Microsoft van de 500 a 30.000 dólares para aplicaciones y on-prem, y de 1.250 a 19.500 dólares para M365, con un récord de 17 millones de dólares pagados en 2024-2025 (fuente: MSRC). En todo HackerOne, el pago medio anual por programa activo ronda los 42.000 dólares, y la plataforma pagó 81 millones en total durante el último año, un 13% más (fuente: BleepingComputer). Una regla general común en el sector es que las organizaciones están dispuestas a pagar más de 7.000 dólares por una vulnerabilidad crítica, sin que exista un estándar universal.
• Tu propio historial, una vez que tengas alguno. La mediana, la media, el mínimo y el máximo que realmente has pagado por nivel de severidad y por tipo de vulnerabilidad te dicen dónde se sitúa la distribución real, de modo que puedes tasar el siguiente nivel con base en evidencia en vez de recortar en todos los frentes.

Usa niveles con rango (un mínimo y un máximo por severidad), no una cifra única y frágil. Los rangos te permiten recompensar una crítica excepcional en lo alto de la banda y una marginal en lo bajo sin reescribir la tabla. Esa es la práctica que recomiendan tanto Intigriti como el Bug Bounty Community of Interest, y es exactamente lo que les falta a los recortes generalizados como el del IBB.

Paso 2: publica y bloquea tus términos y tu alcance

Escribe la matriz de recompensas, los activos dentro y fuera de alcance, los tipos de vulnerabilidad excluidos, tus compromisos de SLA y tu cláusula de puerto seguro (Safe Harbor) en una única política publicada. Luego ponle versión, y trata la versión que un investigador aceptó al enviar como vinculante para ese informe.

Esta es la respuesta estructural a la queja sobre el IBB. Si los términos están publicados y bloqueados en el momento del envío, no hay mecanismo por el que un trabajo terminado se vuelva a tasar en silencio. El investigador se apunta a un trato conocido. Si quieres cambiar el trato, lo cambias para envíos futuros y lo anuncias, al estilo de GitHub.

Paso 3: haz que cada pago sea auditable

Cada recompensa y cada ajuste debería ser un evento explícito, registrado y defendible, con marca de tiempo y un motivo. Un libro mayor auditable hace dos cosas. Le demuestra a un investigador que la cantidad que recibió corresponde al nivel que se le prometió. Y en la rara ocasión en que de verdad ajustas una recompensa, muestra que el ajuste fue una decisión deliberada y registrada, no una nueva tasación automática y opaca.

El planteamiento del IBB de que “los niveles de recompensa se ajustan automáticamente” es justo lo que un libro mayor evita. Lo automático e invisible es lo que erosiona la confianza. Lo deliberado y registrado es lo que la preserva, aun cuando la cifra cambie.

Paso 4: recompensa el esfuerzo con reconocimiento, no con un recorte de pago encubierto

Los hallazgos válidos pero de bajo impacto merecen reconocimiento. La forma correcta de darlo es un carril de reconocimiento aparte y aditivo: puntos de reputación o karma, merchandising, una entrada en el salón de la fama. La forma incorrecta es disfrazar una reducción de dinero como “reconocimiento” en un trabajo que debería haberse pagado.

La política de merchandising para bajo impacto de GitHub es la versión limpia porque se anuncia por adelantado y convive con el dinero para bugs de alto impacto, sin reemplazar nunca el dinero prometido en trabajo ya enviado. El reconocimiento es un complemento de tus niveles de pago bloqueados. Nunca es una puerta trasera para volver a tasar.

Cómo hacerlo en Kit

El conjunto de herramientas CSIRT de Kit está construido en torno a exactamente estos cuatro hábitos, y ese es el punto: la disciplina la impone la herramienta, no se deja a la buena voluntad. Para ser claros, Kit es un producto joven de gestión de programas, no un marketplace con el volumen de pagos ni el conjunto de datos de referencia de HackerOne. El diferenciador es la estructura que impone, y esa estructura es la mayor parte de lo que sostiene la confianza.

• Niveles anclados a referencias. Agrega tus propias recompensas históricas (mediana, media, mínimo, máximo, ejemplos recientes) filtradas por nivel de severidad y tipo de vulnerabilidad, para que tases cada nivel con datos reales de distribución y puedas mostrarle a un investigador la mediana de su clase de bug. Los programas nuevos arrancan con referencias externas, como las bandas publicadas por Microsoft, hasta que tienen historial propio.
• Niveles con rango y publicados. Configura la matriz de recompensas como mínimo y máximo por severidad a lo largo de los niveles informativo, bajo, medio, alto, crítico y un nivel súper crítico, y luego publícala junto con el alcance, el SLA y los términos de puerto seguro como una política con versión que los investigadores aceptan al enviar.
• Un libro mayor auditable. Cada aprobación, ajuste y desembolso es un evento financiero tipado y registrado, filtrable por informe y fecha, de modo que el pago corresponde a la promesa y cualquier ajuste es una decisión registrada, no una nueva tasación silenciosa.
• Un carril de karma aparte. El reconocimiento no monetario corre junto a los niveles de pago bloqueados con preajustes fijos y transparentes, de modo que un hallazgo válido pero de bajo impacto recibe su honor sin que nadie disfrace un recorte de dinero como un agradecimiento.

Profundizamos en cómo mantener vivo un programa cuando la bandeja se inunda en el manual de triaje del VDP, y en cómo montar uno desde cero en cómo configurar un programa de divulgación de vulnerabilidades. Este artículo es la capa de diseño de recompensas que va encima de ambos.

Preguntas frecuentes

¿Puede un programa de bug bounty cambiar las recompensas después del envío?

Puede, pero no debería. La reacción contra el IBB en mayo de 2026 vino menos por el tamaño del recorte que por el hecho de que se aplicara a trabajo ya enviado, arreglado y acreditado bajo los niveles antiguos. El patrón defendible, que ejemplifica GitHub, es cambiar las recompensas solo hacia adelante, con aviso publicado, para que los investigadores se apunten a los nuevos términos a sabiendas. Trata la página publicada de tu programa como vinculante para cualquier informe enviado bajo ella.

¿Cuánto debería pagar por un bug crítico?

No hay un estándar universal; es un cálculo de riesgo. Como anclas orientativas, Microsoft paga hasta 30.000 dólares por hallazgos de aplicación de primer nivel, el programa medio de HackerOne paga unos 42.000 dólares al año en todos los niveles, y una regla general común sitúa a las organizaciones pagando más de 7.000 dólares por una crítica (fuentes: MSRC; BleepingComputer). Fija un rango mínimo-máximo por severidad anclado a esas referencias y a tu propio historial, no una cifra fija única.

¿Cómo gestiono los informes de bug bounty generados por IA?

No recortes las recompensas para desincentivarlos; eso castiga a los investigadores que producen bugs reales. El problema duradero es el volumen, no la IA. curl demostró que la calidad de los informes de IA puede pasar de no valer nada a ser “casi toda buena” en un año. Gestiona el volumen con triaje (filtrado, limitación de tasa, puntuación de reputación, protección del SLA) y gestiona el diseño de recompensas pagando por impacto y reconociendo el trabajo de bajo impacto por separado, de modo que el incentivo premie la calidad por encima del número de envíos.

En resumen

Cuando la IA inunda tu bandeja, el instinto es proteger el presupuesto recortando lo que pagas. El IBB muestra adónde lleva eso cuando el recorte golpea trabajo terminado: un agujero de credibilidad que ninguna cantidad de dinero rellena rápido. La respuesta duradera es estructural. Ancla tus niveles a datos reales, publica y bloquea los términos y el alcance, registra cada pago para que los ajustes sean deliberados y visibles, y recompensa el esfuerzo con un reconocimiento que se sume al dinero en vez de reemplazarlo. Hazlo y tu VDP seguirá siendo creíble cuando llegue la riada de IA, en lugar de convertirse en el próximo titular de advertencia.

Si estás diseñando una matriz de recompensas que quieres publicar hoy y no lamentar dentro de seis meses, empieza una prueba gratuita de Kit y configura desde el principio un programa con referencias, bloqueado y auditable.