La lista de seguridad Linux del kernel se ha vuelto «casi totalmente inmanejable», según Linus Torvalds, tras un aluvión de reportes duplicados originados por investigadores que ejecutan las mismas herramientas de IA contra el mismo código.
La queja de Torvalds llegó en su nota semanal al LKML acompañando la publicación de Linux 7.1-rc4 y la incorporación de nueva documentación que formaliza cómo deben tramitarse los bugs encontrados con ayuda de IA.
Por qué la lista de seguridad Linux se quedó obsoleta
El problema no es tanto la calidad de los hallazgos como el volumen y la redundancia. Varios investigadores, usando herramientas automáticas similares, están encontrando los mismos fallos y enviando informes por separado a una lista privada en la que nadie puede ver lo ya reportado.
El resultado: mantenedores ocupados en filtrar duplicados y en redirigir a reporteros hacia soluciones que, en algunos casos, se habían fusionado semanas antes.
Willy Tarreau, creador de HAProxy y mantenedor estable del kernel, resumía el cambio en cifras: hace dos años la lista recibía unas dos o tres notificaciones semanales; hoy son de cinco a diez al día. Muchos hallazgos son válidos, pero la duplicidad está saturando el proceso de triage.
Qué pide el proyecto y cómo deben enviarse los bugs
La nueva documentación del proyecto establece que las vulnerabilidades detectadas por IA deben tratarse como divulgaciones públicas. Es decir, deben enviarse directamente a los mantenedores relevantes y no pasar por la lista privada de seguridad.
Los informes deben ser concisos, en texto plano y contener un reproducer verificado. Torvalds insiste en que los envíos no pueden limitarse a una captura generada por la herramienta: «Si quieres aportar valor, crea también un parche y añade algo real sobre lo que hizo la IA», escribió.
Ese enfoque ya lo practica Greg Kroah-Hartman con su sistema «Clanker T1000»: identificar el problema, escribir la corrección, responsabilizarse del parche y publicarlo de forma abierta.
Además, la política del kernel sobre contribuciones asistidas por IA, aprobada recientemente, permite código generado por IA solo si se siguen reglas estrictas de transparencia. Entre ellas está la prohibición de usar el tag legalmente vinculante Signed-off-by en contenido generado por máquinas; en su lugar existe la etiqueta Assisted-by para dejar claro qué parte fue asistida por IA.
El proyecto recuerda que, aunque la IA ayude a generar código o parches, la responsabilidad legal recae en la persona que somete el cambio.
Torvalds critica también el perfil del colaborador que envía «reportes al vuelo» sin entender el fallo ni aportar contexto. Para él, la comunidad gana cuando el investigador va más allá del hallazgo bruto: leer la documentación, preparar un parche y explicar el impacto concreto.
En la práctica, esto significa que la gestión de seguridad del kernel se orienta hacia la transparencia pública y hacia contribuciones con responsabilidad técnica y legal clara.
Lo que el proyecto no aclara todavía es cómo se escalará la carga de trabajo si el número absoluto de reportes sigue creciendo, aunque sean no duplicados. La solución aplicada reduce las fricciones por duplicados, pero deja sobre la mesa la necesidad de más herramientas de automatización y de procesos que prioricen los hallazgos por impacto real.
Para quienes trabajan con análisis estático o fuzzers generados por IA, la nueva norma es clara: aporta un reproducible, prepara una corrección si puedes y publica en abierto. No firmes legalmente lo que no puedes justificar, y usa la etiqueta Assisted-by cuando proceda.
La reacción de la comunidad refleja una mezcla de alivio y trabajo pendiente: alivio porque la visibilidad pública evita triages ciegos; trabajo pendiente porque es necesario mejorar procesos y coordinación entre investigadores para que la política funcione sin añadir ruido.
