Google pausa su bug bounty de código abierto por spam de IA

Por qué Google congela su programa de recompensas por bugs en open source

El 1 de octubre de 2026 Google dejó de aceptar nuevos reportes de vulnerabilidades en su programa OSS VRP (Open Source Software Vulnerability Rewards Program), según confirmó la propia compañía a través de su perfil en X y en la página oficial de Bug Hunters. La medida, temporal hasta nuevo aviso, se atribuye a un aluvión de reportes automatizados con IA, la "vasta mayoría" de los cuales no son válidos, según el comunicado oficial recogido por BleepingComputer.

Para una startup que produce o consume software de código abierto, el movimiento importa más de lo que parece: la garantía de que proyectos como Go, Angular, Bazel, Protocol Buffers o Fuchsia reciban auditorías externas incentivadas se debilita justo cuando la superficie de ataque crece por el uso masivo de modelos generativos.

Qué cambia exactamente y qué sigue abierto

El OSS VRP se lanzó en agosto de 2022 y premiaba con hasta US$31.337 los hallazgos de gravedad alta en proyectos open source de Google y en dependencias de terceros críticas para su cadena de suministro. Ahora, los reportes de producto nuevo quedan en pausa, aunque Google aclara tres excepciones operativas:

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Reportes enviados antes del 1 de octubre de 2026 siguen su curso normal.
Los reportes de cadena de suministro (supply chain) sí se aceptan.
Las vulnerabilidades en repositorios open source que impactan productos de Google Cloud pueden canalizarse por el Cloud VRP.

Adicionalmente, el Patch Rewards Program sigue activo y paga hasta US$15.000 por parches de alto impacto en proyectos open source de la compañía. Google prometió una revisión del programa en el primer trimestre de 2027 con nuevas reglas de filtrado.

El trasfondo: la IA inunda los canales de bug bounty

Google no es la primera víctima del fenómeno. BleepingComputer documenta que en enero de 2026 el mantenedor de curl canceló su programa en HackerOne tras recibir una avalancha de "AI slop". Más recientemente, a mediados de septiembre, Intel retiró las recompensas económicas de su programa en Intigriti sin dar explicaciones públicas. Help Net Security ya había alertado en mayo sobre el mismo patrón en el Internet Bug Bounty.

El problema de fondo es operativo: un reporte de vulnerabilidad suena plausible y aun así puede describir código inalcanzable, un exploit que no funciona o una falla sin impacto real. Las herramientas de IA multiplican el volumen de esos reportes, pero un humano debe investigar cada uno para validarlo. Como recordó CryptoBriefing, los proyectos open source son los más afectados porque muchos los mantienen equipos pequeños o voluntarios sin capacidad de triage adicional.

Google ya había intentado filtrar la avalancha en marzo de 2026, cuando endureció los criterios de evidencia para algunas categorías del OSS VRP y redujo los premios en los niveles de menor prioridad. La pausa de octubre es el paso siguiente y, según BleepingComputer, el más agresivo hasta la fecha.

¿Qué significa esto para tu startup?

Si tu producto depende de proyectos open source de Google, el coste real de mantener una superficie segura acaba de subir: hay menos ojos externos incentivados revisando ese código. La ironía, según TechBooky, es que la misma IA que permite descubrir debilidades más rápido — Google ya experimenta con su agente Big Sleep — también sirve para generar reportes basura a escala. Más reportes no significan software más seguro.

Tres acciones concretas que puedes tomar esta semana:

Audita tus dependencias Go, Angular y Bazel con SBOM (Software Bill of Materials) y revisa si ya tenés canal directo con los mantenedores upstream para reportar fallos críticos sin pasar por el programa público.
Asigna un presupuesto interno de triage de vulnerabilidades: un analista a tiempo parcial que filtre reportes automatizados antes de que lleguen a tu equipo de desarrollo. El coste de ese filtro es una fracción de lo que cuesta un parche de emergencia mal priorizado.
Diversifica tu canal de disclosure: intégrate en plataformas como HackerOne o Intigriti con programa propio, aunque sea pequeño, para mantener un flujo controlado de investigadores externos. Con los programas públicos saturándose, el "bug bounty privado" recupera atractivo.

Una tendencia que llegó para quedarse

El caso del kernel de Linux ya marcó el tono: Linus Torvalds tuvo que pedir a los contribuidores que dejaran de enviar parches generados íntegramente por IA, y en 2026 el propio Torvalds terminó usando IA para arreglar un bug, una decisión que reabrió el debate en la comunidad, según XDA Developers. La lección es incómoda: detectar si un código lo escribió un LLM es mucho más difícil que detectar un texto generado, por lo que cualquier prohibición absoluta es casi imposible de hacer cumplir a escala.

En ese escenario, el movimiento de Google es un termómetro del sector: si la mayor empresa de internet del mundo no puede sostener un programa abierto sin que lo inunden reportes de IA inválidos, pocas organizaciones medianas podrán. Para los founders, la conclusión es clara: la seguridad open source ya no se garantiza con recompensas públicas; hay que construirla internamente o pagarla como servicio.