Cuando se compara el número de CVE (vulnerabilidades de seguridad) reportados en software escrito en Rust frente a los escritos en C o C++, la comparación resulta engañosa, ya que la forma de catalogar las vulnerabilidades de memoria difiere sustancialmente entre ambos ecosistemas.
En C y C++, el sistema de tipos es demasiado limitado para expresar con precisión los contratos de las funciones, y los autores de bibliotecas suelen no documentar todos los usos incorrectos posibles. Esto provoca que situaciones como pasar un puntero NULL a una función —algo tan simple como un programa de cinco líneas— generen fallos de segmentación y, por tanto, vulnerabilidades potenciales. Sin embargo, la comunidad no las reporta como CVE de la biblioteca, sino como uso indebido por parte del desarrollador, porque, en caso contrario, cualquier biblioteca quedaría inundada de millones de avisos.
En Rust, en cambio, la situación es radicalmente distinta. Si una biblioteca expone una API que puede causar un fallo de memoria sin que el usuario emplee bloques unsafe, se considera automáticamente un defecto de soundness en la biblioteca, y se le asigna un CVE, aunque aún no exista un programa real que lo desencadene. Esto hace que algunos CVE de Rust parezcan más estrictos que los de C/C++.
El artículo ilustra la diferencia con la biblioteca C libcurl, que segfaulta al recibir un argumento NULL en curl_getenv sin que ello se catalogue como vulnerabilidad de la biblioteca, y contrasta ese caso con el equivalente en una biblioteca Rust como hyper, donde el mismo escenario se trataría como un bug de soundness. En definitiva, el texto argumenta que el número bruto de CVE no es un indicador fiable de la seguridad relativa de un lenguaje frente a otro.