Google pausó los reportes de producto en su programa de recompensas por vulnerabilidades de OSS

El 4 de octubre de 2026, Google dejó temporalmente de aceptar reportes de fallas de producto para su programa de recompensas por errores de código abierto, aunque mantuvo abiertas las solicitudes sobre la cadena de suministro. Cuatro años antes, había ofrecido hasta $31,337 para atraer reportes de vulnerabilidades de terceros. Una parte de esa invitación quedó ahora en pausa.

En 2022, Google lanzó su Programa de Recompensas por Vulnerabilidades de OSS para premiar reportes sobre proyectos de código abierto. Su Programa de Recompensas por Vulnerabilidades, más amplio y separado, pagó $10 millones a 632 investigadores en 2023. Los dos programas tenían alcances distintos, pero ambos usaban recompensas para dirigir la atención externa hacia fallas que un proveedor podría pasar por alto.

Los agentes de IA pueden generar reportes de errores plausibles a menor costo sin necesariamente reducir el trabajo requerido para verificarlos. Los programas de recompensas por vulnerabilidades se crearon para competir por hallazgos escasos; su restricción más difícil está pasando a ser la capacidad de autenticar, reproducir, eliminar duplicados y actuar sobre lo que envían los investigadores.

La recompensa compraba atención cuando encontrar una falla era costoso

Antes, un investigador tenía que dedicar un esfuerzo considerable a inspeccionar un objetivo, desarrollar un hallazgo creíble y prepararlo para una divulgación coordinada antes de que un proveedor considerara un pago. El proveedor aún tenía que probar el reporte, pero el trabajo del investigador filtraba muchas posibilidades débiles antes de que llegaran a la cola de recepción. Las recompensas daban a los investigadores un lugar legítimo para enviar un hallazgo, un proceso de divulgación y una razón para revisar el software del proveedor en vez del de alguien más.

El programa de OSS de Google de 2022 aplicó ese acuerdo a proyectos de código abierto. Una recompensa mayor podía hacer que valiera la pena inspeccionar un objetivo difícil, pero no podía ayudar a un revisor a reproducir un reporte defectuoso.

DARPA lanzó su AI Cyber Challenge en 2023 para desarrollar sistemas que analizan código de fuente abierta en busca de fallas de seguridad. En abril de 2026, Bloomberg reportó que 360 Digital Security Group había utilizado un agente impulsado por IA para descubrir cerca de 1,000 vulnerabilidades antes desconocidas, incluidas fallas en Microsoft Office. Ninguno de los dos esfuerzos demuestra que los hallazgos automatizados sean ruido. Ambos muestran cuánto más fácil se está volviendo producir otro candidato para revisión.

Google cerró un canal de recepción, no el programa

El 4 de octubre, Google dijo que temporalmente ya no aceptaba solicitudes de vulnerabilidades de producto para OSS VRP. Los reportes sobre la cadena de suministro y los reportes pendientes no se vieron afectados, y Google planeaba una actualización para el Q1 de 2027. Google restringió una categoría particular de recepción en lugar de abandonar la divulgación externa o declarar que la investigación generada por IA carece de valor.

La razón reportada fue una afluencia de reportes inválidos impulsados por IA. Las afirmaciones de que ingenieros y mantenedores de código abierto estaban abrumados por miles de solicitudes descuidadas siguen sin verificarse. La pausa de Google no establece ni su volumen de solicitudes ni una tasa de reportes inválidos para toda la industria.

Otros operadores han enfrentado el mismo tipo de problema de capacidad. El proyecto curl planeaba terminar su programa de recompensas de HackerOne, citando reportes de baja calidad generados por IA. El Financial Times reportó que operadores de programas de recompensas por errores estaban agregando verificaciones de antecedentes y creando agentes de IA para el triage. Un mantenedor que recibe una afirmación plausible aún debe establecer la versión afectada, reproducir el comportamiento, evaluar el impacto y determinar si alguien ya lo reportó. Incluso un reporte que no supera esas verificaciones consume tiempo antes de poder descartarse.

Un hallazgo se vuelve valioso cuando otra persona puede probarlo

Un reporte escrito puede nombrar una función real y describir una falla plausible sin establecer que el software se comporta como se afirma. Una solicitud más sólida proporciona al destinatario una versión afectada, una ruta para reproducir el comportamiento, evidencia del impacto y suficiente procedencia para compararla con reportes anteriores. Esos materiales permiten a un mantenedor cuestionar la afirmación sin antes reconstruir toda la investigación del investigador.

