La suspensión del OSS VRP de Google expone el coste oculto de los informes de errores generados por IA
Google dejó de aceptar nuevas comunicaciones de vulnerabilidades de producto a través de su programa de recompensas de código abierto el 1 de octubre, después de que informes de IA no válidos desbordaran su proceso de revisión. La suspensión del Google OSS VRP no pone fin a todas las partes del programa. Sin embargo, cierra una importante vía de comunicación hasta que Google complete un rediseño.
El problema inmediato no es que la inteligencia artificial no pueda encontrar fallos de software. Los sistemas de IA ya están descubriendo defectos válidos en grandes bases de código sometidas a exhaustivas revisiones. El problema es que generar un informe plausible cuesta ahora mucho menos que demostrar su impacto en la seguridad.
Ese desequilibrio ha convertido el triaje de vulnerabilidades en el recurso escaso. Google debe separar los hallazgos reales de rutas de ataque alucinadas, código inaccesible, duplicados y errores de programación comunes. GitHub, los mantenedores de Linux y los proyectos de código abierto más pequeños afrontan la misma presión.
Google afirma que los informes enviados antes de la fecha límite seguirán siendo considerados. Los informes sobre la cadena de suministro permanecen abiertos, mientras que determinados fallos en repositorios de Google Cloud pueden utilizar el Cloud Vulnerability Reward Program. La empresa espera ofrecer otra actualización antes del primer trimestre de 2027.
La pausa plantea un conflicto revelador. La IA promete ampliar la investigación defensiva en seguridad, pero la automatización sin verificar puede consumir la atención humana necesaria para corregir vulnerabilidades reales. El futuro de la búsqueda de errores asistida por IA depende ahora menos del volumen bruto de descubrimientos y más de la calidad de las pruebas.
La suspensión del Google OSS VRP es limitada, pero inmediata
Google ha congelado una categoría de envíos, no ha abandonado su relación más amplia con los investigadores externos de seguridad.
El programa afectado es el Open Source Software Vulnerability Reward Program, conocido habitualmente como OSS VRP. Google lo lanzó en 2022 para recompensar a investigadores que divulgaran de forma responsable vulnerabilidades que afectaran a proyectos de código abierto elegibles.
El programa cubre software alojado en repositorios públicos propiedad de Google y proyectos seleccionados hospedados en otros lugares. Su alcance ha incluido tanto vulnerabilidades de producto como compromisos de la cadena de suministro. Estas categorías abordan riesgos distintos y ahora siguen vías de envío diferentes.
Las vulnerabilidades de producto se refieren a defectos en el código, la lógica o el diseño de un proyecto. Un informe convincente debe mostrar que los atacantes pueden alcanzar el defecto y generar consecuencias de seguridad significativas. Identificar simplemente una función que parece insegura no demuestra la explotación.
Los informes sobre la cadena de suministro se refieren a amenazas en la forma en que el software se compila, empaqueta, firma o distribuye. Una canalización de lanzamiento comprometida puede propagar código malicioso incluso cuando el código fuente subyacente parece legítimo. Google ha mantenido abierta esa categoría de informes.
La suspensión se aplica a los nuevos informes de vulnerabilidades de producto presentados a partir del 1 de octubre de 2026. Los envíos anteriores siguen siendo elegibles para revisión bajo el proceso previo. Google también dirigió a los investigadores hacia sus otros programas de recompensas por vulnerabilidades cuando correspondiera.
Algunos informes relacionados con repositorios de Google Cloud aún pueden calificar a través del Cloud VRP. Esa excepción depende de si el problema afecta a un producto de Google Cloud, no simplemente de que el repositorio de código fuente pertenezca a Google.
Google anunció el cambio a través de su cuenta Bug Hunters en X. Según el primer relato publicado detallado, la empresa vinculó su decisión a una afluencia de envíos no válidos impulsados por IA.
La pausa sigue a meses de endurecimiento, más que a un giro repentino. En una actualización de reglas de abril, Google describió un aumento de informes inválidos y de baja calidad que llegaban al OSS VRP.
Google identificó dos patrones recurrentes. Algunos envíos contenían explicaciones alucinadas sobre cómo podía activarse una supuesta vulnerabilidad. Otros encontraban errores de programación reales, pero no lograban demostrar código alcanzable ni un impacto material en la seguridad.
Esa distinción importa porque los defectos de software y las vulnerabilidades de seguridad no son intercambiables. Un fallo en una utilidad de pruebas inaccesible tiene consecuencias diferentes de la ejecución remota de código en un servicio de producción.
Google ya había dejado de ofrecer recompensas o reconocimiento por determinadas vulnerabilidades de producto y otros problemas de seguridad en niveles de proyectos de menor prioridad. También hizo hincapié en hallazgos accionables, pasos de reproducción verificados y demostraciones de impacto.
Por tanto, la medida de octubre amplía un esfuerzo existente para reducir el ruido. En vez de ajustar la elegibilidad mientras los informes seguían llegando, Google ha cerrado el canal de recepción afectado durante un rediseño más amplio.
La empresa no ha revelado el número exacto de informes rechazados, el tamaño de su acumulación pendiente ni su tasa de aceptación. Las afirmaciones sobre miles de envíos siguen siendo cifras reportadas, no estadísticas completas del programa.
La falta de esos datos limita el análisis externo. Sin embargo, la secuencia de cambios de reglas, advertencias públicas y la congelación final muestra que el filtrado incremental no resolvió el problema de carga de trabajo.
Por qué los informes de errores de IA no válidos desbordan el triaje de seguridad
La IA cambia la economía de los informes porque los envíos escalan automáticamente, mientras que la validación sigue exigiendo un escaso juicio humano.
La investigación tradicional de vulnerabilidades requiere varios pasos costosos. Un investigador debe comprender el objetivo, identificar una debilidad, construir un ataque reproducible, evaluar el impacto y comunicar claramente el resultado.
Los modelos de lenguaje grandes pueden acelerar partes de ese trabajo. Pueden inspeccionar código fuente, sugerir flujos de datos peligrosos, redactar casos de prueba y convertir notas preliminares en prosa pulida. Los agentes automatizados pueden repetir esos pasos en numerosos repositorios.
Las mismas herramientas también pueden producir explicaciones seguras de sí mismas, pero falsas. Un modelo puede asumir que los atacantes controlan una entrada que sigue siendo de confianza. Puede pasar por alto una comprobación de permisos, malinterpretar una configuración de despliegue o inventar una ruta de ejecución alcanzable.
Estos fallos se vuelven costosos después del envío. Un ingeniero de seguridad no puede rechazar un informe con apariencia creíble basándose en su tono. Debe inspeccionar el código citado, reproducir las condiciones, rastrear los datos y comprobar si existe el impacto alegado.
Por ello, un informe falso puede tardar minutos en crearse y horas en descartarse. Mil informes similares convierten ese desequilibrio en una denegación de servicio operativa, incluso sin intención maliciosa.
La presentación del informe puede empeorar el problema. Los modelos de lenguaje generan con facilidad extensas narrativas de vulnerabilidades, etiquetas de severidad, diagramas de ataque y recomendaciones de mitigación. Ninguno de esos añadidos sustituye una reproducción funcional.
El lenguaje pulido puede incluso incrementar los costes de triaje. Los revisores deben localizar la afirmación factual dentro de páginas de contexto generado. También necesitan determinar qué declaraciones proceden de pruebas y cuáles de inferencias del modelo.
Las reglas anteriores de Google se centraban en esta diferencia entre detección y validación. Una advertencia de un analizador estático puede identificar código sospechoso. No demuestra automáticamente que el código genere una vulneración explotable de un límite de seguridad.
La accesibilidad es una prueba esencial. Los revisores necesitan evidencias de que una entrada no confiable puede llegar a la operación peligrosa en condiciones realistas. Los informes también deben tener en cuenta la sanitización, los privilegios, la configuración y las defensas existentes.
El impacto es otra prueba. Un desbordamiento de búfer suena grave, pero su ubicación y los controles circundantes determinan qué puede lograr un atacante. Algunos fallos solo terminan un proceso aislado sin exponer datos ni control.
La novedad también importa. Los sistemas automatizados pueden redescubrir problemas conocidos, repetir teorías rechazadas previamente o producir varias descripciones de la misma causa raíz. Cada duplicado sigue consumiendo capacidad de recepción y revisión.
Esta carga de trabajo recae en personas especializadas. Los mantenedores y los ingenieros de seguridad con experiencia entienden supuestos arquitectónicos que los modelos suelen pasar por alto. Dedicarlos a validaciones repetitivas retrasa parches, auditorías, revisiones de diseño y respuesta a incidentes.
El coste de oportunidad se extiende más allá de Google. Los proyectos de código abierto suelen contar con grupos pequeños de mantenedores, incluso cuando su código respalda servicios ampliamente utilizados. Una campaña automatizada de informes puede superar toda su capacidad de seguridad.
Los equipos pueden preservar el contexto manteniendo decisiones, reproducciones y hallazgos previos en una base de conocimientos de ingeniería con capacidad de búsqueda. Esa práctica reduce las investigaciones repetidas, pero no puede eliminar la necesidad de verificación experta.
La pausa del programa de recompensas de Google visibiliza esa limitación de mano de obra. Los programas de seguridad se diseñaron en torno a envíos que implicaban un esfuerzo significativo por parte de los investigadores. La IA permite al remitente transferir gran parte de ese esfuerzo al equipo receptor.
Los informes de errores de IA crean un problema de calidad, no una prohibición de la IA
El conflicto central es entre investigación verificada y automatización no verificada, no entre investigadores humanos e inteligencia artificial.
Google no ha sostenido que los investigadores deban evitar la IA por completo. Su postura declarada es que las personas deben validar la salida de la IA durante la investigación. Ese requisito trata a la IA como un instrumento, no como un informante responsable.
Un envío útil asistido por IA puede incluir pruebas directas. Los investigadores pueden proporcionar versiones afectadas, comandos exactos, casos de prueba minimizados, registros, capturas de pantalla y resultados observados. También pueden explicar el límite de seguridad vulnerado.
La pregunta decisiva es si una persona confirmó la afirmación. Una hipótesis generada por un modelo se vuelve valiosa cuando las pruebas demuestran que el código relevante es alcanzable y que el resultado afecta a la confidencialidad, la integridad o la disponibilidad.
Este estándar protege la automatización legítima. Los fuzzers llevan años generando hallazgos de seguridad al enviar entradas inesperadas y registrar fallos. Su valor procede de resultados concretos y reproducibles, no de descripciones persuasivas.
Los agentes de IA pueden ampliar ese modelo. Pueden razonar sobre el código fuente, crear arneses de prueba, investigar fallos y proponer parches. Su espacio de búsqueda más amplio puede revelar defectos que las herramientas convencionales pasan por alto.
Sin embargo, los sistemas de razonamiento introducen otro modo de fallo. Pueden cubrir la falta de evidencias con lenguaje plausible. Un escáner convencional normalmente informa del patrón que detectó, mientras que un modelo de lenguaje puede inventar toda una narrativa de ataque.
Esa diferencia explica por qué los programas de divulgación no pueden simplemente puntuar los informes por su fluidez. Los revisores necesitan artefactos vinculados a comportamientos observables. Las afirmaciones sobre consecuencias teóricas merecen menos confianza que los resultados demostrados.
La evidencia más sólida contra un rechazo generalizado de la IA proviene del trabajo de seguridad exitoso con IA. Los sistemas de IA han encontrado vulnerabilidades genuinas en importantes proyectos de código abierto, incluidos fallos que los revisores humanos habían pasado por alto.
Esos resultados muestran por qué prohibir todos los informes asistidos por IA sería miope. Los equipos defensivos quieren una cobertura más amplia, especialmente en grandes grafos de dependencias y bases de código maduras. No quieren una especulación ilimitada y sin probar.
Google utiliza IA en su propia investigación defensiva de seguridad. Su trabajo de seguridad más amplio incluye descubrimiento de vulnerabilidades asistido por IA y fuzzing de código abierto. La objeción de la empresa se refiere a la calidad de la validación en el límite de comunicación.
Ese límite plantea una cuestión de responsabilidad. Cuando un agente autónomo presenta un informe, ¿quién responde a las preguntas de seguimiento? Alguien debe aclarar las premisas, modificar la reproducción y distinguir entre el comportamiento observado y el previsto.
Un informe sin un investigador responsable traslada esas tareas al mantenedor. El destinatario pasa a ser responsable de completar la investigación que inició quien lo presentó.
Una divulgación clara del uso de IA puede ayudar, pero la divulgación por sí sola no puede demostrar calidad. Un informe escrito por una persona también puede ser erróneo. Un informe generado por IA puede ser correcto, conciso y estar probado exhaustivamente.
Por lo tanto, los programas necesitan filtros basados en evidencia, no detectores de estilo. Los clasificadores de texto generado por IA pueden etiquetar erróneamente la redacción técnica, especialmente cuando los investigadores usan plantillas o escriben en una segunda lengua.
Un sistema de admisión mejor evalúa el contenido del informe. Puede exigir una reproducción mínima, detalles del entorno, commits afectados, pruebas de alcanzabilidad y una explicación directa de las capacidades del atacante.
La suspensión del OSS VRP de Google da a la empresa tiempo para diseñar esos filtros. El riesgo es que un sistema más estricto también excluya a recién llegados capacitados que carecen de reputación, pero tienen un hallazgo válido.
Ese equilibrio no puede desaparecer. Los programas abiertos atraen descubrimientos inesperados porque cualquiera puede participar. Restringir el acceso mejora la calidad media, pero reduce la probabilidad de que un investigador desconocido llegue al equipo adecuado.
GitHub y los mantenedores de código abierto están endureciendo el mismo filtro
La decisión de Google forma parte de un cambio generalizado en la industria: de una admisión abierta hacia la reputación, la evidencia y canales de envío más acotados.
GitHub afrontó su propio retraso de informes de bajo esfuerzo y generados por IA durante 2026. Respondió reestructurando su programa de recompensas y creando vías separadas para investigadores públicos e invitados.
El programa público añadió un requisito de señal de HackerOne, que utiliza el historial previo de un investigador en la plataforma como medida de elegibilidad. El programa por invitación ofrece una vía distinta para investigadores con confianza consolidada.
GitHub afirmó que su objetivo era reducir el volumen de bajo esfuerzo y preservar al mismo tiempo la investigación externa seria. Su anuncio de reestructuración aplicó la nueva estructura a los informes enviados a partir del 27 de julio de 2026.
Las orientaciones anteriores explicaban qué consideraba la plataforma como evidencia útil. Un informe sólido necesitaba un resumen conciso, pasos de reproducción con artefactos de apoyo y una declaración clara del impacto que podría lograr un atacante.
GitHub también advirtió que las narrativas teóricas y el relleno generado por IA ralentizaban el triaje. El problema no era simplemente el contenido inexacto. Una explicación excesiva podía ocultar el hallazgo real y retrasar la revisión.
Google y GitHub eligieron respuestas inmediatas diferentes. GitHub mantuvo una vía pública con filtros de reputación y calidad más sólidos. Google suspendió una categoría de OSS VRP mientras mantenía disponibles otros programas de vulnerabilidades.
Ambos enfoques protegen la atención de los revisores. También generan fricción para nuevos investigadores que aún no han construido reputación en las plataformas. Un excelente primer informe puede provenir de alguien sin un largo historial de recompensas.
Los mantenedores de código abierto afrontan una versión aún más aguda de este problema. Muchos proyectos no cuentan con personal de seguridad dedicado, equipos de triaje remunerados ni infraestructura formal para recibir envíos. Un mantenedor puede revisar informes en su tiempo personal.
Las orientaciones del sector asignan cada vez más responsabilidad a ambas partes. La Open Source Security Foundation aconseja a los investigadores verificar sus hallazgos, comprender las políticas del proyecto y divulgar claramente cómo contribuyó la IA al trabajo.
Su guía para mantenedores también reconoce que la IA puede respaldar análisis defensivos legítimos. La respuesta recomendada se centra en una integración segura y la revisión humana.
El patrón más amplio se parece al control del spam. Cuando enviar se vuelve casi gratuito, los destinatarios deben introducir filtros, señales de reputación, límites de frecuencia o costes de envío. De lo contrario, el volumen de baja calidad abruma la comunicación valiosa.
Los programas de recompensas por errores no pueden copiar exactamente los filtros de spam convencionales. Los informes de seguridad contienen detalles técnicos novedosos y a menudo llegan de investigadores desconocidos. Rechazar contenido inusual con demasiada agresividad puede ocultar el descubrimiento más importante.
Es probable que los programas combinen varios controles. Los formularios estructurados pueden obligar a dar respuestas concretas. Las comprobaciones automatizadas pueden verificar si existen los artefactos requeridos. La reputación puede determinar límites de envío en lugar de la elegibilidad absoluta.
Los límites de frecuencia pueden ser especialmente importantes para los agentes autónomos. Una persona puede revisar varios candidatos generados por máquinas y enviar solo los más sólidos. Un sistema sin supervisión puede inundar un programa antes de que los mantenedores ofrezcan comentarios.
Los depósitos o bonos de envío reembolsables impondrían costes más altos, pero plantean problemas de acceso. Los investigadores de regiones con menores ingresos podrían enfrentar barreras desproporcionadas. La complejidad legal y administrativa también aumentaría.
Los programas privados o solo por invitación evitan el volumen público, pero pierden una participación amplia. Concentrarían la confianza entre investigadores conocidos y podrían pasar por alto a personas externas con conocimiento especializado de un componente concreto.
Por ello, el rediseño de Google tiene implicaciones que van más allá de una sola empresa. Otros operadores de programas estudiarán si restablece la señal sin cerrar la puerta al talento nuevo.
Los filtros más estrictos también pueden ocultar vulnerabilidades reales
Reducir el ruido de la IA es necesario, pero cada filtro crea la posibilidad de que un informe válido y poco familiar nunca llegue al ingeniero adecuado.
Google ha descrito las razones de la suspensión, pero no ha publicado datos completos de rendimiento. Las personas externas no pueden comparar las tasas de falsos positivos antes y después de la adopción de IA ni medir la gravedad real del retraso.
Sin esas cifras, siguen siendo posibles varias interpretaciones. Los envíos generados por IA pueden dominar la cola, o un grupo más pequeño de reporteros repetitivos puede generar la mayor parte de la carga. Causas diferentes requieren controles diferentes.
También importa la calidad de los modelos subyacentes. Una política diseñada en torno a las tasas actuales de alucinación puede envejecer rápidamente. Mejores agentes pueden producir reproducciones más sólidas, pero también pueden generar mayores volúmenes de informes.
El diseño del programa debe distinguir la confianza de la evidencia. Un agente que asigna una alta probabilidad a la explotación no ha demostrado la explotación. A la inversa, un informe incompleto aún puede describir un fallo grave que merece seguimiento.
Los nuevos investigadores suelen enviar informes imperfectos porque carecen de experiencia en divulgación. Su redacción puede parecerse a una salida automatizada de baja calidad, incluso cuando la observación subyacente es genuina.
El idioma y la accesibilidad crean riesgos similares. Exigir un inglés pulido puede perjudicar a investigadores que poseen un conocimiento técnico profundo. Los formularios deben exigir evidencia específica sin convertir el estilo en un sustituto de la credibilidad.
Los filtros de reputación también refuerzan el acceso previo. Los investigadores establecidos reciben más oportunidades para generar señales, mientras que los recién llegados tienen dificultades para entrar. Un circuito cerrado puede mejorar la eficiencia, pero debilitar la diversidad.
La automatización en el lado receptor presenta otra incertidumbre. Google puede usar modelos para resumir, deduplicar o priorizar informes. Esos sistemas requieren auditoría porque un falso negativo tiene consecuencias distintas de un falso positivo.
Un falso positivo desperdicia tiempo de los revisores. Un falso negativo puede dejar una vulnerabilidad sin descubrir. Por ello, los sistemas de admisión deberían automatizar el enrutamiento y las comprobaciones de evidencia con mayor facilidad que el rechazo final.
Las apelaciones ofrecen una salvaguarda. Un investigador rechazado debe entender qué elemento falló y si evidencia adicional puede reabrir el informe. Los mensajes de rechazo genéricos fomentan envíos repetidos y frustración pública.
Los ejemplos transparentes también pueden mejorar el comportamiento. Los programas pueden publicar casos anonimizados que muestren código inalcanzable, afirmaciones de impacto sin respaldo, causas raíz duplicadas y reproducciones aceptables.
Google ya ofrece orientación para reportar a través de sus programas de vulnerabilidades. Su marco de calidad enfatiza la información del objetivo, la reproducibilidad, el impacto y la comunicación.
El rediseño debe decidir si estos estándares pasan a ser requisitos previos aplicados por máquinas. También debe determinar qué informes merecen discreción humana pese a que les falte un campo formal.
Existe otro peligro al calificar cada envío no deseado como contenido basura de IA. La etiqueta puede ocultar desacuerdos genuinos sobre los modelos de amenaza. Investigadores y proveedores suelen evaluar la explotabilidad de forma diferente.
Una empresa puede rechazar un problema porque un atacante necesita interacción del usuario. Un investigador puede sostener que esa interacción sigue siendo realista. Estas disputas son anteriores a la IA generativa y no pueden resolverse mediante la detección de autoría.
La misma cautela se aplica a los defectos de código ordinarios. Algunos errores carecen de impacto inmediato, pero se vuelven peligrosos tras otro cambio de producto. Los programas necesitan límites, pero esos límites no deben confundirse con juicios universales sobre la gravedad.
Por tanto, la suspensión es una intervención de triaje, no una prueba de que los repositorios afectados se hayan vuelto más seguros. Las vulnerabilidades siguen existiendo mientras una vía de reporte permanece cerrada.
Los investigadores deben identificar otro canal apropiado o contactar directamente con el proyecto relevante. Las vías de divulgación fragmentadas pueden aumentar los retrasos, la publicación accidental y el trabajo duplicado.
Google puede reducir ese riesgo al dirigir claramente los informes excluidos. Su directorio público de programas ya separa los ámbitos de Google, Cloud, Chrome, Android, IA, abuso y código abierto.
El rediseño tendrá éxito solo si los investigadores válidos pueden prever el destino correcto. Una cola más pequeña sirve de poco si los informes serios desaparecen entre reglas de programa superpuestas.
Qué observar antes de que Google reabra los informes de productos
La próxima prueba será si Google reemplaza un formulario de envío abierto por un sistema que verifique la evidencia sin silenciar a investigadores poco conocidos.
La primera señal es la actualización prometida para el primer trimestre de 2027. Google debería aclarar si los envíos de vulnerabilidades de productos se reabrirán, se trasladarán a otro lugar o regresarán mediante un proceso de acceso limitado.
Una reapertura con requisitos de evidencia estructurada respaldaría la idea de que la suspensión fue un triaje temporal. Un cierre indefinido mostraría que Google ya no considera sostenible el antiguo modelo público.
La segunda señal es el diseño del filtro de admisión. Reproducciones obligatorias, versiones afectadas, commits probados, trazas de ejecución y declaraciones concisas de impacto abordarían directamente los modos de fallo documentados.
Las restricciones basadas únicamente en la reputación representarían una elección diferente. Podrían reducir rápidamente el volumen, pero darían más peso al historial del investigador que a la evidencia dentro de cada informe.
El tratamiento que Google dé a los agentes autónomos será especialmente importante. La empresa podría exigir que una persona identificada certifique que cada envío fue reproducido. También podría imponer límites de frecuencia a los reportes asistidos por máquinas.
Una política significativa debería separar la asistencia de IA de los envíos masivos sin supervisión. Los investigadores usan habitualmente automatización, depuradores, fuzzers, escáneres y modelos de lenguaje. La cuestión decisiva es quién valida y asume la responsabilidad de la afirmación.
La tercera señal es si el retraso mejora sin reducir los descubrimientos confirmados. Google no ha publicado datos suficientes para esa comparación, pero una transparencia futura ayudaría a otros programas a aprender del rediseño.
Las métricas útiles incluirían el volumen de envíos, el tiempo de validación, las tasas de duplicados, los hallazgos aceptados, las apelaciones de reporteros y la proporción de informes que contienen reproducciones funcionales. Las cifras agregadas podrían proteger los detalles sensibles.
Los investigadores también deberían vigilar los demás VRP de Google. Si los informes inválidos de errores de IA migran a los canales de Cloud, Chrome o los canales generales de Google, la suspensión habrá trasladado la carga de trabajo en lugar de resolverla.
El sistema más amplio de recompensas por errores de la empresa sigue activo. El directorio de programas de Google todavía canaliza los problemas de seguridad elegibles hacia varios programas especializados.
Los responsables de mantenimiento fuera de Google no deberían esperar a la política final. Pueden definir la evidencia aceptada, publicar modelos de amenazas, limitar los envíos automatizados y crear plantillas que separen las observaciones del impacto inferido.
Los investigadores también pueden adaptarse. Antes de presentar un informe, deberían reproducir el comportamiento, minimizar el caso de prueba, confirmar la revisión afectada y explicar el acceso que necesitaría el atacante.
Deberían eliminar el contenido generado que no respalde el hallazgo. Un informe breve con evidencia directa es más fácil de validar que un ensayo pulido construido sobre una premisa incierta.
La investigación de seguridad asistida por IA seguirá expandiéndose porque sus beneficios legítimos son considerables. Los modelos pueden examinar más código, generar pruebas específicas y ayudar a los investigadores a conectar componentes desconocidos.
Sin embargo, el volumen de descubrimientos ya no es la mejor medida del progreso. Un informe solo se vuelve útil cuando ofrece a los responsables de mantenimiento suficiente evidencia fiable para actuar.
La suspensión del OSS VRP de Google marca el momento en que esa distinción se volvió imposible de ignorar. El próximo diseño de programa debe recompensar los hallazgos verificados, preservar el acceso y mantener la atención humana centrada en el riesgo real.
Antes de enviar otro hallazgo asistido por IA, formule una pregunta más difícil que si el modelo encontró código sospechoso: ¿puede otro ingeniero reproducir el impacto de seguridad a partir de la evidencia proporcionada?
