¿Cuenta CVE un buen indicador de la seguridad de un software?

  

¿Podemos decir que un software es "más seguro" que otro, según la cantidad de CVE que tienen estos programas?

No. Las entradas de CVE no son una buena fuente para clasificar los productos por su "seguridad general".

La idea principal detrás del sistema CVE es crear identificadores únicos para las vulnerabilidades de software. No está diseñado para ser una base de datos completa y verificada de todas las vulnerabilidades conocidas en ningún producto. Es decir, un proveedor o investigador podría simplemente decidir no solicitar un número CVE para un defecto determinado. Además, las entradas a veces combinan errores relacionados bajo una sola ID o no revele la información exacta impacto, haciendo que un simple "recuento de errores" sea un criterio de seguridad sin sentido. Además, para una clasificación tendría que encontrar métricas razonables para comparar diferentes severidades. (¿Cuántos errores DoS equivalen a una ejecución remota de código ...?)

Dicho esto, las CVE sí te dan una idea sobre qué tipo de vulnerabilidades se han encontrado en un producto y son un buen punto de partida para la investigación. Pero la cantidad depende en gran medida de la antigüedad del software y de cuánta atención reciba a través de la auditoría de seguridad. Realmente no puede razonar si una gran cantidad de asignaciones de CVE significa que el software está mal escrito o si realmente significa que es particularmente seguro porque, evidentemente, muchas vulnerabilidades se están arreglando. Personalmente tiendo a encontrarlo sospechoso si un producto anterior tiene un historial muy corto de vulnerabilidades parcheadas porque podría indicar que no se ha auditado a fondo.

Así que debes pensar en CVE como un diccionario en lugar de una base de datos que simplemente asigna manejadores de vulnerabilidades para que puedas puede hacer referencia a ellos más fácilmente, no lo use como una herramienta para comparar la seguridad.

Aquí hay algunos mejores indicadores para un producto seguro:

• El software se utiliza y se desarrolla activamente.
• El proveedor alienta a las personas a buscar vulnerabilidades (y quizás incluso ofrezca recompensas).
• Los nuevos errores de seguridad se procesan y parchean rápidamente.

Como sistema voluntario, CVE está tan abierto al abuso como los productos de software que rastrea y, a menudo, es altamente subjetivo. Esto se ve agravado por el mecanismo de puntuación que se usa para rastrear la gravedad, que normalmente es CVSSv2.

En un mundo ideal, cuando se descubre una vulnerabilidad en un producto, los desarrolladores registrarán un CVE, y luego lo publicarán junto con la solución que produjeron para su producto.

Sin embargo, como han señalado otros, a veces los CVE simplemente no se crean o los desarrolladores tomarán un montón de vulnerabilidades, eliminarán una versión que los solucione a todos y crearán en el CVE que lo acompaña.

Si estoy interesado en usar un determinado producto de software y tengo reservas respecto a su seguridad, es más probable que analice cómo manejan los problemas de seguridad, reciben informes, etc. que si miran específicamente su base de datos de CVE. / p>

Una excepción a lo anterior son los productos de software que usan otros componentes, en estos casos, ver cuánto tiempo le tomó a un producto ponerse al día con los CVE que se emitieron en contra de los productos / servicios que lo componen puede ser esclarecedor. El software comercial que vuelve a empaquetar los componentes de código abierto a menudo puede retrasarse muchos meses en las correcciones de seguridad. Esta es probablemente la cosa más útil para la que hago uso de la base de datos CVE.

CVE solo representa los errores en las aplicaciones que las personas intentan explotar activamente. Si bien el código abierto puede o no estar sujeto a un mayor o menor volumen de CVE, podría suponerse razonablemente que no implica que ninguna aplicación sea más o menos propensa a la explotación. Considere que muchas de las vulnerabilidades / vulnerabilidades se venden a menudo como 0 días incluso antes de ser consideradas como una entrada CVE. También considere que muchas personas en la comunidad de código abierto tienden más a la divulgación razonable que a la ganancia. En cualquier caso, mediría la vulnerabilidad de dos aplicaciones basadas en un par de métricas:

1. ¿Qué tan graves son los impactos de las hazañas del pasado?

2. Volumen de CVE: Como usted indicó, más CVE probablemente implica que la investigación de seguridad audita la aplicación con más frecuencia.

3. Código abierto: personalmente considero que el código abierto es 'generalmente' más seguro. Vea el código fuente por sí mismo y observe el estilo de codificación. Tal vez usted puede encontrar una vulnerabilidad a ti mismo.

Quizás un poco, pero la relación entre conteos y calidad es compleja, si es que tiene sentido. Las preguntas útiles que se deben hacer con respecto a los recuentos de CVE y sus implicaciones acerca de la calidad / seguridad de un software son:

• ¿Tiene algún CVE? Si no, eso probablemente significa que a nadie le importa lo suficiente como para buscar errores de seguridad (es decir, poca relevancia, no alta calidad).

• ¿Se han repetido CVE para los mismos tipos de errores año tras año? Si es así, eso significa que los desarrolladores / mantenedores probablemente están haciendo a lo sumo el mínimo necesario para corregir un error específico en lugar de corregir su base de código en su totalidad y corregir los procesos que llevaron al error.

• ¿Se encuentran las CVE comparables a las CVE para otros programas similares en los mismos años, y son incluso razonables para los años en que se encuentran? Por ejemplo, para la mayoría de los lenguajes utilizados para aplicaciones web, la existencia de cualquier error de inyección SQL indica que se están utilizando API / frameworks completamente incorrectos / hacia atrás (es decir, los antiguos sin declaraciones preparadas). Para los programas de C, aunque esto es mucho más difícil de juzgar; Es poco probable que los resúmenes de CVE le digan si un error fue sutil (y, por lo tanto, "razonable" para aparecer) o si se produjo algo idiota y contrario a las prácticas modernas.

Y así sucesivamente. La mayoría de estas preguntas dependen de algo más que un simple conteo (aunque algunas podrían ser modeladas como "conteos en varias clases"), por lo que soy escéptico de que los conteos tienen mucho valor.