La investigación de vulnerabilidades asistida por IA ha experimentado un auge espectacular, generando una avalancha de informes de baja calidad sobre los responsables del mantenimiento de software, sobrecargados de trabajo, que pierden horas filtrando información irrelevante en lugar de solucionar problemas reales.
Linus Torvalds, el creador del núcleo de Linux, afirma que la avalancha de mensajes ha hecho que la lista de correo de seguridad del proyecto sea «prácticamente inmanejable, con una enorme duplicación debido a que diferentes personas encuentran las mismas cosas con las mismas herramientas».
Demasiados duplicados y demasiadas chapuzas de IA.
“Si encontraste un error usando herramientas de IA, lo más probable es que alguien más también lo haya encontrado”, escribió Torvalds en la nota que acompañaba a la última versión candidata del kernel de Linux.
“Si de verdad quieres aportar valor, lee la documentación, crea también un parche y añade valor real *además* del que ya proporciona la IA. No seas de los que envían informes al azar sin entender realmente nada.”
Jarom Brown, ingeniero sénior de seguridad de productos en GitHub, reconoció la semana pasada que, si bien la reducción de las barreras de entrada para la investigación en seguridad mediante la IA es un avance positivo, su equipo está recibiendo una avalancha de propuestas que no demuestran ningún impacto real en la seguridad.
Esto incluye informes sin prueba de concepto, escenarios de ataque teóricos que no resisten un análisis minucioso y hallazgos que ya están cubiertos por la lista de elementos no elegibles publicada por GitHub.
Y GitHub no es el único receptor de este aluvión indeseado.
“Los programas de toda la industria se enfrentan al mismo desafío, y algunos han cerrado definitivamente ”, dijo.
GitHub no ha llegado a tomar una medida tan drástica, pero ahora exige a quienes envían sus contribuciones que validen los resultados obtenidos con la ayuda de la IA antes de enviarlos.
En adelante, una solicitud completa también deberá incluir una prueba de concepto funcional que demuestre el potencial de explotación y el impacto concreto en la seguridad.
Además, los informes que abarquen categorías conocidas como no elegibles se cerrarán como No aplicable, lo que puede afectar la puntuación y la reputación del remitente en HackerOne, agregó.
Finalmente, Brown instó a los investigadores a ser concisos: los informes extensos y manipulados mediante inteligencia artificial ralentizan la clasificación de los pacientes y hacen perder el tiempo a todos.
La opinión del investigador
Los daños colaterales van más allá de los propios programas. Shubham Shah, cofundador de Assetnote y un respetado investigador de seguridad, afirma que las organizaciones ahora tardan mucho más en revisar informes legítimos y actuar ante fallos reales, lo que está acabando con el ciclo de retroalimentación que mantiene a los mejores investigadores comprometidos.
Si bien las plataformas de recompensas por la detección de errores como HackerOne y Bugcrowd están tratando de combatir la avalancha de informes de spam creados por IA con IA y controles adicionales, él dice que «la alegría de informar sobre vulnerabilidades a las plataformas de recompensas por la detección de errores se está disipando rápidamente», y no solo para él.
“Espero que las plataformas solucionen esto, pero hasta entonces, no me veo continuando informando sobre investigaciones originales de alta calidad a ciertos programas en los que he contribuido significativamente durante una década, cuando no logran comprender la diferencia entre yo y un investigador que no tiene ninguna credibilidad”, agregó.
A corto plazo, algunos investigadores experimentados podrían dedicarse a la investigación privada sobre vulnerabilidades y a programas de recompensas solo por invitación.
El software abierto es quien soporta la peor parte.
La “industrialización” del descubrimiento de vulnerabilidades impulsada por la IA representa actualmente un problema mucho mayor para los proyectos de código abierto que para grandes organizaciones como Microsoft o Google, ya que dependen de mantenedores voluntarios, cuyo número y tiempo son limitados.
Estas limitaciones han llevado, por ejemplo, al proyecto cURL a dejar de aceptar envíos de HackerOne y a eliminar las recompensas monetarias por los informes de seguridad.
El desarrollador principal de CURL, Daniel Stenberg, esperaba que esta última decisión eliminara el incentivo para enviar software de IA de baja calidad, y afirmó que creía que «los mejores y más valiosos informadores de seguridad seguirán avisándonos cuando encuentren vulnerabilidades de seguridad».
El proyecto optó por recibir informes a través de GitHub o correo electrónico, pero un mes después volvió a usar HackerOne, ya que estas dos vías resultaron menos efectivas de lo esperado para reportar vulnerabilidades. Sin embargo, el proyecto decidió mantener su decisión de no ofrecer recompensas por los informes de errores.
“Desde ese día, la naturaleza de los informes de seguridad presentados ha cambiado. El problema de la basura ya no existe”, señaló Stenberg en abril.
El número de informes aumentó, su calidad mejoró (incluso si se elaboraron con la ayuda de la IA) y la tasa de vulnerabilidades confirmadas superó el nivel anterior a la IA de 2024.
Si bien este cambio fue bienvenido, Stenberg cree que el aumento en la cantidad de informes de vulnerabilidades «buenas» planteará un problema diferente para los proyectos de código abierto. «Esta avalancha agravará aún más la sobrecarga de trabajo de los mantenedores. Algunos proyectos tendrán dificultades para gestionar este incremento en la lista de tareas pendientes sin la ayuda de más mantenedores», señaló.
Tras la desaparición y el regreso de cURL, HackerOne reconoció el problema que la ineficiencia de la IA puede representar para las organizaciones con recursos limitados y aconsejó a sus clientes que perfeccionaran el alcance y las directrices de envío para reducir el ruido, utilizaran herramientas de clasificación asistidas por IA y combinaran esa automatización con la supervisión humana.
«A medida que la IA facilita la automatización de los envíos, preservar la calidad de la señal se vuelve fundamental para que los responsables del mantenimiento del código abierto puedan centrarse en solucionar problemas reales», declaró Michiel Prins, cofundador y director sénior de gestión de productos de HackerOne, a Help Net Security.
“Nuestro objetivo es ayudar a los programas a gestionar ese cambio con flujos de trabajo que filtren el ruido de forma temprana, identifiquen informes fiables y mantengan una gestión de vulnerabilidades sostenible, para que las comunidades de código abierto puedan mantener la transparencia y la resiliencia que las caracterizan”.
El Grupo de Trabajo sobre Divulgación de Vulnerabilidades de la Open Source Security Foundation también busca la opinión de la comunidad para ayudar a los responsables del mantenimiento de software de código abierto a abordar los informes basura generados por IA. Sus objetivos incluyen recopilar las mejores prácticas, crear plantillas de políticas y desarrollar guías para ayudar a los responsables del mantenimiento a detectar y gestionar los informes generados con ayuda de IA.
ACTUALIZACIÓN (19 de mayo de 2026, 06:55 am ET):
Este artículo se ha actualizado para reflejar otro cambio en el programa de recompensas por la detección de errores del proyecto cURL, que tuvo lugar en febrero de 2026.
El artículo original afirmaba que el programa se había trasladado de HackerOne a GitHub, pero desconocíamos que cURL hubiera regresado a HackerOne desde entonces.
El artículo también se ha actualizado para incluir hallazgos adicionales que surgieron como resultado de este cambio y la eliminación de las recompensas por los informes de vulnerabilidades.
Fuente y redacción: helpnetsecurity.com/Zeljka Zorz
