最近我正在研究我们仍在使用的特定 JRE (1.8.0_151) 版本的常见漏洞，并偶然发现了 cvedetails.com。结果相当混乱，因为对于这个特定版本似乎根本没有已知的 CVE。至少，该页面没有列出此版本。但是，该页面列出了所有较新 JRE 版本的结果。这可能导致（可能是错误的）假设版本 8.0_151 作为以下较新的 JRE 版本更安全，并且不需要更新。 List of all CVEs for JRE on cvedetails.com
有人知道为什么没有列出特定版本，或者它是否可能与版本 152 一起计算？
此外，对于 JRE 各自的安全性，您推荐的更新策略方法是什么。有没有最佳实践？我知道在测试与要使用的应用程序的兼容性方面进行投资是一个时间和金钱问题，但除此之外，了解与 JRE 保持同步的最佳理由会很棒。
非常感谢！
【问题讨论】：
标签： java security web-applications updates
您应该假设该漏洞不仅存在于指定的更新中，还存在于给定 JRE 版本的所有先前更新中。因此，如果警报调用 1.8.0_151，您应该假设问题存在于 1.8.0_anything-equal-to-or-less-than-151。
这不仅仅是因为最好谨慎行事。这是因为这几乎总是实际情况。
CVEDetails 摘要页面不完整的原因有几个，因为它没有列出每个受影响的更新。首先是甲骨文在 2014 年改变了其 CVE 通知的格式。早期的格式是这样的：
这清楚地表明该漏洞不仅存在于 1.7.0_40、1.6.0_60 和 Embedded 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。
【讨论】：