Google pausa informes de producto en OSS VRP

Google dejó de aceptar nuevos informes de vulnerabilidades de producto en su Open Source Software Vulnerability Reward Program (OSS VRP) desde el 1 de octubre de 2026, según el cambio en las reglas del programa. La empresa se comprometió en ese mismo aviso a actualizar esta parte del programa en el primer trimestre de 2027. Para los investigadores, la pausa cierra una categoría de recepción, pero deja otras rutas sujetas al tipo de riesgo descubierto.

Google atribuyó la decisión al aumento de envíos automatizados, «the vast majority of which are not valid», una explicación recogida por SecurityWeek. La cobertura también señala que los informes de cadena de suministro y los casos pendientes siguen fuera de la pausa. Google no precisó si los envíos que motivaron esta decisión se habían generado con IA; su explicación identifica la automatización y la falta de validez de la mayoría de esos informes.

La categoría que dejó de aceptar informes

La entrada suspendida corresponde a nuevos hallazgos de vulnerabilidades de producto en el código abierto de Google. Esta categoría abarca fallos de diseño o implementación del software cuyo impacto de seguridad recae en el producto construido con ese código. Un error en una función y una vía para alterar los componentes con los que se publica el proyecto pueden pertenecer a categorías distintas, aunque ambos afecten al mismo repositorio.

La pausa tampoco borra el trabajo ya presentado. Los informes de vulnerabilidades de producto enviados antes de su entrada en vigor no quedan afectados, y los expedientes pendientes conservan su condición previa. La distinción temporal importa tanto como la técnica: un investigador que ya comunicó un hallazgo está en una situación diferente de quien intenta enviar hoy un informe nuevo sobre el mismo tipo de fallo.

Los riesgos de cadena de suministro mantienen su vía dentro de OSS VRP. Se trata, por ejemplo, de condiciones que podrían permitir alterar el código fuente, el proceso de construcción o los paquetes publicados de un proyecto. El punto decisivo es el efecto demostrado sobre la integridad de esa cadena, no que el problema aparezca en un repositorio de código abierto. Por eso, cambiar la etiqueta de un fallo de producto no lo convierte en un aviso de cadena de suministro.

Qué rutas siguen disponibles para los investigadores

El recorrido para un hallazgo nuevo empieza por su impacto. Si compromete la fuente, la construcción o la distribución de un proyecto comprendido por OSS VRP, la categoría de cadena de suministro continúa disponible. Si es una vulnerabilidad del producto de código abierto, la entrada específica de OSS VRP está pausada. Son rutas definidas por el riesgo que se comunica, no formularios alternativos para presentar el mismo informe.

Existe una posibilidad más estrecha para Google Cloud: algunos repositorios de Google Cloud cuyos fallos afecten a productos de Google Cloud podrían admitir informes de vulnerabilidades de producto mediante Cloud VRP. La formulación de Google es condicional. Que un repositorio sea público, o que su código pueda utilizarse en la nube, no basta por sí solo para situar cualquier fallo dentro de esa excepción; importa el efecto sobre un producto cubierto por el programa.

Google también dirige a los investigadores hacia sus otros programas de recompensas cuando el impacto encaje en sus reglas. Esa indicación exige identificar el producto afectado y el alcance admitido por el programa correspondiente. Un hallazgo en un proyecto de código abierto no pasa automáticamente a otra vía de recompensas por haber perdido la entrada de vulnerabilidades de producto en OSS VRP.

Patch Rewards ofrece una ruta de naturaleza diferente: recompensa contribuciones que mejoran la seguridad de proyectos de código abierto cubiertos por sus reglas. Su objeto es el parche, no el traslado sin cambios de un aviso presentado a la categoría pausada. Para quien puede aportar una corrección, esa diferencia cambia la clase de trabajo que se evalúa. Para quien solo dispone de un informe de vulnerabilidad, Patch Rewards no sustituye de forma directa la recepción suspendida.

Cómo llegó la revisión al límite

El coste de un informe automatizado recae sobre quienes deben comprobarlo. Producir una descripción convincente de un posible fallo puede ser rápido; establecer si la ruta vulnerable es alcanzable, si el comportamiento se reproduce y si el impacto encaja en el modelo de seguridad del proyecto requiere revisión técnica. Un volumen mayor de propuestas inválidas ocupa así capacidad que también necesitan los hallazgos útiles y las correcciones.

El problema venía tomando forma antes de la pausa. En una actualización anterior de Google Bug Hunters, el equipo describió un fuerte aumento de informes generados con IA y distinguió dos fallos frecuentes: explicaciones inventadas sobre cómo activar una vulnerabilidad y errores reales de código sin impacto de seguridad apreciable porque la ruta no era alcanzable o el modelo de seguridad del proyecto no quedaba comprometido. También endureció los requisitos de prueba para determinadas clases de informes.

Esos ejemplos explican por qué el volumen puede saturar la revisión sin que todo uso de IA produzca un informe inválido. Una herramienta puede ayudar a encontrar un indicio; el informe sigue necesitando una reproducción y una explicación verificable del impacto. El anuncio de la pausa no ofrece una cifra de envíos ni una tasa precisa de rechazo. La próxima actualización comprometida por Google deberá aclarar cómo reorganizará esta parte de OSS VRP; por ahora, no hay una fecha anunciada para reabrir la recepción de nuevos informes de vulnerabilidades de producto.