Si mi aplicación utiliza JRE 1.8.0_6 , que actualmente tiene 3 CVEs informados, todos los CVE de las actualizaciones posteriores suman 216, y 34 CVE informados en JRE 1.8.0 en general, ¿cuál es el número de vulnerabilidades a las que mi aplicación está potencialmente expuesta a 3, 3 + 34, 3 + 216 o 3 + 216 + 34, y por qué?
No es posible determinar el número de CVE relevante solo en función de los números que se muestran. Por ejemplo, un CVE que se muestra para Java 8u131 podría haberse introducido recientemente en Java 8u130 o podría haber estado escondido en el código desde Java6. Por lo tanto, para obtener qué CVE son relevantes para su versión de Java, debe examinar los detalles de todos los CVE posteriores y buscar las versiones que aplican. Si ya se aplican a Java 7, existe una gran probabilidad de que el error también se encuentre en la versión anterior de Java 8 que utiliza.
Aparte de eso: a quién le importa el número exacto (y solo el número). Relevante para evaluar el riesgo que tiene al usar una versión antigua de Java no es el número total de CVE, sino cuál de ellas afecta realmente a su aplicación, qué tan malas son y cómo pueden mitigarse.
Oracle solía descubrir en qué versiones de las vulnerabilidades de Java se introdujeron, sin embargo, con Java 8, Oracle solo dice que hay una vulnerabilidad en la última versión de una rama (Java 6, 7 u 8). Lo más seguro (y lo que yo instruyo a nuestros equipos) es asumir que cualquier vulnerabilidad está en todas las versiones anteriores de Java. No siempre será cierto, pero es lo más seguro de asumir.
Steffan tiene razón y quiere comprender si una vulnerabilidad es explotable o no (también conocida como evaluación de vulnerabilidad). Desafortunadamente, cuando Oracle realizó el cambio señalado anteriormente, también hicieron sus descripciones de vulnerabilidad mucho más vagas. Por ejemplo, la descripción de CVE-2017-10116 (que se corrigió en el informe crítico trimestral de julio La actualización del parche) indica que "Una vulnerabilidad difícil de explotar permite a un atacante no autenticado con acceso a la red a través de múltiples protocolos para comprometer Java SE, Java SE Embedded, JRockit. Los ataques exitosos requieren la interacción humana de una persona que no sea el atacante y mientras la vulnerabilidad está en Java SE. .. "Con esa descripción tendrías que asumir que cualquier protocolo es vulnerable. A menudo puede encontrar mejores descripciones en el sitio de Red Hat. Vaya al enlace CVE allí y luego haga clic en el enlace Bugzilla y obtendrá una información mucho más útil. descripción del problema: "Se descubrió que la clase LDAPCertStore en el componente de Seguridad de OpenJDK seguía las referencias de LDAP a direcciones URL arbitrarias. Una dirección URL de referencia de LDAP especialmente diseñada podría hacer que LDAPCertStore se comunique con servidores que no sean LDAP". Red Hat no siempre tendrá un Bugzilla y si lo tienen de vez en cuando estará restringido, pero por lo general le brinda mucha más información.