Google cierra el programa de recompensas de vulnerabilidades para su software open source

octubre 8, 2026 Alfonso Moreno | Sysadmin Senior 40 Visitas 9 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Qué pasó

El 1 de octubre de 2026 Google dejó de aceptar reportes de vulnerabilidades de producto enviados a través de su Open Source Software Vulnerability Reward Program (OSS VRP). El cambio afecta a investigadores que encontraban fallos en proyectos como Go, Angular, Protocol Buffers, Bazel y Fuchsia. La razón oficial: una ola de reportes automatizados, la inmensa mayoría inválidos, que colapsó a los equipos de revisión.

El aviso lo publicó la cuenta oficial @googlevrp en X el 1 de octubre, y la página oficial de reglas del programa se actualizó para reflejar la pausa. La promesa de Google: actualización en el primer trimestre de 2027.

Qué cubre el programa (y qué se pausa exactamente)

El OSS VRP, lanzado en agosto de 2022, recompensaba con montos desde 100 USD hasta 31.337 USD a quien reportara de forma privada fallas de seguridad en el código abierto que Google mantiene. La cobertura se organizaba en cuatro niveles de proyecto, del OT0 (Flagship) al OT3 (Low-priority), y se extendía también a configuraciones de repositorio, dependencias de terceros y la cadena de suministro.

Componente	Estado desde 1-oct-2026
Reportes de producto en proyectos Google OSS (Go, Angular, Protocol Buffers, Bazel, Fuchsia)	Pausados
Reportes de producto enviados antes del 1 de octubre de 2026	Se procesan normalmente
Compromisos de cadena de suministro (supply chain)	Abiertos
Vulnerabilidades de producto en repos de Google Cloud que impactan productos Cloud	Derivados al Cloud VRP
Vulnerabilidades en proyectos OSS ligados a productos de IA	Derivados al AI VRP
Mejoras de seguridad en proyectos OSS	Patch Rewards Program (hasta 15.000 USD)

La distinción clave es entre product vulnerabilities (fallos en el código del producto) y supply chain compromises (algo que permita modificar el código o los artefactos de build). Solo los primeros se pausan. Si tu hallazgo toca el flujo de build, la configuración de GitHub Actions, o las credenciales de publicación, sigue entrando.

Por qué importa hoy

Go, Angular y Protocol Buffers son infraestructura base. Go corre en servicios backend de medio internet y se compila dentro de herramientas como Docker, Kubernetes, Terraform y Prometheus. Protocol Buffers es el formato de serialización por defecto de gRPC, usado por muchísimos microservicios. Angular sigue siendo uno de los frameworks frontend más desplegados. Bugs reales en estos proyectos no son problemas teóricos: tienen superficie de ataque medible.

El incentivo económico para encontrarlos era real. El OSS VRP ya pagó premios grandes antes — los 31.337 USD son la banda más alta, reservados para hallazgos con impacto severo en la cadena de suministro. Con el programa pausado, ese incentivo se va temporalmente a otros frentes.

Para quienes mantienen proyectos que dependen de Google OSS, el mensaje práctico es: no asumas que un bounty externo está cubriendo tu riesgo. El modelo “alguien lo va a reportar y a mí me llega el parche” tiene ahora un hoyo.

Cómo verificar si tu stack está afectado

Si tu servidor o pipeline usa Go, Angular o Protocol Buffers, conviene revisar manualmente tres cosas mientras el bounty está pausado:

# 1. Versión de Go instalada
go version
# 2. Listar binarios compilados con Go en el sistema
find /usr/local/bin /opt -type f -executable 2>/dev/null | while read f; do
  if head -c 4 "$f" | grep -q "Go"; then echo "$f"; fi
done | head -20
# 3. Buscar dependencias protobuf
grep -rl "import google/protobuf" --include="*.go" --include="*.py" --include="*.cc" . 2>/dev/null | head -10

Si la versión de Go es anterior a la 1.23, o si tus binarios no se reconstruyen con regularidad, los CVEs de los últimos meses quizá no llegaron a tu sistema. El mismo principio aplica a Angular: verifica el package.json y la fecha de la última auditoría.

Qué hacer como investigador de seguridad

Si encontraste un fallo de producto en un proyecto cubierto por el OSS VRP, el programa pide que lo reportes a través de otros canales. Las opciones que quedan abiertas son:

# 1. Reportar via HackerOne (Google Bug Hunters)
# https://bughunters.google.com/ — seleccionar el programa correcto (Cloud VRP, AI VRP, etc.)
# 2. Mantenedor upstream primero, especialmente para dependencias de terceros
# Regla del programa: "send your bug reports directly to the owner of the vulnerable package first"
# 3. Si es mejora de seguridad, Patch Rewards Program
# https://bughunters.google.com/about/rules/open-source/patch-rewards-program-rules

Para dependencias de terceros, Google mantiene la regla histórica: reportar primero al mantenedor upstream, esperar el parche, y solo entonces notificar a Google — y solo si demuestras que la vulnerabilidad se manifiesta en su proyecto.

Por qué pasó: el problema del AI slop

