<blockquote>
  <p>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?</p>
</blockquote>

<p>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..</p>

<p>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.</p>

<p>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 <em>be there</em> and supply the packages.</p>

<p>Placing a security filter, if you will, between <code>mvn</code> 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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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 <code>telnetd</code> package as insecure although it is, per se, perfectly fine).</p>

<p>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.</p>

CC BY-SA 4.0
2018-05-10T09:08:24.887Z
2018-05-10T09:29:51.307Z
2018-05-10T09:29:51.307Z
AnoE
<p>First of all there is <strong>one</strong> Maven central repository and that is Maven central. The website mvnrepository.com is just a search engine for Maven central.</p>

<p>Secondly there is a gazillion of paid services that already scan artifacts for you and allow you to know about known vulnerabilities beforehand. So that problem is already solved.</p>

<p>Finally several people who download code from Maven central are used for university projects, quick demos, QA environments so of course not all people care...</p>

CC BY-SA 3.0
2018-04-10T04:46:04.767Z
2018-04-10T04:46:04.767Z
kazanaki
<p>AFAIK there are two official primary repositories for Maven packages (Java language):</p>

<ul>
<li>search.maven.org offered by Sonatype Inc.</li>
<li>mvnrepository.com offered by a private person @frodriguez</li>
</ul>

<p>Now obviously it makes sense to have a complete archive for backward compatibility purposes. However already as mentioned back 2013 in the <a href="http://static1.1.sqspcdn.com/static/f/702523/22081811/1362352394057/201303-Jackson.pdf" rel="nofollow noreferrer">interview</a> with Sonatype's CEO, there are lots of downloads for components with known vulnerabilities. So many seem just to not care.</p>

<p><a href="https://i.sstatic.net/8sMlZ.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/8sMlZ.png" alt="enter image description here"></a></p>

<p>So is backward compatibility of so much value here? Why not take some action to reduce risks? Of course there is the <a href="https://jeremylong.github.io/DependencyCheck/index.html" rel="nofollow noreferrer">OWASP dependency check plugin</a> but I think on long term it is possible to implement a deeper risk prevention strategy.</p>

<p>Question: 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 <strong>reject download of vulnerable components <em>by default</em></strong>? This would in my opinion save a lot of time and electrical power if not to expect every build on the planet to do the check if this can be done centrally effectively.</p>

<p>UPD. In year 2017, over 80% of projects still <a href="https://www.sonatype.com/ssc2017" rel="nofollow noreferrer">seem not to recognize the risks</a>, despite court cases.</p>

<p><a href="https://i.sstatic.net/mTkmK.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/mTkmK.png" alt="2017 State of software supply chain"></a></p>

<culture><security><java><devsecops><dependency-management>
Mitigating Maven Central risks as seen from the DevSecOps perspective
Ta Mu
# Mitigating Maven Central risks as seen from the DevSecOps perspective

(Asked by: username_0 on 2018-02-27)

AFAIK there are two official primary repositories for Maven packages (Java language):

* search.maven.org offered by Sonatype Inc.
* mvnrepository.com offered by a private person @frodriguez

Now obviously it makes sense to have a complete archive for backward compatibility purposes. However already as mentioned back 2013 in the [interview](http://static1.1.sqspcdn.com/static/f/702523/22081811/1362352394057/201303-Jackson.pdf) with Sonatype's CEO, there are lots of downloads for components with known vulnerabilities. So many seem just to not care.

[![enter image description here](https://i.sstatic.net/8sMlZ.png)](https://i.sstatic.net/8sMlZ.png)

So is backward compatibility of so much value here? Why not take some action to reduce risks? Of course there is the [OWASP dependency check plugin](https://jeremylong.github.io/DependencyCheck/index.html) but I think on long term it is possible to implement a deeper risk prevention strategy.

Question: 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***? This would in my opinion save a lot of time and electrical power if not to expect every build on the planet to do the check if this can be done centrally effectively.

UPD. In year 2017, over 80% of projects still [seem not to recognize the risks](https://www.sonatype.com/ssc2017), despite court cases.

[![2017 State of software supply chain](https://i.sstatic.net/mTkmK.png)](https://i.sstatic.net/mTkmK.png)

**Tags:** culture, security, java, devsecops, dependency-management


---

## 2 answers

### Answer by username_1 on 2018-05-10. Score: 2 | Accepted answer

> 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.


---

### Answer by username_2 on 2018-04-10. Score: 1

First of all there is **one** Maven central repository and that is Maven central. The website mvnrepository.com is just a search engine for Maven central.

Secondly there is a gazillion of paid services that already scan artifacts for you and allow you to know about known vulnerabilities beforehand. So that problem is already solved.

Finally several people who download code from Maven central are used for university projects, quick demos, QA environments so of course not all people care...


---