OpenAI presentó Codex Security como un agente que encuentra, valida y propone correcciones para vulnerabilidades. OpenAI también dijo que su beta privada Aardvark mejoró la calidad de la señal, la precisión de la severidad y las tasas de falsos positivos. Las mismas herramientas que abaratan los candidatos pueden ayudar a probarlos. Las afirmaciones de OpenAI no establecen cuánto trabajo de los revisores desaparece en la base de código de otra organización, pero incorporan la validación al producto en vez de dejarla a quien abre la bandeja de entrada.

Artificial Analysis y sus socios tomaron una decisión relacionada en la medición. Su Cyber Index Alliance evalúa agentes para encontrar y corregir vulnerabilidades; CWE-Bench-AA incluye 120 tareas reservadas de auditoría y aplicación de parches. Como ocurre con los benchmarks de programación con IA en general, una puntuación solo es útil en la medida en que la prueba capture el trabajo en el que un destinatario debe confiar. Encontrar una línea sospechosa es distinto de reproducir un error, y producir un parche es distinto de demostrar que el parche no rompe el software.

Alguien todavía debe decidir qué nivel de impacto amerita una corrección de emergencia, quién es responsable del proyecto afectado y cuándo la divulgación es responsable. Esas decisiones necesitan un registro que otro mantenedor pueda inspeccionar.

Un descubrimiento más rápido vuelve más importante la transferencia hacia la reparación

La iniciativa Daybreak de OpenAI combina modelos, Codex Security y socios de seguridad para ayudar a las organizaciones a encontrar, validar y corregir vulnerabilidades de forma continua. Ese diseño conecta tareas que un programa de recompensas puede separar en distintas colas: un investigador presenta una afirmación, un revisor la verifica, un responsable la recibe y un mantenedor prepara una corrección. Cuando cualquier transferencia pierde los pasos de reproducción o la razón de una decisión de severidad, la siguiente persona tiene que repetir el trabajo.

Un verificador puede registrar el entorno y el comportamiento observado; un revisor puede adjuntar las decisiones sobre duplicados y severidad; un mantenedor puede probar un parche propuesto contra el mismo caso. Esa cadena es el trabajo práctico de la garantía operativa de IA, aunque no se ha demostrado que los agentes actuales completen cada paso de forma confiable.

La demora también tiene un costo adversarial. El Threat Intelligence Group de Google reportó lo que describió como el primer caso conocido de hackers que usaron IA para descubrir y convertir en arma un zero-day. Ese reporte no le dice a un operador de recompensas que acepte más rápido solicitudes débiles. Hace más útiles las solicitudes precisas y reproducibles: un proveedor que no puede distinguir una falla real de una falsa alarma persuasiva dedica tiempo a ambas, mientras que un atacante solo necesita la real.

El acceso de confianza ahorra tiempo de revisión al limitar quién entra

La selección de participantes es anterior al auge de reportes de IA. En 2020, la empresa de tecnología electoral ES&S se asoció con Synack para permitir que profesionales evaluados por Synack probaran algunos de sus productos. La evaluación dio a ES&S una manera de permitir escrutinio externo mientras decidía quién podía realizarlo. La empresa aceptó una participación más limitada a cambio de una relación que podía gobernar.

El programa de recompensas de dos niveles planeado por GitHub hace ese intercambio en la compensación: recompensas menores para solicitudes públicas y pagos más altos para investigadores solo por invitación, ante el volumen de reportes generados por IA. Apple introdujo un límite de solicitudes y un periodo de espera de 30 días, al tiempo que permite a los investigadores pedir cuotas mayores. Cada regla limita el trabajo que entra a la cola de un revisor antes de que este sepa si una afirmación particular es válida.

Un investigador desconocido puede encontrar una falla que un grupo evaluado no detecta, y un canal abierto puede llegar a partes de una base de código a las que no llega una lista de invitados. Las verificaciones de antecedentes, las cuotas y la reputación pueden proteger el tiempo de los mantenedores mientras excluyen trabajo útil. La validación asistida por máquinas ofrece otra forma de mantener la puerta más abierta, siempre que aporte evidencia que una persona pueda inspeccionar en vez de otro veredicto confiado que investigar.

El tope de $31,337 de Google anunciaba el valor de encontrar una falla. Su canal cerrado para fallas de producto mostró cuánto aún tiene que probar una afirmación antes de que ese premio signifique algo.