El patrón de fondo es económico. Un reporte de vulnerabilidad bien hecho lleva horas: reproducir el fallo, reducir el caso, escribir un proof-of-concept, redactar el impacto. Una herramienta con capacidad de razonamiento puede escupir un reporte plausible en segundos. La firma coincide, la terminología es la correcta, el reporte parece legítimo. La realidad: falla al intentar reproducirlo, describe una versión inexistente de la API, o reporta un comportamiento que no es explotable.

Para el revisor, cada reporte exige el mismo trabajo de verificación que uno bueno. Si llegan diez mil reportes automatizados y solo cien son válidos, los mil revisores humanos están quemando el 99% de su tiempo descartando ruido. Esa es exactamente la situación que llevó al cierre temporal.

El OSS VRP no es el primer programa en caer. El proyecto curl terminó su bug bounty en enero de 2026 por el mismo motivo, y Nextcloud también pausó el suyo. La lectura de los operadores de bug bounty coincide: la presión del volumen automatizado no se sostiene sin filtros previos mucho más estrictos.

El cambio de incentivo: Patch Rewards

Mientras el reporte de producto está pausado, Google sigue pagando por el otro extremo: el parche. El Patch Rewards Program ofrece hasta 15.000 USD por mejoras de seguridad enviadas a proyectos OSS de Google. La diferencia operativa es importante:

Programa	Qué recompensa	Estado actual
OSS VRP (product vulnerabilities)	Reporte privado de fallo	Pausado desde 1-oct-2026
OSS VRP (supply chain)	Reporte de compromiso de cadena de suministro	Abierto
Patch Rewards Program	Enviar el parche, no el reporte	Abierto, hasta 15.000 USD
Cloud VRP	Vulnerabilidades en productos Cloud	Abierto
AI VRP	Vulnerabilidades en productos de IA de Google	Abierto

El cambio de modelo es relevante: la carga de reproducir, reducir y proponer fix pasa del equipo de seguridad interno al investigador que envía el parche. Es un experimento que vale la pena seguir de cerca. Si el modelo funciona, podríamos verlo en más proyectos grandes.

Qué esperar hasta Q1 2027

Google se comprometió a dar una actualización en el primer trimestre de 2027. Las opciones realistas son tres:

Reapertura con filtros más estrictos — por ejemplo, exigir PoC funcional y alcance demostrado antes de aceptar el reporte, o un proceso de pre-validación con LLM interno.
Fusión con Patch Rewards — eliminar el reporte de producto como vía separada y consolidarlo todo en el programa de parches.
Cierre definitivo del componente de producto — reservar el OSS VRP únicamente a cadena de suministro, y derivar el resto a programas verticales (Cloud, AI).

El precedente del proyecto curl, que cerró su bounty y luego lo reabrió con condiciones más estrictas, sugiere que el escenario más probable es el primero. Pero la decisión final dependerá de cuánto haya costado la pausa en cobertura efectiva.

Lo que puedes hacer esta semana

Si mantienes infraestructura que corre Go, Angular, Protocol Buffers, Bazel o Fuchsia, este es un buen momento para:

Revisar el CHANGELOG reciente de cada proyecto y auditar qué CVEs están abiertos en tu versión.
Suscribirte a las listas de seguridad upstream directamente, en lugar de depender de un bounty como tu única fuente de aviso.
Si usas Go en producción, considera activar GOFLAGS=-mod=readonly y un pipeline de govulncheck en CI para que cada build nuevo revise contra la base de datos de vulnerabilidades conocida.
Documentar internamente quién es el responsable de monitorear avisos de seguridad upstream. Sin un bounty que centralice el reporte, la responsabilidad de enterarse se reparte.

La pausa del OSS VRP no significa que los proyectos sean menos seguros. Significa que el mecanismo externo que cubría cierta superficie ya no está disponible temporalmente, y el resto del ecosistema tiene que compensar.

Resumen

Google pausó la aceptación de reportes de vulnerabilidades de producto en su OSS VRP el 1 de octubre de 2026, citando una avalancha de reportes automatizados inválidos. La pausa afecta a proyectos como Go, Angular, Protocol Buffers, Bazel y Fuchsia. Los reportes de cadena de suministro, el Patch Rewards Program, el Cloud VRP y el AI VRP siguen abiertos. Google prometió actualización en el primer trimestre de 2027. Mientras tanto, los mantenedores de proyectos OSS que dependían de este programa como red de seguridad tienen que reforzar su monitoreo interno.

Fuentes y documentación oficial

Google Open Source Software Vulnerability Reward Program Rules — reglas oficiales con la fecha de pausa y alcance.
Publicación oficial de @googlevrp en X (1-oct-2026) — el anuncio original.
Google Patch Rewards Program Rules — alternativa abierta con pago por parches.
Help Net Security — AI slop submissions force Google to freeze its open-source bug bounty
The Hacker News — Google Pauses OSS Product Bug Bounty Rewards

Preguntas frecuentes

¿Por qué Google cierra el programa de recompensas de vulnerabilidades para su software open source es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Google cierra el programa de?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Google cierra el programa de?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Google cierra el programa de y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Google cierra el programa de?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.