Se la mia applicazione utilizza JRE 1.8.0_6 , che ha attualmente 3 CVE riportati, tutti i CVE degli aggiornamenti successivi riassumono fino a 216 e 34 CVE riportati in JRE 1.8.0
Non è possibile determinare il numero di CVE rilevanti basandosi solo sui numeri che mostri. Ad esempio, un CVE mostrato per Java 8u131 potrebbe essere stato introdotto di recente in Java 8u130 o potrebbe già essere stato in agguato nel codice da Java6. Pertanto, al fine di ottenere quale CVE è rilevante per la tua versione Java, devi esaminare i dettagli di tutti i CVE successivi e cercare le versioni che applicano. Se si applicano già per Java 7, la probabilità è alta che il bug si trovi anche nella vecchia versione di Java 8 che usi.
A parte questo: a chi importa del numero esatto (e solo del numero). Rilevante per valutare il rischio che si ha quando si utilizza una vecchia versione di Java non è il numero totale di CVE ma quali di questi hanno effettivamente effetto sull'applicazione, quanto sono pessimi e come possono essere mitigati.
Oracle ha usato per capire quali versioni delle vulnerabilità di Java sono state introdotte, tuttavia con Java 8 Oracle afferma solo che una vulnerabilità è nell'ultima versione di un ramo (Java 6, 7 o 8). La cosa sicura da fare (e ciò che istruisco i nostri team) è di supporre che ogni vulnerabilità sia presente in tutte le precedenti versioni di Java. Non sarà sempre vero, ma è la cosa più sicura da assumere.
Steffan ha ragione a voler capire se una vulnerabilità è sfruttabile o meno (ovvero una valutazione della vulnerabilità). Sfortunatamente, quando Oracle ha apportato la modifica sopra riportata, hanno reso le loro descrizioni sulla vulnerabilità molto più vaghe. Ad esempio, la descrizione per CVE-2017-10116 (che è stata fissata nel Quarterly Critical di luglio Aggiornamento patch) afferma "Difficile sfruttare la vulnerabilità consente a malintenzionati non autenticati l'accesso alla rete tramite protocolli multipli per compromettere Java SE, Java SE Embedded, JRockit. Gli attacchi di successo richiedono l'interazione umana da una persona diversa dall'attaccante e mentre la vulnerabilità è in Java SE. .. "Con quella descrizione dovresti dare per scontato che qualsiasi protocollo sia vulnerabile. Puoi trovare spesso descrizioni migliori sul sito di Red Hat. Vai al link CVE e poi fai clic sul link Bugzilla e ottieni un risultato molto più utile descrizione del problema: "È stato scoperto che la classe LDAPCertStore nel componente Security di OpenJDK ha seguito i riferimenti LDAP a URL arbitrari: un URL di riferimento LDAP appositamente predisposto potrebbe causare a LDAPCertStore di comunicare con server non LDAP." Red Hat non avrà sempre un Bugzilla e se lo fanno occasionalmente sarà limitato, ma di solito ti dà molte più informazioni.