Por qué los informes de vulnerabilidad ya no son « especiales »: el problema de las falsas alarmas en el ecosistema del bug bounty

Filippo Valsorda, antiguo responsable de seguridad del lenguaje de programación Go y ahora investigador independiente, resumió el lunes en una entrada de blog un problema fundamental del ecosistema moderno del bug bounty: los informes de vulnerabilidades ya no son « especiales » y la situación se ha convertido en un reto serio para los responsables de proyectos de código abierto. El artículo se debatió en la cima de Hacker News a lo largo del día.

El argumento de Valsorda es sencillo: en la década de 2010, un informe de vulnerabilidad era un evento relativamente raro y llamativo para el equipo de un proyecto. Solía ser un correo electrónico de un investigador experimentado lleno de pruebas detalladas y recomendaciones. En 2026, en un entorno con escáneres automatizados y con informes generados por IA, esa estructura ha cambiado.

La principal tesis del artículo es que, a medida que el volumen de informes ha aumentado, la relación señal/ruido ha caído. Valsorda afirma que un responsable de código abierto puede recibir docenas de informes « he encontrado algo » por semana, pero la inmensa mayoría son falsos positivos (no hay problema), están mal descritos (faltan pruebas) o son duplicados de cuestiones ya conocidas.

El texto resume un punto que Valsorda subraya especialmente: « Los programas de bug bounty se diseñaron como herramienta para reducir la superficie de ataque; pero para los responsables se han convertido en un sistema de gestión de spam ». El artículo sugiere que esto está acelerando el agotamiento entre los responsables voluntarios de software libre.

Valsorda explicó que el problema tiene varias fuentes. La primera: informes generados por IA. Tanto los grandes modelos de lenguaje (LLM) como las herramientas automatizadas de análisis estático producen informes de hallazgos que no son reales o que se exageran. La segunda: los incentivos de las plataformas de bug bounty (HackerOne, Bugcrowd) tienden a recompensar la cantidad de informes.

El artículo destaca que el ecosistema de código abierto (proyectos como el núcleo Linux, OpenSSL, FFmpeg) es el segmento más afectado por esta dinámica. Los responsables de estos proyectos no tienen los recursos humanos para seguir el ritmo de los cambios en el ecosistema de informes. Los procesos de asignación de CVE, dependientes de la capacidad limitada de MITRE, ya están demorados.

El equipo Project Zero de Google planteó un mensaje similar en una entrada de blog el año pasado: « los escaneos automatizados no son una señal significativa para nosotros, y la mayoría de las veces son ruido ». Project Zero solo acepta hallazgos verificados con trabajo manual en sus propias investigaciones.

En el centro de las soluciones propuestas por Valsorda está un rediseño del proceso de notificación. Sus sugerencias incluyen: (1) una capa de verificación automatizada que establezca un orden de prioridad, (2) una distribución más amplia de la autoridad para asignar CVE, (3) la reestructuración de los sistemas de recompensa del bug bounty para favorecer a proveedores recurrentes de pruebas de calidad en lugar de a informes únicos, y (4) una clasificación separada para los informes generados por IA.

El director de GitHub Security Lab, Bas Alberts, se sumó a la discusión en Hacker News con un comentario: « El argumento de Valsorda concuerda con lo que vemos en GitHub. Los informes generados por IA requieren una validación mucho más estricta para alcanzar un umbral de calidad aceptable ». Alberts añadió que GitHub renovará su estructura de validación de informes este mismo año.

El artículo de Valsorda forma parte de un debate sectorial más amplio: ¿cómo deberían reequilibrarse los incentivos económicos de la investigación en seguridad? Si las recompensas premian la cantidad de informes, el sector generará ruido de forma natural. Hace falta un rediseño o, como también señala Valsorda, un nuevo marco financiero para la protección del ecosistema de código abierto.