Mitigating Maven Central risks as seen from the DevSecOps perspective
What could be a feasible way to motivate Maven and repository makers to establish some kind of early time warning, like issue special headers on download, or and additionally for example reject download of vulnerable components by default?


Your concern, i.e. the meat of your question is a very valid one: how to improve security when downloading "stuff" from the internet. Maven, yes, but also other places like Dockerhub, Debian, Ubuntu etc..

I have no idea what stance the Maven developers have on this; I assume they have thought about it and come to the conclusion that it is not a good idea, for whatever reason. Generally speaking, I see no particular reason to place this responsibility on the repository, though.

Having separate responsibilities between componentes (here, Maven Central as one component) is a very powerful concept in IT. You find it in Unix command line tools, in OOP class design, or server architecture. In this particular case, it seems perfectly valid to me to let Maven Central simply be a huge repository of "stuff". Its main function is to be there and supply the packages.

Placing a security filter, if you will, between mvn and Maven Central is then pretty easily achieved. For example, a company I work for runs their own hierarchy of Nexuses; while the developers can pretty much do whatever they want on their laptops, the automated build environments have no internet access and must go through curated Nexuses. Each project has their own Nexus (for seldom used packages), and they chain up to a common intra-company global Nexus.

Developers, then, have no way to insert packages into those Nexuses, but a dedicated team reviews new packages and decides whether they can be used.

Note that this extends not only to security, but also, for example, to licenses. Depending on the policy of the company, not every open source license may be acceptable. So this can also be screened for.

Another big reason would be non-security related bugs. Say you find that X of your projects use package Y, and Y is found out to contain a serious bug, maybe with the result of being able to trash all your data. Would Maven Central remove that version from their repository? Certainly not! The bug may only appear in a very small edge case, which, by chance could be very relevant to your company. So, by having your own repository structure inbetween, you can flag the affected versions as "invalid", and thus enforce bug fixes traveling downward to your projects.

Finally, a company might want to phase out old versions of packages as a matter of routine, simply to keep up with the times. Using such a "filter" approach helps with that as well.

Back to Maven Central: why do they not do it? The question is not just a technical one, but also organizational. Who decides what is a relevant breach of security? Are we only talking about actual bugs? Are we also excluding packages that are safe in the hands of a responsible and knowledgeable user, or do we also by default remove packages that lead to possible holes indirectly (i.e., in a Unix package management, one may designate the telnetd package as insecure although it is, per se, perfectly fine).

So there you have it. Such filtering is a complex issue, and complex stuff is best distributed to different entities instead of forcing it on one central body.