Google ha suspendido temporalmente las recompensas por reportar vulnerabilidades de producto en su software de código abierto debido a un aumento de envíos automatizados inválidos. El cambio afecta a proyectos como Go y Angular, aunque se siguen aceptando reportes sobre compromisos de la cadena de suministro. La empresa planea actualizar el programa a principios de 2027.

Google ha dejado de aceptar informes de vulnerabilidades de productos a través de su programa de recompensas por errores (bug bounty) para su software de código abierto.

El cambio, en vigor desde el 1 de octubre, significa que ya no puedes enviar fallos de seguridad en el código de proyectos como Go, Angular y Protocol Buffers para recibir una recompensa. Se siguen aceptando los informes sobre compromisos de la cadena de suministro, y los informes presentados antes del 1 de octubre no se ven afectados.

Google calificó la interrupción como temporal en una publicación en X el 1 de octubre y afirmó que se debía a "un aumento significativo de envíos automatizados, la gran mayoría de los cuales no son válidos".

La publicación no proporcionó cifras ni indicó si los envíos fueron generados con herramientas de IA.

Las reglas del programa, llamado Open Source Software Vulnerability Reward Program (OSS VRP), muestran ahora el aviso de la detención. Google se compromete a realizar una actualización en el primer trimestre de 2027 mientras rediseña esta parte del programa.

Ni la publicación ni el aviso dan una fecha para volver a aceptar informes de vulnerabilidades de productos.

Según las reglas, una vulnerabilidad de producto es un fallo de diseño o implementación en el software de código abierto de Google. Debe afectar sustancialmente la confidencialidad o integridad de los datos del usuario en el software construido con ese código. Los ejemplos incluyen la corrupción de memoria en los analizadores de formato de archivos y el salto de directorio (path traversal).

El programa clasifica los proyectos en cuatro niveles según su sensibilidad. Solo los dos superiores, llamados "insignia" (flagship) e "importante", tenían recompensas listadas para vulnerabilidades de productos.

El mismo cambio que añadió el aviso eliminó esos importes listados : de 500 $ a 7.500 $ para proyectos insignia y de 101 $ a 3.133,7 $ para los importantes. Esto se publicó en la copia pública de GitHub de las reglas de Google el 30 de septiembre, un día antes de la publicación en X.

La lista de repositorios por niveles de Google, actualizada por última vez a mediados de septiembre, nombra 26 repositorios insignia y 47 importantes. El nivel insignia incluye Go, Angular, Flutter, Bazel y Protocol Buffers.

Los compromisos de la cadena de suministro, que son fallos que podrían permitir a alguien manipular el código fuente de un proyecto o los paquetes publicados, mantienen sus recompensas. También ocurre lo mismo con otros problemas de seguridad, como las credenciales filtradas que dan acceso de escritura.

Categoría | Insignia | Importante | Estándar
Compromisos de cadena de suministro | 3.133,7 $ a 31.337 $ | 1.337 $ a 13.337 $ | 500 $ a 3.133,7 $
Vulnerabilidades de productos | Ninguna (era de 500 $ a 7.500 $) | Ninguna (era de 101 $ a 3.133,7 $) | Ninguna
Otros problemas de seguridad | 1.000 $ | 500 $ | Ninguna

El cuarto nivel, para proyectos de baja prioridad, no tiene recompensas listadas.

Dónde pueden ir los informes ahora

El aviso de Google nombra tres rutas para los investigadores:

* Cloud VRP: Aún se pueden aceptar informes de vulnerabilidades de productos para algunos repositorios de Google Cloud que afecten a sus productos, aunque el aviso no los especifica. Según las reglas de Cloud VRP, un fallo en un repositorio de código abierto mantenido por Google Cloud que afecte a productos de Cloud se califica como máximo IT3b.
* Recompensas por parches: El Patch Rewards Program paga entre 100 $ y 15.000 $ por parches de seguridad para los proyectos que cubre, no por informes de vulnerabilidades. Los mantenedores del proyecto deben aceptar el parche y este debe permanecer activo durante un mes antes de poder enviarlo.
* Otros programas de recompensas: Google te pide que compruebes si un fallo afecta a algo cubierto por uno de sus otros programas de recompensas y que lo envíes allí. Las reglas del OSS VRP también fomentan informar de fallos en proyectos estrechamente vinculados a Google Cloud o productos de IA al Cloud VRP o al AI VRP.

El aviso no dice si Google seguirá aceptando informes de vulnerabilidades de productos sin recompensa.

Algunas políticas de proyectos apuntan a otros canales. Go acepta informes de seguridad por correo electrónico a su propio equipo de seguridad. Una política de seguridad en la organización de GitHub de Google dirige a los informantes a la dirección de notificación de vulnerabilidades de Google, g.co/vulnz.

La política de seguridad de Angular , a fecha de 6 de octubre, dice que Angular es parte del OSS VRP, envía los informes de vulnerabilidades al sitio de Bug Hunters de Google y no menciona ningún otro canal.

Límites anteriores sobre informes de baja calidad

Google lanzó el OSS VRP en agosto de 2022. En marzo de 2026, comenzó a exigir pruebas más sólidas para los informes en algunos niveles con el fin de filtrar los de baja calidad. Un parche ya fusionado en el proyecto es una forma de prueba aceptada.

InfoWorld informó en aquel momento que el equipo del programa estaba preocupado por la baja calidad de algunos envíos generados por IA, muchos de los cuales incluían detalles inventados sobre cómo se podría activar una vulnerabilidad.

Por separado, el proyecto Go añadió a principios de septiembre una sección sobre informes generados por modelos de lenguaje extensos (LLM) en su política de seguridad. Te pide que no envíes tales informes sin revisarlos y filtrarlos primero.

La política afirma que los LLM son buenos encontrando errores de seguridad reales y igual de buenos informando de otros que no existen. Los informantes que reenvíen grandes cantidades de resultados de LLM sin filtrar no recibirán crédito por sus hallazgos.

Fuente:
THN