El programa de Google para detectar fallos de seguridad en código abierto cierra: los informes generados por IA desbordaron el sistema
El programa de Google para recompensar el hallazgo de vulnerabilidades en código abierto ha sido cerrado. No porque las amenazas hayan disminuido, sino porque las herramientas de IA automatizadas inundaron el sistema con informes no válidos e inventados. No es casualidad ni sorpresa: los expertos en seguridad advirtieron sobre exactamente este escenario ya el año pasado. Ahora la advertencia se ha convertido en una interrupción real del servicio, y la pregunta es qué ocurre con todas las vulnerabilidades auténticas que nadie llega ya a revisar.
Cuando la herramienta se convierte en el problema
Hay una amarga ironía en lo que acaba de ocurrir en Google. El Open Source Software Vulnerability Rewards Program, un programa cuyo objetivo completo es reforzar la seguridad del código abierto, se ha visto obligado a cerrar. No porque funcione mal, sino porque funciona demasiado bien como objetivo para las herramientas automatizadas.
Desde el 1 de octubre el programa está cerrado y, según la propia Google, no se reanudará hasta el primer trimestre de 2027, en el mejor de los casos. La causa es inequívoca: un aumento explosivo de envíos automatizados, de los cuales la gran mayoría carece de validez.
Según el sitio de tecnología Tom's Hardware, citado por TechCrunch, los ingenieros y los mantenedores de código abierto de Google se han visto completamente desbordados. Los informes que llegan contienen hallazgos no válidos o errores puros: alucinaciones, es decir, información inventada que los sistemas de IA presentan con seguridad como si fuera un hecho.
Una advertencia anunciada que se cumplió
Lo que hace la situación especialmente frustrante es que no llegó sin aviso. TechCrunch informó ya el año pasado de que los expertos en seguridad advertían sobre exactamente este escenario: que las herramientas de IA de fácil acceso atraerían una oleada de envíos generados de forma descuidada u oportunista, que acabarían asfixiando los programas.
Entonces era un riesgo hipotético. Ahora es una interrupción real.
Como desarrollador de sistemas, reconozco el patrón de muchos otros ámbitos. Cuando un sistema ofrece una recompensa, económica o de reputación, y el umbral para participar se reduce drásticamente, toda la dinámica cambia. Los programas de vulnerabilidades se basan en un contrato tácito: tú dedicas tiempo y competencia considerables, nosotros revisamos con seriedad y pagamos si el hallazgo se sostiene. Cuando las herramientas de IA permiten generar cientos de informes en una fracción del tiempo que antes se necesitaba, ese contrato se derrumba.
El resultado no es que se encuentren más fallos de seguridad, sino que quienes buscan de forma seria se ahogan en el ruido.
El problema de la señal en la seguridad
La teoría de la información tiene un concepto clásico: la relación señal-ruido. Cuanto más ruido hay, más difícil resulta distinguir la señal. En el ámbito de la seguridad, las consecuencias no son abstractas: cada hora que un ingeniero dedica a revisar un informe de IA no válido es una hora que no se dedica a vulnerabilidades reales.
Es una cuestión de asignación de recursos que rápidamente se convierte en una cuestión de seguridad. El código abierto es la columna vertebral de la infraestructura digital moderna. Las bibliotecas, los marcos de trabajo y las herramientas que se utilizan en millones de sistemas de todo el mundo suelen ser mantenidos por pequeños grupos que trabajan con recursos limitados. Que estos grupos corran ahora el riesgo de ver paralizados sus procesos de revisión por basura generada con IA es grave.
Y es importante subrayarlo: el problema no es la IA en sí. Las herramientas de IA pueden y deben usarse en el trabajo de seguridad, para analizar código, detectar patrones y priorizar revisiones. El verdadero problema es el uso descalibrado, sin juicio humano y sin incentivos para mantener una alta calidad.
¿Qué pasa ahora?
Google promete volver con un programa reformulado. Cabe suponer que incluirá requisitos más estrictos para los envíos, quizá umbrales técnicos, exigencias de pasos de reproducción o una revisión humana previa antes de que un informe siquiera se registre en el sistema.
Es el camino correcto. Pero pone de manifiesto un reto más amplio que toda la industria de la seguridad debe afrontar: ¿cómo diseñamos sistemas y estructuras de incentivos que sean robustos frente al abuso automatizado sin excluir a los colaboradores legítimos?
No es una pregunta sencilla. Pero es urgente.