Tiempo de lectura: 3 minutos

La compañía deja de aceptar nuevos informes sobre vulnerabilidades de producto en su programa OSS VRP. La medida no afecta a los reportes de cadena de suministro ni a los enviados antes del 1 de octubre, y todavía no hay una fecha confirmada de reapertura.

Google ha suspendido temporalmente una parte de su Open Source Software Vulnerability Reward Program OSS VRP, el programa que recompensa a investigadores por comunicar fallos de seguridad en su software de código abierto. Desde el 1 de octubre de 2026, no acepta nuevos reportes sobre vulnerabilidades de producto a través de esta vía. El cambio ya figura en las reglas oficiales.

La explicación de Google apunta a un aumento significativo de los envíos automatizados, cuya gran mayoría, según la compañía, no son válidos. El anuncio no aporta cifras sobre el volumen recibido ni el porcentaje exacto de rechazos, y tampoco identifica qué herramientas han generado esos informes.

Las claves del suspenso y qué sigue funcionando

La pausa afecta a los fallos de diseño o implementación presentes en el propio software. No supone el cierre completo del OSS VRP: siguen admitiéndose los reportes de cadena de suministro, como los que permiten demostrar que un atacante podría manipular el código fuente o los paquetes distribuidos por un proyecto. Las reglas mantienen esa categoría separada de las vulnerabilidades de producto.

Tampoco quedan afectados los informes enviados antes del 1 de octubre. Para ciertos repositorios vinculados a productos de Google Cloud, la compañía señala que puede seguir aceptando vulnerabilidades mediante el Cloud VRP. Por tanto, no se trata de una suspensión general de todos los programas de recompensas de Google, sino de una restricción sobre una categoría concreta.

La IA ya había provocado un endurecimiento de las reglas

Aunque el anuncio de octubre habla de envíos automatizados sin atribuirlos expresamente a una tecnología, el problema tiene antecedentes relacionados con la IA. En marzo, Google ya había reforzado los requisitos de prueba para determinadas categorías del OSS VRP, en un contexto de preocupación por informes generados con IA que incluían detalles inventados sobre cómo explotar supuestas vulnerabilidades.

El proyecto Go describe esta dificultad en su propia política de seguridad. Sus responsables reconocen que los modelos de lenguaje pueden encontrar fallos importantes, pero también señalar problemas inexistentes o errores que no representan una vulnerabilidad. Por eso piden que los investigadores revisen y filtren los resultados antes de enviarlos, en lugar de trasladar directamente la salida del modelo al equipo de seguridad.

La diferencia es fundamental: generar una hipótesis no equivale a demostrar un fallo. Un informe puede parecer convincente y, aun así, no aportar una forma válida de reproducir el problema. Go advierte de que recibir decenas de posibles incidencias para encontrar una realmente relevante traslada el trabajo de selección a los mantenedores y dificulta su labor de proteger el proyecto.

Recompensar correcciones, no solo informes

Entre las alternativas que Google mantiene está el Patch Rewards Program, orientado a mejoras de seguridad implementadas en proyectos de código abierto incluidos en su alcance. A diferencia de un programa centrado en comunicar vulnerabilidades, aquí se recompensa la aportación de cambios que refuercen el software, como mejoras de aislamiento, separación de privilegios o correcciones sistemáticas de determinadas clases de errores.

Los investigadores que recurran a otros programas también deben comprobar sus condiciones. Por ejemplo, el Cloud VRP exige explicar el impacto, proporcionar instrucciones de reproducción y presentar una prueba de concepto, además, distingue entre vulnerabilidades del producto y configuraciones inseguras del cliente. Cambiar de canal no elimina la necesidad de aportar evidencia técnica.

Novedades en 2027, pero sin fecha de regreso

Google se ha comprometido a publicar una actualización sobre esta parte del OSS VRP durante el primer trimestre de 2027, mientras revisa su funcionamiento. Eso no equivale a anunciar que volverá a aceptar estos reportes en enero ni garantiza que regrese con las mismas condiciones.

La pausa plantea un problema que va más allá de Google: si automatizar la elaboración de informes reduce el esfuerzo de enviarlos, pero no el de comprobarlos, la carga termina desplazándose hacia quienes mantienen el software. El valor de una investigación no está en cuántas alertas produce, sino en cuánto ayuda a resolver un problema real. Una descripción convincente puede iniciar una investigación; no puede sustituir sus pruebas.