Google pausa su programa de recompensas por errores de código abierto mientras los informes de IA desbordan a los revisores
Google pausó su programa de recompensas por errores de código abierto después de un aumento de informes automatizados, y afirmó que la gran mayoría no eran válidos. La suspensión comenzó el 1 de octubre de 2026 y afecta a los nuevos envíos de vulnerabilidades de productos al Open Source Software Vulnerability Reward Program.
La decisión plantea una marcada contradicción para la investigación de seguridad asistida por IA. Los modelos ya pueden inspeccionar más código y producir informes convincentes a una velocidad sin precedentes. Sin embargo, cada envío sigue requiriendo que una persona determine si la falla alegada existe, importa y puede reproducirse.
Google no está sola. Curl puso fin a las recompensas monetarias después de que su tasa de vulnerabilidades confirmadas cayera por debajo del 5 % en 2025. Los mantenedores de Linux también han modificado las prácticas de divulgación tras recibir oleadas de hallazgos de IA duplicados. En conjunto, estos casos muestran que el descubrimiento de vulnerabilidades ha escalado más rápido que su revisión.
El programa de recompensas de Google para código abierto deja de aceptar informes de productos
Google ha cerrado temporalmente un importante canal de recepción porque los envíos automatizados generaban más trabajo de revisión que hallazgos de seguridad útiles.
El Google OSS VRP, abreviatura de Open Source Software Vulnerability Reward Program, recompensa a los investigadores que divulgan de forma responsable fallas de seguridad en proyectos de código abierto elegibles. Google lanzó el programa en 2022 para cubrir software mantenido en sus repositorios públicos y determinados proyectos externos.
Ese canal de vulnerabilidades de productos dejó de aceptar nuevos informes el 1 de octubre. Google indicó que espera ofrecer otra actualización durante el primer trimestre de 2027.
“Esta pausa se debe a un aumento significativo de los envíos automatizados, la gran mayoría de los cuales no son válidos”, afirmó Google en su aviso. La formulación importa porque distingue la automatización de la investigación de vulnerabilidades verificada.
La pausa no elimina los informes enviados antes de la fecha límite. Tampoco cierra todas las vías asociadas al programa más amplio. Los envíos de vulnerabilidades de la cadena de suministro siguen siendo elegibles, según las reglas del programa actualizadas.
Algunas vulnerabilidades relacionadas con repositorios de Google Cloud aún pueden calificar mediante el Cloud VRP. Google también ha dirigido a los investigadores a sus otros programas de recompensas mientras revisa el proceso de recepción de informes de código abierto.
Ese alcance más limitado hace que “congelación” sea más preciso que “cierre”. Google ha suspendido los nuevos envíos de vulnerabilidades de productos dentro del programa OSS, no ha abandonado la investigación de seguridad externa en toda la empresa.
La compañía no ha publicado un recuento de envíos, una tasa de informes inválidos ni el volumen total de trabajo pendiente de clasificación para el canal afectado. Por tanto, las afirmaciones de que los revisores recibieron una cifra concreta de informes defectuosos siguen sin verificarse.
Lo que Google sí reveló es la señal decisiva. Los informes automatizados se habían vuelto lo bastante numerosos y poco fiables como para que el proceso existente dejara de ser sostenible.
Ese proceso depende de algo más que recibir un documento bien redactado. Un revisor debe inspeccionar la ruta de código, recrear las condiciones, evaluar la explotabilidad, buscar duplicados e identificar al equipo responsable del proyecto.
Un informe plausible puede consumir mucho tiempo incluso cuando es incorrecto. Los modelos de lenguaje grandes agravan el problema porque pueden producir explicaciones detalladas, fragmentos de código y afirmaciones de gravedad contundentes sin demostrar la vulnerabilidad subyacente.
Google ya había endurecido sus reglas a principios de 2026 tras observar un “aumento masivo” de informes generados por IA. La pausa de octubre sugiere que los requisitos de filtrado por sí solos no restablecieron una relación señal-ruido aceptable.
El programa de recompensas de Google para errores de código abierto se ha convertido así en un caso de prueba para un problema de seguridad más amplio. Generar una afirmación es ahora barato, mientras que refutarla sigue siendo caro.
Por qué los informes de errores de IA generan un coste asimétrico
La IA cambia la economía de la divulgación porque una máquina puede generar informes más rápido de lo que los mantenedores pueden validarlos.
La búsqueda tradicional de errores impone costes significativos al investigador. Una persona debe comprender una base de código, aislar un comportamiento inesperado, comprobar si genera un impacto de seguridad y documentar un caso reproducible.
La IA generativa reduce parte de esa carga de trabajo. Un agente puede analizar repositorios, seguir funciones, comparar patrones, redactar código de prueba de concepto y convertir hallazgos preliminares en informes de apariencia profesional.
Estas capacidades pueden ayudar a investigadores legítimos. También pueden permitir que usuarios inexpertos presenten afirmaciones que no entienden ni pueden defender durante las preguntas de seguimiento.
La asimetría aparece después del envío. Producir otro informe puede requerir poco esfuerzo adicional, pero clasificarlo sigue consumiendo una atención de ingeniería escasa.
Christopher Robinson, director de tecnología de la Open Source Security Foundation, describió la carga en un informe de seguridad de marzo. Los proyectos populares recibían antes dos o tres informes durante una semana promedio, estimó. Algunos más tarde recibieron cientos de una vez.
Robinson dijo que un informe individual puede requerir entre dos y ocho horas de trabajo no planificado por parte de los mantenedores. Ese coste existe incluso cuando la respuesta final es que no existe vulnerabilidad alguna.
Los falsos positivos no son el único problema. Los sistemas automatizados pueden enviar hallazgos duplicados, interpretar erróneamente comportamientos documentados, ignorar modelos de amenazas o exagerar defectos de bajo impacto.
Una vulnerabilidad alucinada resulta especialmente costosa porque el informe puede sonar internamente coherente. Los revisores pueden seguir un argumento técnico detallado antes de descubrir que se inventaron una función, una ruta de control o una condición de explotación citadas.
Vlad Ionescu, cofundador de la empresa de seguridad de IA RunSybil, describió esa experiencia en una anterior investigación sobre contenido basura de IA. Dijo que los informes pueden parecer técnicamente sólidos hasta que los revisores investigan y descubren que el modelo fabricó los detalles.
Esto crea un cuello de botella de verificación. La IA amplía la oferta de posibles hallazgos, pero no amplía automáticamente el número de revisores de confianza.
Los programas de recompensas por errores también crean un incentivo financiero para presentar afirmaciones inciertas. Un investigador puede enviar muchos informes especulativos mientras los mantenedores absorben la mayor parte del coste de validación.
Los sistemas de reputación y los límites de tasa pueden reducir el abuso, pero introducen sus propias concesiones. Barreras estrictas pueden excluir a nuevos investigadores que carecen de historial en la plataforma, pero poseen un hallazgo legítimo.
Los requisitos de identidad pueden desalentar la divulgación responsable de personas que enfrentan riesgos legales, profesionales o geográficos. Las tarifas de envío crearían una barrera aún mayor.
El filtrado automatizado presenta otra complicación. Un filtro que rechace informes porque parecen generados por máquinas puede descartar vulnerabilidades genuinas encontradas o documentadas con ayuda de IA.
La distinción esencial no es si la IA intervino en el informe. Es si quien lo presenta verificó el comportamiento y puede respaldar la afirmación con evidencia reproducible.
Ese estándar se vuelve más difícil de aplicar cuando los agentes pueden crear documentos persuasivos a escala. La calidad del texto ya no proporciona una señal fiable de la calidad de la investigación.
La respuesta práctica probablemente implicará requisitos de evidencia más estrictos. Los programas pueden exigir reproducciones mínimas, detalles de las versiones afectadas, rastros de explotación, casos de prueba o parches funcionales antes de asignar una revisión humana.
Estos requisitos devuelven parte del coste de verificación al remitente. También favorecen a investigadores que entienden el código y permanecen disponibles para responder preguntas.
El problema de los informes de errores de IA de Google también es un éxito de la seguridad con IA
La misma tecnología que genera envíos de baja calidad está encontrando vulnerabilidades reales que los investigadores humanos pasaron por alto.
Tratar cada informe asistido por IA como basura interpretaría mal la evidencia. Los modelos avanzados han demostrado capacidades significativas de análisis de código en condiciones controladas.
Anthropic afirmó que Claude Opus 4.6 encontró más de 500 vulnerabilidades previamente desconocidas en proyectos de código abierto durante pruebas internas. Según la empresa, investigadores de seguridad humanos o externos validaron cada hallazgo antes de su divulgación.
Mozilla recibió 112 informes de ese esfuerzo durante dos semanas. Emitió 22 avisos de seguridad, incluidos 14 por fallas de alta gravedad, mientras clasificaba muchos de los hallazgos restantes como errores no relacionados con la seguridad.
Esos resultados ilustran un proceso distinto del envío automatizado masivo. Anthropic combinó el descubrimiento por máquinas con validación humana, divulgación coordinada y una comunicación centrada con los mantenedores.
En un caso, según se informó, el modelo creó una prueba de concepto para demostrar que una falla sospechada era real. Ese paso convierte un patrón especulativo en evidencia que los revisores pueden probar.
Los hallazgos de Firefox también muestran por qué prohibir por completo la investigación con IA sería contraproducente. Los modelos pueden examinar código maduro y sometido a numerosas pruebas, y aun así detectar defectos importantes.
Por tanto, el conflicto no es entre humanos e IA. Es entre investigación verificada y generación de informes sin rendición de cuentas.
Un flujo de trabajo de alta calidad asistido por IA mantiene a una persona responsable. Esa persona verifica el resultado, elimina falsos positivos, comprende el impacto y asume la responsabilidad de comunicarse con los mantenedores.
Un flujo de trabajo de baja calidad trata el punto final de divulgación como otro destino automatizado. El agente identifica un patrón, redacta una narrativa de gravedad y la envía sin una reproducción independiente.
Ambos flujos de trabajo pueden producir una prosa pulida. Solo uno reduce la carga de trabajo del receptor.
Esta distinción explica por qué la pausa de Google no demuestra que la búsqueda de errores con IA haya fracasado. Muestra que su arquitectura de envíos no podía absorber la mezcla actual de hallazgos valiosos, duplicados y alucinaciones.
La seguridad asistida por IA podría acabar mejorando ambos lados de esa arquitectura. Los programas pueden utilizar modelos para agrupar duplicados, comparar afirmaciones con problemas conocidos, probar rutas de explotación e identificar evidencia faltante.
HackerOne y otras plataformas han empezado a introducir asistencia de clasificación basada en IA. Estas herramientas pueden priorizar informes, pero su rendimiento debe medirse frente a las tasas de rechazos erróneos y de vulnerabilidades no detectadas.
Un revisor automatizado también puede alucinar. Si los programas sitúan un modelo entre los investigadores y los mantenedores, necesitan vías de escalamiento para los hallazgos que el filtro no pueda clasificar con confianza.
El modelo más sólido probablemente sea uno por capas. Las máquinas realizan comprobaciones de bajo coste, los clasificadores experimentados revisan los informes que superan el filtro y los mantenedores de proyectos se encargan solo de los hallazgos creíbles.
Ese enfoque se asemeja a la integración continua para las contribuciones de software. Las pruebas rechazan fallos evidentes antes de que un mantenedor dedique tiempo a una revisión detallada.
Las afirmaciones de seguridad siguen siendo más difíciles de probar que los cambios de código ordinarios. La explotabilidad depende del contexto, la configuración, los límites de confianza y las capacidades del atacante, factores que las comprobaciones automatizadas pueden malinterpretar.
Aun así, exigir evidencia verificable por máquinas puede mejorar el nivel de partida. Un informe con una prueba fallida, un rastro de ejecución o un bloqueo reproducible ofrece a los revisores algo concreto que evaluar.
Las organizaciones también necesitan registros duraderos de este trabajo. Una base de conocimientos de ingeniería con capacidad de búsqueda puede ayudar a los equipos a comparar nuevos hallazgos con informes, decisiones y correcciones anteriores.
El objetivo no es ralentizar los descubrimientos legítimos. Es impedir que la generación ilimitada consuma un presupuesto limitado de revisión humana.
Curl y Linux Demuestran que Es un Problema de Toda la Industria
La pausa de Google sigue un patrón en el que los proyectos de código abierto restringen los canales de divulgación después de que la IA desborda los sistemas de confianza existentes.
Curl ofrece el ejemplo anterior más claro. El proyecto de transferencia de datos ampliamente utilizado puso fin a su recompensa monetaria por errores el 31 de enero de 2026, después de operar el programa desde 2019.
El mantenedor Daniel Stenberg afirmó que el programa había producido 87 vulnerabilidades confirmadas. Sin embargo, la tendencia de calidad se deterioró drásticamente durante 2025.
Curl anteriormente confirmaba como vulnerabilidades más del 15 % de los envíos. La tasa cayó por debajo del 5 % en 2025, lo que significa que menos de uno de cada veinte informes resultó válido.
Stenberg atribuyó la situación a tres tendencias conectadas: contenido basura generado por IA, la disminución de la calidad en otros envíos y reporteros centrados en las recompensas en lugar de mejorar el proyecto.
«Las interminables presentaciones de contenido basura suponen una carga mental seria para gestionarlas», escribió al anunciar la decisión de curl.
Curl no dejó de aceptar divulgaciones de seguridad. Eliminó las recompensas monetarias, mantuvo HackerOne como canal recomendado y dirigió a los investigadores hacia informes privados en GitHub o el correo electrónico.
Esa respuesta se dirigió a los incentivos, en lugar de a la tecnología en sí. Stenberg sostuvo que las recompensas atraían descubrimientos legítimos, pero también facilitaban demasiado los envíos especulativos.
Reconoció la disyuntiva. Eliminar los pagos puede reducir el ruido, pero también debilitar los incentivos para investigadores independientes cualificados que dedican mucho tiempo a investigaciones difíciles.
La comunidad del kernel de Linux se enfrentó a un problema relacionado con hallazgos duplicados. Varios investigadores ejecutaron herramientas de IA similares contra el mismo código y enviaron los mismos problemas a través de un canal privado.
La divulgación privada impedía que los investigadores vieran que otra persona ya había informado o debatido un hallazgo. Los mantenedores redirigieron repetidamente los duplicados o señalaron correcciones que ya estaban disponibles públicamente.
Linus Torvalds describió la lista privada de seguridad como «casi totalmente inmanejable». Argumentó que los hallazgos detectados por IA deberían generalmente pasar por los canales públicos del proyecto, salvo que el secreto sea realmente necesario.
La documentación de Linux también elevó el estándar esperado para quienes envían informes. Los investigadores deben aportar pruebas concisas, contactar a los mantenedores pertinentes y contribuir con un parche cuando sea posible.
Esa política preserva la responsabilidad humana. La IA puede ayudar en el descubrimiento, pero una persona debe comprender el informe y seguir siendo responsable de sus consecuencias.
Google, curl y Linux eligieron intervenciones diferentes porque sus programas tienen estructuras distintas. Google pausó una categoría de envíos. Curl eliminó las recompensas. Linux redirigió muchos informes y enfatizó la gestión pública.
Su conclusión compartida es más importante que los detalles de cada política. La recepción abierta sin costes significativos para el envío no funciona cuando los agentes automatizados pueden generar afirmaciones casi ilimitadas.
Los proyectos más pequeños enfrentan el mayor riesgo. Google puede asignar ingenieros y rediseñar infraestructura, mientras que los mantenedores voluntarios pueden no contar con ningún equipo dedicado de triaje.
El software de código abierto suele estar integrado en productos comerciales, servicios en la nube, herramientas de desarrollo y sistemas críticos. Sin embargo, la responsabilidad de revisar los informes de seguridad puede recaer en unos pocos colaboradores no remunerados.
La IA amplifica este desajuste. Permite que personas externas analicen código importante de forma continua sin aportar el trabajo necesario para validar, corregir y coordinar cada posible hallazgo.
El resultado se asemeja a un problema de denegación de servicio, incluso cuando quienes presentan los informes tienen buenas intenciones. Cada informe exige atención de los mantenedores, y el volumen combinado puede desplazar vulnerabilidades genuinas.
Los Filtros Más Estrictos También Pueden Ocultar Vulnerabilidades Reales
Los programas deben reducir el volumen de baja calidad sin crear un sistema de seguridad al que solo puedan acceder investigadores consolidados.
La pausa de Google protege a los revisores a corto plazo, pero también elimina una vía de reporte para descubrimientos legítimos. Una vulnerabilidad válida en un producto descubierta después del 1 de octubre puede requerir otro programa elegible o canal de divulgación.
Esa fricción importa porque los investigadores no siempre comprenden los límites organizativos de una empresa. Un fallo en un repositorio de código abierto puede afectar a un producto en la nube, una dependencia o una aplicación posterior.
Las reglas de enrutamiento complicadas aumentan el riesgo de una divulgación tardía o mal dirigida. También pueden fomentar la publicación pública cuando los investigadores no pueden identificar un canal privado aceptado.
El acceso basado en la reputación crea otro riesgo. Es más fácil confiar en investigadores experimentados, pero los nuevos participantes han contribuido históricamente con descubrimientos importantes a los programas de recompensas.
Un sistema que favorece a identidades consolidadas puede reproducir las brechas de acceso existentes. Puede perjudicar a investigadores independientes, estudiantes y personas fuera de las principales comunidades de seguridad.
Los requisitos estrictos de prueba de concepto también pueden volverse peligrosos. Demostrar la explotabilidad puede requerir gestionar datos reales, eludir salvaguardas o realizar pruebas que infringen las reglas del programa.
Por ello, los programas necesitan estándares de evidencia sólidos pero seguros. Un reproductor mínimo, una prueba controlada o una ruta de código detallada pueden establecer credibilidad sin requerir una explotación dañina.
Tampoco existe un detector fiable de texto generado por IA. Los investigadores suelen usar modelos para traducción, edición, explicación de código o formato, incluso cuando el trabajo subyacente es legítimo.
Rechazar informes basándose en el estilo castigaría la divulgación cuidadosa y crearía incentivos para ocultar el uso de IA. No establecería si el fallo reportado es real.
La declaración pública de Google deja varias preguntas sin respuesta. La empresa no ha revelado qué medidas de filtrado fallaron, cuántos hallazgos legítimos quedaron atrapados en el aumento de volumen ni qué rediseño está considerando.
Tampoco está claro si la pausa terminará con más automatización, umbrales de evidencia más altos, acceso restringido o un modelo de recompensas diferente.
La falta de cifras limita la evaluación externa. «La gran mayoría» comunica gravedad, pero no revela si la validez cayó ligeramente por debajo de un umbral existente o se desplomó casi por completo.
Los lectores también deben evitar tratar la experiencia de Google como universal. Mozilla afirmó anteriormente que su tasa de rechazo de informes no válidos se había mantenido estable durante un periodo anterior, pese a la preocupación más amplia de la industria.
El diseño del programa, la visibilidad del proyecto, los incentivos de recompensa y las reglas de envío afectan al volumen y la calidad de los informes. Una política que funciona para un proyecto puede fracasar en otro.
Los propios sistemas de IA están cambiando rápidamente. Mejores modelos pueden producir falsos positivos más convincentes, pero también pueden generar pruebas más sólidas y reducir las alucinaciones.
Ese movimiento dual vuelve frágiles las reglas estáticas. Los programas necesitan controles de calidad medibles que evalúen la evidencia en lugar de adivinar qué herramienta la produjo.
Para los responsables de seguridad, la métrica central no debería ser el volumen bruto de informes. Las medidas útiles incluyen la tasa de vulnerabilidades confirmadas, la tasa de duplicados, el tiempo medio de triaje, el tiempo de remediación y la carga de trabajo de los revisores.
Un programa puede recibir más informes mientras se vuelve menos eficaz. A la inversa, una recepción más estricta puede reducir el volumen y aumentar la proporción de hallazgos graves que llegan a los mantenedores.
Por lo tanto, la pausa del OSS VRP de Google debe juzgarse por lo que la reemplace. Cerrar una cola desbordada es comprensible, pero un resultado de seguridad duradero requiere una vía fiable para los informes válidos.
Qué Sigue para la Recompensa por Errores de Código Abierto de Google
Tres señales revelarán si la pausa de Google se convierte en un mejor sistema de divulgación o en una retirada duradera de la participación abierta.
La primera señal es la actualización prometida por Google durante el primer trimestre de 2027. Los detalles más importantes se referirán a elegibilidad, estándares de evidencia, filtrado automatizado y procedimientos de apelación.
Una reapertura con requisitos claros de reproducción reforzaría la idea de que Google usó la pausa para rediseñar la recepción. Una extensión indefinida sugeriría que el envío abierto sigue siendo económicamente difícil.
Observe si Google exige a los reporteros proporcionar pruebas ejecutables, commits afectados, rastros de explotación o correcciones propuestas. Tales reglas trasladarían la responsabilidad hacia los investigadores sin prohibir la asistencia de IA.
La segunda señal es la tasa de informes confirmados después de cualquier reapertura. Google no ha publicado una referencia actual, por lo que la transparencia sobre las futuras tasas de validez y duplicados ayudaría a evaluar el nuevo sistema.
Una mayor tasa de confirmación con acceso estable a la divulgación respaldaría un filtrado más estricto. Una caída brusca de la participación podría indicar que las barreras están excluyendo a investigadores legítimos junto con el spam.
El tiempo de triaje también importa. Si los revisores pueden evaluar informes creíbles más rápido, Google tendrá evidencia de que el rediseño redujo el trabajo oculto en lugar de limitarse a reducir el volumen visible.
La tercera señal es cómo responden otros proyectos y plataformas. Curl eliminó las recompensas, Linux redirigió hallazgos automatizados y Google pausó una categoría de envíos.
Si más programas adoptan reproducciones verificadas, requisitos de parche o umbrales de reputación, esas prácticas podrían convertirse en la norma para la divulgación asistida por IA.
Las plataformas también podrían construir defensas compartidas. La detección de duplicados entre programas, la evidencia estandarizada legible por máquinas y las identidades de agentes responsables podrían reducir el trabajo repetido.
El resultado más constructivo separaría la escala de descubrimiento de la escala de envío. Los investigadores podrían ejecutar agentes ampliamente, pero solo los hallazgos validados y sin duplicados entrarían en las colas de revisión humana.
Ese modelo exige responsabilidad en cada traspaso. Los desarrolladores de herramientas deben diseñar para la verificación, los investigadores deben probar los hallazgos, las plataformas deben filtrar cuidadosamente y los mantenedores necesitan rutas de escalamiento claras.
Los desarrolladores que usan herramientas de seguridad con IA ya deberían comportarse como si esas reglas existieran. Deben reproducir cada afirmación, comprender el código afectado, revisar el historial público de incidencias y documentar un impacto realista.
También deben permanecer disponibles después del envío. Un reportero que no puede responder preguntas técnicas básicas transfiere al proyecto todo el coste de la investigación.
Para las empresas, la lección va más allá de las recompensas por errores. Cualquier sistema público de recepción puede sobrecargarse cuando la IA abarata la generación de contenido y la evaluación sigue siendo costosa.
Las colas de soporte, las solicitudes de empleo, los programas de subvenciones, las pull requests y los informes de cumplimiento enfrentan el mismo desequilibrio básico. El recurso escaso ya no es la redacción. Es la revisión fiable.
La pausa de Google en su recompensa por errores de código abierto hace visible ese desequilibrio en un entorno de alto riesgo. Un informe de seguridad falso desperdicia tiempo, mientras que pasar por alto una vulnerabilidad real puede exponer a millones de usuarios posteriores.
El desafío no consiste en elegir entre la IA y los investigadores humanos. Consiste en diseñar un sistema de divulgación en el que la automatización aumente el trabajo de seguridad verificado en lugar de multiplicar afirmaciones sin sustento.
Google tiene ahora hasta su próxima actualización para mostrar cómo es ese sistema. ¿Reabrirá con barreras de evidencia más sólidas y acceso significativo, o la participación abierta seguirá reduciéndose a medida que crece el volumen de informes?
