Google congela su bug bounty de código abierto: la avalancha de reportes generados por IA obliga a pausar el programa
Desde el 1 de octubre de 2026, el bug bounty de Google para código abierto ya no acepta vulnerabilidades de producto: la empresa lo atribuye a una avalancha de reportes generados por IA. Esto es lo que cambia, lo que sigue pagando y por qué se rompió el triaje.
Qué pasó el 1 de octubre de 2026
Google deja de aceptar vulnerabilidades de producto en el OSS VRP
El aviso se publicó en la cuenta oficial del programa y en el sitio Bug Hunters: desde el 1 de octubre de 2026, el Open Source Software Vulnerability Reward Program (OSS VRP) dejó de recibir reportes de vulnerabilidades de producto. No es el cierre del programa ni el final de sus pagos, sino la pausa de una de sus vías: la de fallos en productos del ecosistema de Google.
Aumento significativo de envíos automatizados: el motivo
Las palabras de la compañía son concretas y conviene no estirarlas: un "aumento significativo" de envíos automatizados y, de ellos, "la gran mayoría" inválidos. Google no publicó porcentajes ni cuántos reportes descartó, así que cualquier cifra exacta que veas circulando es una estimación de terceros, no un dato oficial.
Qué sigue funcionando
La pausa es parcial y vale la pena tener el mapa claro:
Lee también
- Los reportes de cadena de suministro del OSS VRP siguen aceptándose.
- Los reportes presentados antes del 1 de octubre no se ven afectados.
- Otros programas de recompensas de Google (Chrome, Android o Cloud) mantienen sus propias vías; la de Chrome, por ejemplo, sigue pagando por fallos como los que se corrigieron en la actualización de seguridad más reciente de Chrome.
- El Patch Rewards Program sigue abierto para mejoras de seguridad en proyectos de código abierto.
La promesa de una actualización en el primer trimestre de 2027
No hay fecha de reapertura. Google dice que trabajará en el rediseño de esta parte del programa y que dará una actualización en el primer trimestre de 2027. Eso es un compromiso de informar, no una promesa de volver a abrir.
Qué es el bug bounty de Google y por qué no es "el de todo el código abierto"
Un programa para software del ecosistema Google, nacido en 2023
El OSS VRP se anunció en agosto de 2023 y se centra en vulnerabilidades de software de código abierto ligado al ecosistema de Google. No es el bug bounty de todo el código abierto del planeta: un proyecto ajeno a ese ámbito tiene su propio programa, o ninguno.
Qué se pagaba: impacto real y cadena de suministro
El programa premiaba dos cosas distintas: fallos con impacto real en productos y compromisos de cadena de suministro, es decir, cuando alguien manipula el proceso por el que se construye o distribuye una dependencia. Esa segunda vía continúa activa.
Por qué la IA rompe un programa de recompensas
El que paga el resultado no paga el triaje
Un bug bounty paga por un resultado: una vulnerabilidad confirmada. No paga, en cambio, por el trabajo de comprobar si el resultado es real; ese coste lo asume quien recibe el reporte. Ahí está la grieta: escribir un informe que suena a informe cuesta hoy casi nada, mientras que leerlo, intentar reproducirlo y decidir si merece pago sigue costando tiempo humano.
Alucinación, código mejorable y vulnerabilidad real
Las tres cosas llegan con el mismo aspecto. Una alucinación de un modelo describe un fallo que no existe; un aviso de calidad de código señala algo mejorable sin impacto de seguridad; y una vulnerabilidad real es auténtica. Quien revisa no lo sabe hasta que intenta reproducirlo, así que el esfuerzo se gasta antes de saber si había algo.
Por qué el volumen no suma: el ruido tapa lo bueno
Miles de reportes no hacen al equipo más capaz de leerlos: le hacen cola. El riesgo de fondo no es recibir menos hallazgos, sino perder los buenos entre los malos. Si hay que revisar cien informes para encontrar uno cierto, la atención —el recurso escaso— se agota antes de llegar a él.
Por qué filtrar con IA no cierra el círculo
Un filtro automático puede descartar un reporte raro pero auténtico. Ese equilibrio entre ruido y falsos negativos es justo lo que Google venía ajustando con reglas y, al final, lo que lo llevó a pausar la vía de producto.
Lo que Google ya había intentado antes de pausar
Reglas más estrictas a comienzos de 2026: reproducción o parche fusionado
Antes de rendirse, Google endureció las reglas del programa a comienzos de 2026: para ciertos tramos de recompensa empezó a exigir pruebas de más calidad, como una reproducción en OSS-Fuzz o un parche ya fusionado en el proyecto. La idea era filtrar los informes flojos y centrarse en el impacto real.
Filtrar sin perder hallazgos reales: el dilema
Aun con esas reglas, el volumen siguió siendo demasiado para un equipo finito. Es el dilema de todo programa de recompensas: apretar el filtro reduce el ruido, pero también el riesgo de dejar fuera algo legítimo. Google eligió parar la vía de producto y replantearla.
No es un caso aislado: el patrón de 2026
curl cerró su bug bounty y su mantenedor lo contó en público
El proyecto curl cerró su programa de recompensas el 31 de enero de 2026, después de años en marcha, y su mantenedor, Daniel Stenberg, explicó públicamente por qué se había vuelto insostenible. Es contexto externo, no parte del caso de Google, pero dibuja el mismo patrón.
HackerOne pausó el Internet Bug Bounty
El 27 de marzo de 2026, HackerOne suspendió las nuevas presentaciones de su Internet Bug Bounty citando el aumento de hallazgos asistidos por IA; después llegaron ajustes en los pagos. Y proyectos mantenidos por voluntarios, sin presupuesto para triaje, congelaron sus programas.
El patrón común: descubrimiento barato, verificación cara
En todos los casos se rompe la misma pieza: encontrar candidatos se abarató, atenderlos no. Cuando esa asimetría crece, el programa deja de pagar por lo que recibe y empieza a pagar por limpiarlo. De fondo está la misma tensión que aparece cuando se parchean cero días explotados en masa: el trabajo de verificar no se automatiza solo.
Qué se pierde y qué se gana
El incentivo que desaparece
Lo que pierde el ecosistema es el incentivo económico para auditar ese software concreto: si no hay recompensa, hay menos ojos mirando. Lo que gana Google es tiempo: dejar de quemar horas humanas en ruido. Y el riesgo real no es tener menos reportes, sino perder los buenos entre los malos.
Qué puedes hacer tú: mantenedores, investigadores y quien financia
Si mantienes un proyecto
Escribe tu política antes de necesitarla: exige una prueba de concepto reproducible, la versión o el commit afectado y un impacto demostrable; pide un parche cuando sea posible y deja claro por escrito qué haces con los informes asistidos por IA. Un formulario con campos mínimos evita el "creo que aquí hay un problema" sin más.
Si investigas seguridad con ayuda de IA
Usar un asistente no es el problema; enviar sin verificar, sí. Un informe que sobrevive al triaje lleva un reproductor mínimo, evidencia, el parche si lo tienes y seguimiento. Mandar sin comprobar quema tu reputación y la del asistente que usaste.
Si financias un programa
Mide la tasa de reportes válidos, no el número de reportes. El volumen es fácil de inflar; la proporción de hallazgos reales dice si el programa está sano o ahogándose.
Qué mirar en 2027
Tres cosas, sin fecha cerrada: qué modelo de validación elige Google para reabrir esta vía, si el patrón se extiende a otros fabricantes y si aparecen estándares compartidos para reportes asistidos por IA. Por ahora, lo único confirmado es la actualización prometida para el primer trimestre de 2027.
Conclusión
La pausa del bug bounty de código abierto de Google no es el fin de los programas de recompensas ni una condena a la IA: es un programa que recibió más trabajo del que podía verificar. Si mantienes código o investigas seguridad, la lección práctica es sencilla: lo que se envía sin comprobar cuesta, y lo acaba pagando otro. Seguir leyendo el blog para ver cómo evoluciona el triaje de seguridad en 2027.
