Via Slashdot. Un lector anónimo compartido del presente informe Es FOSS:

Jenny Guanni Qu, investigadora de [Fondo VC] Pebblebed, analizado 125.183 errores de 20 años de historia de desarrollo del kernel de Linux (en Git). Los hallazgos muestran que el error promedio tarda 2.1 años en encontrar. [Aunque la mediana es de 0,7 años, con el promedio posiblemente segado por "outliers" descubierto después de años de ocultación.] El bicho más largo, un buffer que se desbordó en código de red, fue sin darse cuenta durante 20,7 años! [Pero el 86,5% de los bichos se encuentran dentro de cinco años.]

La investigación se llevó a cabo confiando en los Fixes: etiqueta que se utiliza en el desarrollo del kernel. Básicamente, cuando un commit arregla un error, incluye una etiqueta apuntando al commit que introdujo el error. Jenny escribió una herramienta que extrajo estas etiquetas de la historia de la git del kernel de volver a 2005. La herramienta encuentra todos los commits de fijación, extrae el hash de compromiso referenciado, tira las fechas de ambos commits, y calcula el marco de tiempo. En cuanto al conjunto de datos, incluye más de 125k registros desde Linux 6.19-rc3, cubriendo bichos de abril de 2005 a enero de 2026. De ellos, 119.449 fueron únicos compromisos de fijación de 9.159 autores diferentes, y sólo 158 fallos tenían ID de CVE asignados.

Tomó seis horas para reunir el conjunto de datos, según el blog post, que concluye que el porcentaje de errores encontrados dentro de un año ha mejorado dramáticamente, de 0% en 2010 a 69% en 2022. El blog dice que esto puede atribuirse probablemente a:

• El fuzzer Syzkaller (publicado en 2015)
• Detectores dinámicos de errores de memoria como KASAN, KMSAN, KCSAN
• Mejor análisis estático
• Más contribuyentes revisando el código

Pero "estamos capturando simultáneamente nuevos errores más rápidos y lentamente trabajando a través de ~5,400 errores antiguos que han estado escondidos durante más de 5 años".

También han desarrollado un modelo de AI llamado VulnBERT que predice si un compromiso introduce una vulnerabilidad, alegando que de todos los compromisos de introducción de errores reales, alcanza el 92,2%. "El objetivo no es reemplazar a los revisores humanos, sino señalarlos al 10% de los compromisos más probable que sean problemáticos, para que puedan enfocar la atención donde importa..."