Maven允许开发人员将他们的工件依赖于10年前的古代工件（例如2005年发布的commons-el：commons-el：1.0，或者2007年发布的jetty：javax.servlet：5.1.11）。 java生态系统中的常见做法是依赖于特定的旧版本工件，因为它们的更新通常会默默地破坏API。
如果发现安全漏洞，是否修补了这些旧工件？谁会照顾这个？
如果我进入，请说最新版本的spark org.apache.spark：spark-core_2.11：2.0.0，在maven下载其依赖关系的3GiB后，我甚至可以看到其中几个如果产生的火花被执行，那些过时的依赖性是否会暴露出必要的安全漏洞？
注意：这既不是security of java本身也不是security of maven，而是由maven提供的工件。
答案 0 :(得分：2)
Maven的中央存储库requirements不会谈及传递依赖安全问题。
更新传递依赖关系的责任依赖于依赖关系的所有者。依赖项的所有者/维护者需要在更新其依赖项（具有安全漏洞的依赖项）时对其代码库中引起的问题实施任何修复。
作为应用程序中可能具有不安全传递依赖关系的依赖项的用户，您有以下几种选择：
另外，如果您想要详细报告java应用程序中依赖项的安全性，可以查看OWASP Dependency Checker，它会针对NIST NVD数据库检查项目的依赖关系（包括传递）。
答案 1 :(得分：1)
如果在特定包中发现安全漏洞，则期望作者发布新的补丁版本。对于您的观点，较旧的易受攻击的版本仍然存在于Maven Central中，乍一看这似乎是一件非常糟糕的事情。
它导致了以下明显的问题：
让我们探讨后果......
如果有人正在更改我正在使用的库版本，那么代码保持功能的相同程度如何呢？这就是补丁作为新版本处理的原因。这对作者的工作要少得多。
因此，如果旧的易受攻击的版本没有被修补，那么它们肯定会被删除吗？嗯......如果用户不想使用最新的修补版本的库，因为担心它会破坏他们的代码，如果有人删除了他们依赖的库版本，他们肯定会同样不高兴。如果你这样做，该死的，如果你不这样做，该死的......
总而言之，这是一个用户提防的案例。我们都需要管理依赖项并适应各种底层API的变化。如果我们忽略变更，我们就会面临无法升级的风险。欢迎使用软件开发： - ）