Maven 允许开发人员让他们的 Artifact 依赖于长达 10 年的古老 Artifact (例如 2005 年发布的 commons-el:commons-el:1.0 或 2007 年发布的 jetty:javax.servlet:5.1.11)。在 Java 生态系统中，依赖特定的旧版本 Artifact 似乎是一种常见的做法，因为它们的更新经常会默默地破坏 API。
如果发现安全漏洞，这些旧 Artifact 是否会得到修补？谁来处理这个问题？
如果我拉进来，请说最新版本的 spark org.apache.spark:spark-core_2.11:2.0.0，在maven下载了3GiB的依赖项后，我可以看到其中一些甚至早于2005年。如果执行生成的spark，那些过时的依赖项是否会暴露专利安全性有缺陷吗？
注意:这与 security of java 无关本身，也不security of maven ，但是由 maven 交付的 Artifact 。
最佳答案
Maven 的中央存储库 requirements不要谈论传递依赖安全问题。
更新传递依赖项的责任取决于依赖项的所有者。依赖项的所有者/维护者需要在更新其依赖项(存在安全缺陷的依赖项)时对其代码库中引起的问题进行修复。
作为应用程序中可能具有不安全传递依赖项的依赖项的用户，您有几个选择:
- 更新到最新版本的依赖项，依赖项所有者可能已经实现了修复。
- 排除不安全的传递依赖项。使用风险自负，因为这可能会产生意想不到的影响。通常这确实有效，因为不安全的依赖项实际上可能不会被您所需的依赖项使用。
- fork 依赖项代码库、更新不安全的传递依赖项、修复任何问题并提交拉取请求。
此外，如果您想要有关 Java 应用程序中依赖项安全性的详细报告，您可以查看 OWASP Dependency Checker ，它根据 NIST NVD 数据库检查项目的依赖关系(包括传递性)。
关于java - 过时的 Maven Artifact 的安全性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39813093/