最近，我正在研究仍在使用的特定版本的JRE（1.8.0_151）的常见漏洞，并偶然发现了cvedetails.com。结果非常令人困惑，因为该特定版本似乎根本没有已知的CVE。至少，页面未列出此版本。但是，该页面列出了所有较新JRE版本的结果。这可能导致（可能是错误的）假设，即随着以下较新的JRE版本的发布，版本8.0_151更安全，并且不需要进行更新。List of all CVEs for JRE on cvedetails.com
有人知道为什么未列出特定版本，或者它可能与152版本一起算吗？
此外，对于JRE各自的安全性，您推荐的更新策略方法是什么。有没有最佳做法？我知道，在测试与所使用的应用程序的兼容性方面进行投资是时间和金钱的问题，但是除此之外，了解与JRE保持最新的最佳理由将是非常高兴的。
非常感谢！
您应该假定该漏洞不仅存在于指定的更新中，而且还存在于给定JRE版本的所有先前更新中。因此，如果警报发出1.8.0_151的提示，则应假定此问题存在于1.8.0 _ 等于或小于151的任何东西。
这不仅是因为谨慎行事更好。因为这几乎总是情况的实际情况。
出于某些原因，CVEDetails摘要页面不完整，因此没有列出每个受影响的更新。首先是甲骨文在2014年更改了其CVE通知的格式。早期的格式如下：
这清楚表明该漏洞仅在1.7.0_40、1.6.0_60和嵌入式1.7.0_40中不存在。该漏洞存在于较早更新中的事实对于几乎每个漏洞（不仅在Java中而且在任何软件中）都是正确的。唯一的例外不是在更新中引入了漏洞，幸好这很少见。
Oracle的较新格式是这样的：
在先前的更新中不再对存在的问题发表任何声明。 Oracle可能会说他们这样做是因为不再支持早期的更新，因此甚至没有必要调查它们是否容易受到攻击。
事实上，Oracle的当前格式明确表明了这一立场：
仅指定当前支持的版本受影响。但是这个问题也存在于较早的更新中的可能性非常大。
第二个问题是，即使原始警报格式指定为“更新NNN和更早版本”，“更早”部分也不会反映在CVEDetails摘要中。例如，JRE 1.7.0的CVEDetails摘要未显示1.7.0_39，1.7.0_38，1.7.0_37等的漏洞，即使这些漏洞均受原始示例中的“ 7u40及更早版本”问题影响，我上面显示的警报格式。
此外，您推荐的更新策略是JRE各自安全性的方法。有没有最佳做法？
观点各不相同，并且对于StackOverflow来说，观点是偏离主题的。但是IMO，每当有新更新发布时（即使没有安全修复程序），您都应该针对新的JRE重新验证您的应用程序，这样您就可以提前知道客户应用该JRE更新是否会遇到麻烦。如果存在不兼容性，则应尽快解决。
如果漏洞很严重并且可以在您的应用程序中利用，那么您应该让客户知道他们应该应用JRE更新，如果在重新验证时发现不兼容，则可能是在他们首次安装了新的应用程序更新之后。如果该漏洞是轻微的和/或无法在您的应用程序中利用，则应该让您的客户知道这一点，让他们知道JRE更新是否需要应用程序更新，然后让他们决定是否移至更新的JRE。