Google dejó de aceptar nuevos informes de vulnerabilidades de producto en su Open Source Software Vulnerability Reward Program el 1 de octubre de 2026. Atribuyó la decisión al fuerte aumento de envíos automáticos, en su gran mayoría inválidos. Espera ofrecer otra actualización en el primer trimestre de 2027.
Es una pausa en una categoría, no el cierre de todo su sistema de recompensas ni una prohibición de investigar con IA. Expone un fallo más concreto: generar una afirmación de seguridad plausible resulta barato, pero demostrar su realidad sigue requiriendo especialistas escasos.
Qué cerró y qué permanece disponible
Google creó OSS VRP en 2022 para problemas de seguridad de código abierto elegibles. Los informes de producto describen defectos de código, lógica o diseño. La pausa afecta a nuevos envíos de esa categoría; los recibidos antes del límite siguen siendo elegibles.
Los informes de cadena de suministro continúan abiertos. Algunos problemas de repositorios de Google Cloud pueden entrar en Cloud VRP según el producto y las reglas. También continúan otros programas, incluidos Chrome, Android, dispositivos y seguridad de IA. Los investigadores deben comprobar el alcance real en lugar de suponer la misma alternativa para todo repositorio.
La suspensión siguió a cambios anteriores. Las reglas de 2026 exigían validar hallazgos asistidos por IA y demostrar consecuencias reales. En abril, Google retiró dinero y reconocimiento público para ciertas vulnerabilidades de producto de nivel inferior y otros problemas. Esos ajustes más estrechos no evitaron la pausa posterior.
Google no publicó cifras precisas de envíos, aceptación o cola pendiente del canal afectado. La cobertura secundaria mencionó miles de informes débiles, pero ese número no figura en el aviso de la compañía. “Mayoría inválida” indica un problema serio sin aportar una base estadística completa.
El sustituto sigue sin definirse públicamente. Reproducciones probadas, límites, identidad y selección automática son posibilidades, no condiciones anunciadas de reapertura.
Un informe convincente puede no describir ninguna vulnerabilidad
Un modelo puede señalar una operación sospechosa, redactar un ataque y añadir una evaluación profesional de gravedad. Pero la operación quizá nunca reciba datos del atacante, sea inalcanzable o esté protegida. Incluso un error real de programación puede carecer de consecuencia de seguridad bajo el modelo de amenazas del proyecto.
Los revisores reconstruyen esas condiciones. Inspeccionan versiones, reproducen comportamientos, examinan mitigaciones y buscan duplicados. Una función o condición inventada puede esconderse en un relato coherente. La presentación ya no sustituye a la evidencia.
Christopher Robinson, de Open Source Security Foundation, estimó en marzo que proyectos acostumbrados a dos o tres informes semanales podían recibir después cientos de golpe. Una investigación individual podía consumir entre dos y ocho horas imprevistas del mantenedor. Son observaciones atribuidas de varios proyectos, no mediciones de la cola de Google.
El incentivo económico puede agravar la asimetría. Un autor genera muchas hipótesis mientras el destinatario paga la mayor parte de verificarlas. Duplicados, gravedad exagerada y comportamientos documentados mal entendidos compiten con descubrimientos reales. Incluso el volumen bien intencionado puede desplazar reparaciones.
La distinción no es si un modelo ayudó a escribir. Traducción, explicación y generación de pruebas pueden mejorar investigación legítima. Una persona debe entender el camino alcanzable, reproducir el resultado y responder preguntas. Reescribir con estilo humano una hipótesis sin probar no la valida.
La investigación validada impide rechazar toda la IA
Google sigue desarrollando defensas asistidas, como OSS-Fuzz, Big Sleep y CodeMender. Sus equipos pueden definir objetivos, recoger evidencia de ejecución y revisar parches. Un programa externo recibe materiales de múltiples herramientas y entornos sin la misma cadena controlada.
Las recompensas generales siguen siendo importantes. Según su balance, Google pagó más de 17 millones de dólares a más de 700 investigadores en 2025, más de un 40% por encima de 2024. Son totales de programas más amplios, no presupuesto ni productividad de la categoría OSS suspendida.
Las noticias describen otro contraste. Anthropic afirmó que Claude Opus 4.6 halló más de 500 vulnerabilidades desconocidas de código abierto, todas validadas por personas o especialistas externos antes de divulgarse. Mozilla recibió 112 informes en dos semanas y publicó 22 avisos, 14 de gravedad alta. Muchos hallazgos restantes se clasificaron como errores sin impacto de seguridad.
Hay que distinguir unidades: informes, avisos y vulnerabilidades validadas no son recuentos intercambiables. El ejemplo respalda descubrimiento automatizado con validación experta, no una garantía para cualquier informe de modelo.
La clasificación automática puede agrupar duplicados o pedir pruebas ausentes, pero también se equivoca. Que dos modelos coincidan es menos sólido que una prueba reproducible independientemente. Los casos inusuales y desacuerdos siguen necesitando escalado humano.
Curl, Linux y HackerOne cambiaron relevos distintos
Curl terminó los premios monetarios el 31 de enero de 2026 tras un programa iniciado en 2019. Daniel Stenberg informó de 87 vulnerabilidades confirmadas durante su duración. Sin embargo, la proporción confirmada cayó de más del 15% anteriormente a menos del 5% en 2025.
Su explicación combinaba ruido de IA, peor calidad de otros informes y atención excesiva al premio. El fin de los pagos no acabó con la divulgación responsable: GitHub privado y correo seguían disponibles. La medida actuaba sobre incentivos, aceptando que también podía desmotivar a buenos investigadores independientes.
Linux recibió descubrimientos repetidos de personas con herramientas similares. La gestión privada ocultaba discusiones o soluciones existentes a otros autores, obligando a revisar el mismo problema. Torvalds defendió canales públicos para muchos hallazgos fáciles de redescubrir, salvo necesidad real de secreto.
Eso no pide publicar cualquier exploit sin parchear. Las reglas del kernel destacan descripciones concisas, versiones afectadas, condiciones, reproducciones comprobadas e impacto realista. Los autores deben entender el código, contactar a los mantenedores correctos y aportar un parche cuando sea posible.
HackerOne indicó un aumento superior al 100% del volumen sectorial tras herramientas de IA más capaces aparecidas en febrero de 2026. Su análisis incluye descubrimientos útiles, duplicados y afirmaciones no verificables. Exige prueba reproducible, gravedad correcta y considerar las defensas; grandes lotes sin validar pueden provocar medidas de cumplimiento. Es una observación de plataforma, no la tasa de invalidez de Google.
Las intervenciones difieren: Google pausó una categoría, curl quitó dinero y Linux cambió expectativas y rutas. Comparten un límite de atención experta, especialmente cuando dependencias comerciales las mantienen voluntarios.
Reabrir requiere pruebas y una vía para recién llegados
Las barreras fuertes protegen revisores pero pueden ocultar fallos reales. La reputación favorece a los establecidos; depósitos e invitaciones opacas excluyen a nuevos participantes. Exigir un exploit completo puede incentivar pruebas peligrosas cuando bastaría una reproducción mínima controlada.
Un buen paquete identifica commit, entorno, influencia del atacante, entrada y frontera cruzada. Documenta qué se probó, distingue inferencia de observación y protege detalles confidenciales. No debería exigir daño ni enviar código sensible a un servicio de modelos no autorizado.
Los filtros deben rechazar pruebas insuficientes, no considerar el estilo de IA como evidencia de invalidez. No existe una prueba fiable de escritura para decidir si una vulnerabilidad es real. Apelación y especialistas importan porque cadenas poco comunes no siempre encajan en plantillas.
La próxima actualización mostrará si Google reabre con requisitos claros o menos participantes. Los resultados útiles incluyen confirmaciones, duplicados, tiempos de revisión y reparación, carga y rechazos erróneos, no solo menos envíos. Las experiencias varían: Mozilla había informado antes de una tasa estable de rechazo de materiales inválidos. Google no define todo el ecosistema.
La división constructiva separa escala de descubrimiento y escala de envío. Los agentes pueden explorar ampliamente; los humanos deberían recibir hallazgos validados, sin duplicados y con autores responsables. La pausa no demuestra que la IA no encuentre errores. Muestra que las hipótesis ilimitadas solo se convierten en valor de seguridad cuando alguien las demuestra.
Fuentes
Reglas Google OSS · Carga de los mantenedores · Investigación de informes falsos · Resultados validados de Mozilla · Decisión de curl · Base de ingeniería · Información sobre la pausa · Cambios previos de Google · Recompensas Google 2025 · Análisis de volumen HackerOne · Reglas de seguridad Linux · TechCrunch sobre la pausa de Google · Techmeme sobre la pausa de Google