Google congela bug bounty por alucinaciones de IA
Google ha pausado su programa de recompensas por errores en código abierto hasta al menos el primer trimestre de 2027, debido a la avalancha de informes generados por inteligencia artificial que resultan mayormente inválidos. Esta decisión revela una crisis creciente en la intersección entre la IA generativa y el mantenimiento del software.
El programa de recompensas por errores de código abierto de Google está congelado. Por qué importa.
Google ha pausado su Programa de Recompensas por Vulnerabilidades en Software de Código Abierto hasta al menos el primer trimestre de 2027. La razón oficial: un aumento significativo en las submissiones automatizadas, la mayoría inválidas o producto de alucinaciones. La congelación entra en vigor el 1 de octubre y, aunque Google ha dirigido a los investigadores hacia sus otros programas de recompensas por errores, estos cubren ámbitos más estrechos: productos comerciales, no el extenso ecosistema de proyectos de código abierto propios de Google.
Esta es la primera plataforma importante en cuarentenar formalmente lo que la industria ha estado llamando “basura de IA”. La decisión revela algo incómodo sobre hacia dónde se dirige la IA generativa. Cuando los modelos pueden generar informes de seguridad convincentes pero fabricados a escala, no solo colman las bandejas de entrada. Socavan la infraestructura que mantiene el software seguro.
Qué ocurrió aquí
Según publicaciones en X y en el sitio web del programa, los ingenieros de Google y los mantenedores de código abierto fueron abrumados por informes que contenían detalles alucinatorios. No se trataba solo de submissiones con formato deficiente. Eran afirmaciones de vulnerabilidades con apariencia plausible que resultaban fabricadas al ser revisadas: con puntuaciones CVSS que sonaban realistas, rastros de pila que no correspondían a rutas reales del código y referencias a funciones que ya no existían o que habían sido refactorizadas del código meses antes.
Esta no es la primera vez que expertos en ciberseguridad advierten sobre este riesgo. TechCrunch informó el año pasado de que las submissiones generadas por IA estaban convirtiéndose en un problema serio para los programas de recompensas por errores en toda la industria. La congelación de Google es el primer reconocimiento institucional de gran envergadura de que la amenaza ahora es sistémica y no solo teórica. Confirma lo que muchos investigadores sospechaban: la relación señal-ruido en los informes de vulnerabilidades ha cruzado un umbral donde el triaje manual ya no es viable sin cambios estructurales significativos.
“La gran mayoría” de las submissiones automatizadas no son válidas, dijo Google. La redacción es deliberada y cuidadosa. No dice que todas sean falsas. Algunas probablemente son legítimas, y esa incertidumbre por sí sola hace más difícil detectar la señal. Cuando no puedes distinguir un zero-day real de una fabricación generada por IA sin un examen profundo a nivel de código, el costo de verificación se multiplica exponencialmente.
Efectos secundarios que se propagan
Las implicaciones van mucho más allá de los propios programas de Google. El ecosistema de código abierto opera bajo un modelo de confianza frágil. Los mantenedores aportan su tiempo de forma voluntaria. Los revisores invierten horas en validar afirmaciones. Cuando ese flujo de trabajo es bombardeado con ruido sintético, la infraestructura humana detrás de él se desgarra.
Los proyectos más pequeños son los más golpeados. Muchos repositorios de código abierto dependen de un puñado de mantenedores no remunerados que ya luchan contra el backlog. Una avalancha de informes alucinatorios consume ciclos de revisión que podrían dedicarse a trabajo de seguridad real, mejoras de código o documentación. El costo emocional de nadar entre afirmaciones fabricadas, a menudo escritas con suficiente especificidad técnica para parecer creíbles a primera vista, no es despreciable y contribuye al agotamiento en comunidades que ya están desatendidas.
También existe un efecto de enfriamiento sobre los investigadores legítimos. Las personas que construyeron reputaciones a través del programa podrían encontrar su trabajo devaluado por asociación con la inundación. Las futuras submissiones de investigadores de confianza podrían enfrentar un mayor escepticismo simplemente porque la barra para la credibilidad se ha elevado. El capital reputacional que los programas de recompensas por errores están diseñados para construir se está erosionando.
En el lado de la oferta, los proveedores de modelos de IA permanecen aislados. Google no identificó qué modelos generaron las submissiones y nadie está obligado a revelar esa información. Las empresas que desarrollan estos sistemas no enfrentan ninguna penalización por el ruido que producen sus herramientas. No existe un marco de responsabilidad que conecte las salidas alucinatorias con las plataformas que las distribuyeron.
El patrón más amplio
Esta congelación no es un incidente aislado. Es una vista previa de lo que ocurre cuando la calidad de la salida de IA se convierte en un problema de mantenimiento y no solo en un problema de contenido. Cada plataforma que dependa de contenido generado por usuarios —programas de recompensas por errores, moderación de foros, flujos de revisión de código, incluso pipelines automatizados de pruebas— enfrentará esta colisión en algún momento.
El software de código abierto depende de la confianza y la verificación. Un informe de vulnerabilidad es una afirmación que requiere escrutinio. Cuando el volumen de afirmaciones supera la capacidad de verificarlas, todo el sistema se degrada. Esto no es solo sobre Google. Cualquier organización que ejecute un programa de recompensas por errores o dependa de la investigación de seguridad impulsada por la comunidad enfrenta la misma dinámica. El patrón se repetirá en plataformas, lenguajes y tamaños de proyecto.
La colisión entre la IA generativa y el mantenimiento de código abierto está llegando sin importar si las plataformas están listas o no. Herramientas como GitHub Copilot y asistentes de IA similares ya están remodelando cómo los desarrolladores escriben código. Ahora las mismas herramientas están cambiando cómo reportan problemas en él, y no siempre de maneras que ayudan.
Qué sigue
Google prometió una actualización en el primer trimestre de 2027. Eso son aproximadamente ocho meses. Durante ese tiempo, el programa permanecerá cerrado a nuevas submissiones de código abierto. Los investigadores migrarán a otras recompensas o esperarán. Los mantenedores respirarán más tranquilos, al menos temporalmente. Pero el problema subyacente no desaparecerá.
Los modelos de IA seguirán mejorando en la generación de informes con apariencia plausible. El volumen de submissiones automatizadas probablemente aumentará, no disminuirá, a medida que el acceso a los modelos se amplíe y los costos de inferencia sigan cayendo. La congelación de Google es una pausa, no una solución. Es un disyuntor, no un rediseño.
Lo que se necesita es una reinterpretación fundamental de cómo los programas de recompensas por errores verifican las submissiones. Varias aproximaciones ya se están discutiendo en círculos de seguridad. Mecanismos de prueba de trabajo que requieran demostrar explotabilidad real, no solo describir una vulnerabilidad, podrían elevar el costo de generar informes falsos. Una integración más estrecha con herramientas de seguridad existentes y pipelines de análisis estático podría ayudar a filtrar automáticamente submissiones de baja calidad antes de que lleguen a los revisores humanos. Algunos investigadores han propuesto sistemas de triaje con peso de reputación donde la precisión histórica determina qué tan rápidamente se escalan los informes de un remitente.
Ninguna de estas opciones está resuelta. La congelación de Google es la primera respuesta honesta de la industria a una pregunta que nadie quería hacerse: ¿qué hacemos cuando la IA puede inundar nuestros sistemas con basura convincente?
La respuesta hasta ahora es: dejar de dejar entrar a la gente. Eso no es sostenible. Pero ahí estamos, y la comunidad de seguridad del código abierto deberá averiguar qué sigue antes de que llegue la próxima oleada.