La suspensión del OSS VRP de Google muestra que los reportes de errores de IA tienen un problema de verificación
Google suspendió una categoría de su programa de vulnerabilidades de código abierto el 1 de octubre después de que, según se informó, los reportes inválidos generados con IA saturaran su proceso de revisión.
La suspensión del OSS VRP de Google detiene las nuevas presentaciones de “Vulnerabilidades de producto” mientras la empresa rediseña esa parte del programa. Google prevé proporcionar una actualización durante el primer trimestre de 2027.
La decisión no cierra todos los programas de vulnerabilidades de Google. Tampoco prohíbe a los investigadores utilizar inteligencia artificial para analizar código.
En cambio, expone un conflicto creciente entre el descubrimiento automatizado y la verificación humana. La IA puede generar posibles hallazgos mucho más rápido de lo que los mantenedores pueden reproducirlos, evaluarlos y corregirlos.
La medida de Google se produce tras meses de presión creciente en el ámbito de la seguridad de código abierto. Los mantenedores de Linux y otros proyectos se han enfrentado a oleadas similares de reportes duplicados, especulativos o mal probados.
Ese patrón más amplio importa más que un único formulario de envío pausado. Los programas de seguridad tradicionalmente recompensan a los investigadores por encontrar problemas que los equipos internos no detectaron. La IA cambia ese modelo al abaratar de forma extraordinaria la generación de candidatos.
El recurso escaso ya no es la sospecha inicial. Es la atención experta necesaria para demostrar que una falla es alcanzable, explotable y relevante para un modelo de amenazas real.
Qué cambia realmente con la suspensión del OSS VRP de Google
Google ha pausado una categoría de reportes; no ha abandonado la investigación de vulnerabilidades de código abierto ni cerrado toda su operación de recompensas.
El Programa de Recompensas por Vulnerabilidades de Software de Código Abierto, conocido como OSS VRP, cubre problemas de seguridad que cumplan los requisitos en repositorios de código abierto propiedad de Google. Google presentó el programa en 2022.
Los reportes de vulnerabilidades de producto identifican defectos en el código, la lógica o el diseño de un proyecto. Un reporte válido debe hacer más que señalar código sospechoso.
Por lo general, los investigadores deben mostrar una versión afectada, una ruta de ejecución alcanzable, pasos de reproducción y una consecuencia de seguridad significativa. Estos requisitos distinguen las vulnerabilidades explotables de los errores de programación ordinarios.
Según los detalles de la suspensión, la pausa entró en vigor cuando Google la anunció el 1 de octubre. Los reportes de vulnerabilidades de producto enviados antes de esa fecha siguen siendo elegibles para revisión.
Los reportes de cadena de suministro también permanecen abiertos. Estos reportes se refieren a compromisos que afectan la forma en que las dependencias de software, el código fuente, las compilaciones o las versiones llegan a los usuarios.
Algunas vulnerabilidades que afectan productos de Google Cloud aún pueden calificar a través del Cloud VRP independiente. La elegibilidad depende del repositorio y de su conexión con un producto de nube cubierto.
Los investigadores también pueden participar en otros programas de recompensas de Google. Entre ellos se incluyen programas que cubren Chrome, Android, dispositivos de Google, servicios en la nube y problemas específicos de seguridad de IA.
Esta distinción de alcance es importante. Describir la medida como un cierre total exageraría el evento y ocultaría la respuesta más focalizada de Google.
En la práctica, la empresa está cerrando un canal de recepción de gran volumen mientras mantiene disponibles canales más restringidos. Planea reformular ese canal antes de abordar su futuro.
El reemplazo exacto sigue siendo desconocido. Google no ha detallado públicamente si añadirá requisitos más estrictos de identidad, reproducción, frecuencia de envío o evidencia.
Google ya había endurecido el programa antes de la suspensión. Sus reglas del OSS VRP exigían a los investigadores validar los hallazgos asistidos por IA y demostrar un impacto real de seguridad.
Las reglas describían varios problemas recurrentes. Algunos reportes generados por IA incluían condiciones de activación incorrectas o detalles técnicos inventados.
Otros reportes identificaban errores reales de programación, pero no lograban establecer consecuencias de seguridad. Un desbordamiento de búfer, por ejemplo, podría existir solo en código inalcanzable o detrás de una barrera de seguridad efectiva.
Google también eliminó las recompensas monetarias y el reconocimiento público para determinadas vulnerabilidades de producto de nivel inferior y otros problemas de seguridad. Ese cambio de abril de 2026 buscaba eliminar incentivos para envíos de bajo impacto.
La suspensión posterior sugiere que esos controles más limitados no redujeron lo suficiente la carga de revisión. Google pasó de desalentar reportes débiles a rechazar temporalmente la categoría.
Por tanto, la suspensión del OSS VRP de Google representa una decisión operativa. Los revisores del programa ya no podían tratar cada posibilidad enviada como un punto de partida asumible.
Los reportes de errores de IA cambiaron el costo de presentar una afirmación
La IA reduce el costo de alegar una vulnerabilidad sin reducir el costo de demostrarla.
La investigación tradicional de vulnerabilidades requería un esfuerzo manual considerable antes de que un investigador pudiera elaborar un reporte plausible. El investigador debía inspeccionar el código, comprender las rutas de ejecución y construir una prueba.
Los modelos lingüísticos modernos y los agentes autónomos de código pueden analizar repositorios y generar hipótesis mucho más rápido. También pueden producir reportes pulidos que se asemejan a un análisis humano cuidadoso.
Esa apariencia crea una asimetría peligrosa. Un documento convincente puede generarse en segundos, mientras que refutar sus afirmaciones puede consumir horas de atención especializada.
Un reporte podría identificar una operación de memoria sospechosa y predecir ejecución remota de código. Después, el modelo puede crear una narrativa detallada de ataque en torno a esa predicción.
Sin embargo, la función afectada podría no procesar nunca una entrada controlada por un atacante. El compilador podría eliminar la ruta, o la validación existente podría bloquear el desencadenante propuesto.
El modelo de amenazas del proyecto también podría excluir los privilegios supuestos del atacante. En cada caso, el reporte parece grave sin lograr demostrar una vulnerabilidad.
Los mantenedores no pueden rechazar con seguridad todos los reportes automatizados de un vistazo. Un envío mal redactado aún puede contener una falla real, mientras que uno pulido puede ser enteramente especulativo.
Los revisores deben inspeccionar el código, recrear el entorno, probar la entrada alegada y evaluar las defensas existentes. También pueden necesitar contactar al remitente para obtener evidencia faltante.
Esta carga de trabajo aumenta con cada reporte, incluidos los inválidos. Por tanto, los envíos automatizados trasladan el costo de la validación de los reporteros a los mantenedores.
El efecto se parece más al spam de correo electrónico que a la investigación de seguridad tradicional. Enviar otro mensaje casi no cuesta nada, pero las organizaciones receptoras aún deben filtrar cada afirmación potencialmente importante.
Las recompensas económicas pueden intensificar este desequilibrio. Si un resultado aceptado cubre el costo de generar miles de envíos, el volumen se convierte en una estrategia racional para participantes poco rigurosos.
Ese comportamiento perjudica a los investigadores que realizan un trabajo cuidadoso. Sus hallazgos entran en la misma cola y compiten por los mismos revisores.
También perjudica a los usuarios cuando los mantenedores dedican menos tiempo a corregir vulnerabilidades confirmadas. El triaje se convierte en el cuello de botella antes incluso de que pueda comenzar la corrección.
El problema no es simplemente que los modelos alucinen. Los investigadores humanos también cometen errores, exageran el impacto y presentan duplicados.
La IA cambia la escala, la velocidad y la presentación de esos fallos. Permite que una persona produzca más afirmaciones plausibles de las que puede validar personalmente.
Esta distinción explica por qué prohibir la prosa generada por IA resolvería poco. Un investigador podría reescribir una salida de modelo no verificada y presentar la misma afirmación sin respaldo.
En cambio, los programas necesitan filtros basados en evidencia. La pregunta relevante es si el reportero probó el resultado, no si un modelo contribuyó a su descubrimiento.
La pausa de Google indica que sus reglas existentes no podían aplicar esa distinción de manera eficiente. Los requisitos por escrito eran más fáciles de publicar que de aplicar ante un volumen industrializado de reportes.
La estrategia de seguridad de IA de Google se enfrenta ahora a su propia disyuntiva
Google promueve el descubrimiento de seguridad asistido por IA, pero su programa de recompensas no puede absorber cada hallazgo producido por la misma oleada de automatización.
La suspensión del OSS VRP de Google no significa que la empresa considere inútil a la IA para la seguridad. Google sigue invirtiendo en el descubrimiento y la corrección automatizados de vulnerabilidades.
Sus equipos de seguridad utilizan herramientas como OSS-Fuzz, Big Sleep y CodeMender. Estos sistemas combinan análisis automatizado con pruebas controladas y revisión experta.
Google también ha reformulado sus programas de recompensas de Android y Chrome para lo que denomina la era de la IA. La empresa espera que la automatización descubra vulnerabilidades que la investigación convencional no detecta.
Eso hace que la suspensión sea una reversión significativa. Google no está abandonando la investigación de seguridad con IA, pero está limitando un canal externo afectado por los menores costos de envío que trae la IA.
La división central no es entre investigación humana e investigación automática. Es entre automatización validada internamente y afirmaciones enviadas externamente con una validación desigual.
Google controla el entorno de sus propios sistemas. Los ingenieros pueden definir objetivos, ejecutar pruebas, recopilar fallos y medir si los parches generados preservan el comportamiento.
Un programa abierto de recompensas carece de ese control. Los participantes utilizan distintas herramientas, instrucciones, modelos, versiones de código y definiciones de impacto de seguridad.
Los revisores reciben la afirmación final sin ver cada paso que la produjo. Deben reconstruir las suposiciones faltantes antes de decidir si el hallazgo importa.
Esa diferencia convierte la procedencia en una cuestión práctica de seguridad. Los equipos necesitan saber qué revisión se probó, qué entrada activó el resultado y si una persona lo reprodujo.
El sistema de recompensas más amplio de Google sigue siendo considerable. La empresa afirmó que sus programas pagaron más de 17 millones de dólares a más de 700 investigadores durante 2025.
Su revisión anual del VRP describió ese total como un máximo histórico. La cantidad aumentó más de un 40 por ciento respecto a 2024.
Estas cifras muestran que Google sigue valorando la investigación externa. También demuestran por qué es importante mantener canales de envío creíbles.
Un programa de recompensas depende de la confianza mutua. Los investigadores deben creer que los hallazgos válidos recibirán una atención justa, mientras que las empresas deben confiar en que los reporteros probarán sus afirmaciones.
La automatización sin filtrar debilita ambos lados. Las demoras en la revisión frustran a los investigadores capaces, y los reportes inválidos recurrentes hacen que los revisores sean más escépticos ante colaboradores desconocidos.
La respuesta de Google protege la capacidad de triaje, pero también restringe el acceso. Actualmente, los investigadores independientes no pueden enviar vulnerabilidades ordinarias de producto mediante la categoría suspendida del OSS VRP.
Esa limitación podría suprimir hallazgos valiosos junto con el ruido. Un investigador nuevo con un problema válido podría carecer de un programa alternativo evidente.
Por tanto, el desafío es una disyuntiva entre apertura y verificación. El acceso amplio incrementa las oportunidades de descubrimiento, mientras que los filtros estrictos protegen el tiempo limitado de los revisores.
Cualquier programa rediseñado debe preservar ambos objetivos. Si los requisitos de entrada se vuelven demasiado exigentes, Google corre el riesgo de concentrar la participación entre investigadores establecidos y empresas especializadas.
Si los requisitos siguen siendo demasiado laxos, la cola de envíos puede volver a la misma sobrecarga. La actualización del primer trimestre de 2027 revelará dónde traza Google esa línea.
La avalancha de reportes de IA es un problema de toda la industria
La decisión de Google forma parte de un cambio más amplio en el que las comunidades de seguridad están reescribiendo las reglas de divulgación en torno al descubrimiento automatizado.
HackerOne informó de un aumento de más del 100 por ciento en el volumen de reportes del sector después de que aparecieran herramientas de IA más capaces en febrero de 2026.
Su análisis del volumen de reportes concluyó que algunas solicitudes contenían hallazgos útiles. Otras eran duplicados, afirmaciones no verificables o reportes sin profundidad práctica.
La plataforma no respondió prohibiendo la asistencia responsable de IA. En cambio, reforzó la obligación del investigador de validar los hallazgos y demostrar un impacto real.
Las reglas de HackerOne exigen una prueba de concepto reproducible, una severidad precisa y la consideración de las defensas existentes. Grandes lotes de reportes no verificados pueden activar medidas de cumplimiento.
Ese enfoque sitúa la responsabilidad en el operador, no en la herramienta. Un investigador sigue siendo responsable de cada endpoint generado, paso de ataque y afirmación sobre el impacto.
La comunidad del kernel de Linux ha adoptado un enfoque similar centrado en la evidencia. Sus reglas para reportar problemas de seguridad ahora abordan directamente la revisión de código asistida por IA.
La documentación señala que los reportes de IA a menudo se vuelven excesivamente largos y ocultan los hechos críticos. Pide a quienes reportan que proporcionen descripciones concisas, revisiones afectadas, condiciones de activación y reproductores probados.
Linux también advierte que las herramientas pueden inventar un impacto teórico sin comprender el modelo de amenazas del kernel. En su lugar, pide a quienes reportan que expongan consecuencias verificables.
El proyecto trata de forma distinta los hallazgos automatizados ampliamente reproducibles y los descubrimientos tradicionalmente privados. Varios investigadores suelen encontrar el mismo problema porque ejecutan herramientas similares.
Esto genera trabajo duplicado dentro de canales de divulgación diseñados para vulnerabilidades escasas y descubiertas de forma independiente. La automatización cambia los supuestos en los que se basaban esos canales.
El mantenedor de Curl, Daniel Stenberg, describió otra versión del problema en 2025. Su argumento de la “muerte por mil porquerías” se centraba en el coste acumulado de revisar envíos débiles.
Un solo mal reporte puede parecer manejable. Repetir ese coste en cientos de afirmaciones generadas puede agotar a un proyecto mantenido por voluntarios.
Estos casos comparten un mismo mecanismo. La IA amplía la oferta de hipótesis de vulnerabilidades más rápido de lo que crece la oferta de trabajo cualificado de clasificación.
El impacto varía según la organización. Google puede asignar ingenieros de seguridad remunerados, mientras que los proyectos más pequeños suelen depender de voluntarios con tiempo limitado.
Los mantenedores de código abierto afrontan una estructura de incentivos especialmente difícil. El código público es fácil de incorporar para los escáneres automatizados, pero los mantenedores no reciben recursos equivalentes.
Las recompensas pueden añadir otro desequilibrio. Una empresa puede premiar los hallazgos aceptados, mientras que los mantenedores comunitarios gestionan las conversaciones iniciales o la corrección upstream sin compensación.
Esto no hace que la investigación automatizada sea intrínsecamente perjudicial. La IA puede inspeccionar componentes poco conocidos, traducir código desconocido y ayudar a los investigadores a crear pruebas.
También puede mejorar la calidad de los reportes cuando se utiliza después de la verificación. Un modelo puede organizar los pasos de reproducción o explicar con más claridad un flujo de control complejo.
Las mismas capacidades se vuelven destructivas cuando sustituyen a la verificación. Generar una narrativa plausible no equivale a demostrar una condición explotable.
Por tanto, el consenso emergente del sector es una aceptación condicionada. La asistencia de IA sigue siendo bienvenida cuando un operador humano puede reproducir y defender cada afirmación importante.
El cierre temporal de Google es más restrictivo que ese principio. Sin embargo, refleja el mismo criterio sobre dónde debe recaer la responsabilidad.
La persona que presenta un reporte debe asumir suficiente coste de validación para proteger al destinatario. De lo contrario, el programa se convierte en una cola de pruebas externalizada para resultados especulativos de máquinas.
Unos filtros más estrictos pueden ayudar, pero introducen nuevos riesgos
Un programa rediseñado debe incorporar el coste de la verificación en cada envío sin excluir a investigadores independientes legítimos.
Google no ha revelado el reemplazo definitivo para las solicitudes de vulnerabilidades de productos. Varios controles encajarían con los problemas identificados en sus reglas anteriores.
El primero es un reproductor probado obligatorio. Un reproductor proporciona un pequeño programa, entrada o procedimiento que activa de forma consistente el comportamiento alegado.
Google podría exigir a quienes reportan que indiquen la revisión exacta del repositorio y el entorno. Esa información reduciría el tiempo perdido al probar código obsoleto o incompatible.
Los reportes también podrían requerir un argumento explícito de alcanzabilidad. La persona que reporta tendría que mostrar cómo los datos controlados por un atacante llegan a la operación vulnerable.
Un campo estructurado de modelo de amenazas podría obligar a los investigadores a identificar los privilegios necesarios, los límites de confianza y las mitigaciones existentes. Las afirmaciones de severidad sin respaldo serían más fáciles de detectar.
Los límites de frecuencia ofrecen otra opción. Google podría restringir cuántos reportes sin resolver presenta una cuenta durante un período fijo.
Eso desalentaría los envíos indiscriminados y conservaría el acceso para investigadores cuidadosos. Los límites más altos podrían depender de un historial de trabajo aceptado.
Los depósitos o requisitos de reputación podrían proporcionar un filtrado más estricto, pero conllevan mayores riesgos de equidad. Los investigadores nuevos podrían tener dificultades para entrar en el programa.
El filtrado previo automatizado es otro componente probable. Google podría utilizar análisis estático, ejecución en sandbox o revisión basada en modelos para señalar duplicados y pruebas faltantes.
Sin embargo, el filtrado automatizado no puede convertirse de forma segura en la autoridad final. Puede rechazar investigaciones inusuales pero válidas o favorecer patrones de vulnerabilidad conocidos.
Un modelo que revisa el reporte de otro modelo también puede reproducir los mismos supuestos erróneos. La evidencia de ejecución independiente sigue siendo más valiosa que la coincidencia textual.
La privacidad y la confidencialidad introducen complicaciones adicionales. Los investigadores pueden exponer detalles sin parchear a servicios de IA de terceros al pedir análisis a los modelos.
Un programa revisado podría exigir la divulgación del uso de modelos externos en torno a hallazgos confidenciales. También podría restringir qué materiales sensibles ingresan en sistemas alojados.
Google también debe aclarar cómo participan los mantenedores de código abierto en la clasificación. Un reporte puede afectar a un repositorio de Google mientras impone trabajo a una comunidad más amplia de colaboradores.
La empresa debería evitar resolver su problema de cola trasladando las tareas de verificación upstream. Eso reubicaría la carga en lugar de reducirla.
La transparencia importará durante la pausa. Google no ha publicado un desglose detallado de los reportes aceptados, duplicados, inválidos y asistidos por IA.
Tom’s Hardware describió a ingenieros y mantenedores enfrentándose a miles de envíos deficientes. Sin embargo, el aviso publicado por Google no proporcionó un volumen preciso ni una tasa de aceptación.
Esa distinción limita lo que los observadores externos pueden concluir. La evidencia disponible respalda la existencia de un problema serio de calidad, pero no ofrece una imagen cuantitativa completa.
Google debería publicar suficientes datos agregados para explicar los umbrales rediseñados. Entre las métricas útiles se encuentran el tiempo medio de revisión y la proporción de reportes sin reproductores funcionales.
Las tasas de falsos rechazos también importan. Una cola más rápida no es un éxito si los hallazgos sólidos desaparecen porque los filtros automatizados los clasifican erróneamente.
El programa debería distinguir entre asistencia para el descubrimiento y presentación autónoma. Un hallazgo de IA revisado por un humano puede ser valioso, mientras que una cadena de presentación de reportes no supervisada crea un riesgo sin gestionar.
El diseño más sólido de Google haría que la prueba fuera más barata de evaluar que la prosa. Las pruebas legibles por máquinas, las plantillas restringidas y los entornos reproducibles podrían respaldar ese objetivo.
La empresa también debería mantener una vía de escalamiento para hallazgos no convencionales. Algunas vulnerabilidades importantes se resisten a casos de prueba simples o implican cadenas complejas.
Ningún filtro único equilibrará estos requisitos. La respuesta probable es un acceso por capas basado en la calidad de la evidencia, el historial del investigador y el impacto de seguridad demostrado.
Qué observar antes de la actualización de Google del primer trimestre de 2027
La siguiente fase mostrará si Google puede reabrir las solicitudes con mejores estándares de evidencia en lugar de limitarse a aceptar menos investigadores.
La primera señal es el alcance del programa de reemplazo. Google debe explicar si las solicitudes de vulnerabilidades de productos se reabren por completo o regresan a través de un canal más limitado.
Una reapertura completa sugeriría que los nuevos filtros restablecieron la confianza en el proceso de revisión. Un sistema de invitación limitado indicaría que la capacidad de clasificación sigue restringida.
La segunda señal es la evidencia exigida a quienes reportan. Los reproductores probados, los commits afectados y las rutas de ataque concretas abordarían las debilidades que Google ya identificó.
Esos requisitos fortalecerían el programa si siguen siendo accesibles. Lo debilitarían si solo los investigadores establecidos pueden cumplir estándares de revisión opacos.
La tercera señal es cómo responden otros programas de seguridad. HackerOne, Linux y los principales proveedores están experimentando con reglas de envío adaptadas a la IA.
Si convergen en la reproducibilidad y la responsabilidad humana, el sector podría desarrollar una base compartida. Eso podría reducir la confusión de los investigadores que trabajan en distintos programas.
Si, en cambio, los programas adoptan restricciones incompatibles, la divulgación se volverá más difícil. Los investigadores podrían necesitar paquetes de evidencia, políticas de IA y prácticas de confidencialidad distintos para cada objetivo.
Los desarrolladores también deberían observar las propias herramientas. Los agentes mejores pueden producir pruebas funcionales, pero pueden generar evidencia inválida con mayor confianza.
El criterio clave no es cuántas alertas encuentra un agente. Es cuántos hallazgos reproducibles de forma independiente y relevantes para la seguridad sobreviven a la revisión de expertos.
Los mantenedores deberían seguir el tiempo dedicado por vulnerabilidad aceptada, no el número bruto de envíos. Esa métrica captura si la automatización mejora la seguridad o simplemente amplía la cola.
Los equipos de investigación pueden prepararse documentando cada etapa del trabajo asistido por IA. Guarden el commit probado, la configuración, los registros, las entradas y los intentos fallidos de reproducción.
Los equipos también necesitan un registro consultable de hallazgos previos. Una base de conocimiento de ingeniería estructurada puede ayudar a identificar duplicados antes de que lleguen a los mantenedores.
Los investigadores deberían poder explicar el defecto sin depender de prosa generada. Deberían saber por qué la ruta de código es alcanzable y qué control existente falla.
Si falta esa explicación, el hallazgo sigue siendo una hipótesis. No está listo para un programa de recompensas por vulnerabilidades.
Por tanto, la suspensión del Google OSS VRP es una advertencia sobre el diseño del flujo de trabajo, no un veredicto contra la investigación de seguridad con IA. El descubrimiento se ha acelerado, pero la verificación no ha desaparecido.
La actualización de Google del primer trimestre de 2027 pondrá a prueba si un gran proveedor puede reconstruir un programa abierto en torno a esa realidad. El mejor resultado no maximizaría los envíos.
Maximizaría el valor de seguridad verificado por hora de atención del revisor. Ese estándar ofrece a los investigadores serios un objetivo claro y protege a los mantenedores del volumen especulativo.
Antes de presentar un hallazgo asistido por IA en cualquier lugar, haga tres preguntas. ¿Puede otra persona reproducirlo, cruza un límite de seguridad real y ha probado cada afirmación principal?
Si alguna respuesta es no, siga investigando. El reporte más barato de generar puede convertirse en el más costoso de refutar para un mantenedor.
