问题描述
在使用Maven包（Java语言）时，存在两个官方主要的Maven包仓库：
– Sonatype Inc. 提供的 search.maven.org
– 个人 @frodriguez 提供的 mvnrepository.com
目前已经有一个完整的存档以用于向后兼容的目的。然而，早在2013年Sonatype公司的CEO在一次采访中就提到，许多已知漏洞的组件被下载了很多次。很多人似乎并不关心这一问题。
那么，向后兼容性是否有这么大的价值呢？为什么不采取一些行动来减少风险呢？当然，现在已经有OWASP的依赖检查插件，但我认为从长远来看，实施更深层次的风险预防策略是可能的。
问题：有什么可行的方法可以激励Maven和仓库制造商建立一种早期警告机制，比如在下载时发布特殊的头信息，或者另外，例如默认情况下拒绝下载有漏洞的组件？我认为如果不要求地球上的每个构建都进行检查，这将节省大量时间和电力。
UPD：在2017年，超过80％的项目仍然没有意识到这些风险，尽管已经发生了法律诉讼。
解决方案
在下载来自互联网的“内容”时，不仅仅是Maven，还包括其他地方，如Docker Hub、Debian、Ubuntu等，如何提高安全性是一个非常重要的问题。对于Maven的开发者来说，对于这个问题可能有自己的想法，他们可能已经得出结论，将这个责任交给仓库并不是一个好主意，原因可能多种多样。通常情况下，在组件之间有明确的责任分工是IT领域中一个非常有力的概念，无论是在Unix命令行工具、面向对象的类设计还是服务器架构中都能找到。在这个特定情况下，我认为让Maven Central仅仅成为一个巨大的“储存库”是非常合理的。它的主要功能就是“在那里”，提供软件包。
实现在mvn和Maven Central之间放置一个安全过滤器是非常容易的。例如，我所在的公司运行着自己的一系列Nexus仓库；虽然开发人员在他们的笔记本电脑上可以做任何他们想做的事情，但自动化构建环境没有互联网访问权限，必须通过经过策划的Nexus仓库。每个项目都有自己的Nexus（用于不经常使用的包），它们链接到一个公司内部的全局Nexus。
然后，开发人员无法将软件包插入这些Nexus中，但专门的团队会审查新的软件包，并决定是否可以使用。
需要注意的是，这不仅限于安全性，还包括许可证问题。根据公司的政策，可能并不是每个开源许可证都是可接受的。因此，这也可以进行筛选。
另一个重要的原因可能是与安全无关的bug。假设你发现你的项目中有X个使用了软件包Y的项目，而发现Y包含严重的bug，可能会导致您的数据被破坏。Maven Central会从其仓库中删除该版本吗？当然不会！该bug可能只出现在非常小的边缘情况下，巧合的是这对您的公司可能非常重要。因此，通过在其中间加入自己的存储库结构，您可以将受影响的版本标记为“无效”，从而强制进行向下的bug修复。
最后，公司可能希望定期淘汰旧版本的软件包，仅仅为了跟上时代。使用这种“过滤”方法也有助于实现这一点。
回到Maven Central：他们为什么不这样做呢？这个问题不仅仅是技术问题，还涉及组织问题。谁决定什么是安全漏洞的相关问题？我们只谈论实际的bug吗？我们是否还排除了只有在有责任心和知识渊博的用户手中是安全的软件包，或者我们是否默认情况下也删除了导致可能的漏洞的软件包（即在Unix包管理中，可以将telnetd包指定为不安全，尽管它本身是完全正常的）。
所以，这就是问题所在。这种过滤是一个复杂的问题，复杂的事情最好是分散到不同的实体中，而不是强加在一个中心机构上。