Is it safe to use maven central to resolve dependencies (inside a corporate network)?

Question

I'm currently having some problems at work, where the BitDefender antivirus suite that is deployed on everyone's computers is blocking access to Maven Central.

Firstly, we are not a software shop, there are only really 2 people in the company that need to access jars from Maven Central, so the problems we come up against are not really common to the whole company.

I have spoken with the IT Manager, and whilst he did not want to allow jars to be accessed from just any location on the internet, he did add an exception to the BitDefender policies to allow jars from Maven Central to be accessed and downloaded (our build tool is Gradle by the way). All okay, apart from there are still some jars which we cannot successfully access from Maven Central.

I get the impression that he is leaning towards having to specifically add new exceptions to the BitDefender policies for any new jars we are having troubles with, commenting that "By way of information, we will probably need to continue to tweak and tune these settings given the inherently dubious nature of the way these code updates and packages use the HTTP protocol."

Now, my thoughts are that there clearly must be safe and secure means of accessing any required jars, at the very least any jars from Maven Central. Surely this is how major software shops work, right? These industry standard build tools surely do not make 'inherently dubious use of the HTTP protocol', right?

So, my question is how do software shops and the like approach the issue of network security, whilst still enabling their developers to access the jars they require to do their jobs? Is there any useful information I could look to that address' the security aspect of accessing jars from remote repositories such as Maven Central via build tools? Anything I could go back to the IT Manager with to argue the case of how/why we should have less restricted access?

All help/comments is much appreciated!

Answer 1

Here's what we do at my company, and I work for a very large company where security is intense.

We CANNOT link to the maven central repository, BUT there is a whole team dedicated to ensuring that any and all possible software tools are available via an "in-house" repository in our network.

If there is a technology I need for my project, I check if it is in the in-house repo. If not, I can request that it is included.

Based on the info you provided that you do not have a big software department, I would recommend doing something similar to what we are doing here in setting up a repo within the company network with whatever technologies you currently need. This is also nice because you can add technologies as needed as the years progress and your software team grows (possibly).

I hope I have provided some insight/ideas.

Answer 2

These industry standard build tools surely do not make 'inherently dubious use of the HTTP protocol', right?

I would be really really surprised if any of these tools (specially Maven) does anything dubious. The code is open, out there and I am sure people would have already figured out if it was doing anything malicious.

Talking specifically about Maven Central, all the jars deployed in Maven Central need to be signed with a GPG key. Also the files are secured with an SHA checksum to ensure they are not modified. You can read a detailed Readme for process of deploying jars to maven central here which lists all the mandatory requirements for deploying jars to Maven Central.

https://docs.sonatype.org/display/Repository/Central+Sync+Requirements

A Repository Manager will always help you as you ensure that the files are downloaded only one time, and then served locally. So you only need to hit the Maven Central in case you add a dependency which is missing in the local repository. A commercial version of Nexus repository manager has ability to verify the jar against its signature to ensure that it was not modified.

I think its safe to access Maven Central, as there are adequate security measures being employed to ensure integrity of data.

Please note though that if you happen to access any other Third Party repositories, it may not necessarily be safe to do that.

All in all I am sure its about getting those jar files downloaded. Even if you are not using Maven, you will have to download them from somewhere also ensuring you pull down all the transitive dependencies manually and ensure integrity by manual verification of checksum. Maven is simply automating the whole process for you. In addition to that, it centralizes all of these libraries and serves it through a single server, unlike when you download them manually from various servers.

Answer 3

Its always a difficult situation when security considerations clash with development needs. In one of the former companies I worked with we solved the Maven repository issue by using a repository manager which had the necessary permissions to fetch the jars from the external repositories. I highly recommend such a tool because it also reduces the dependency on the external repo. You can still build your SW even if the external repo is not reachable at the moment.

Of course, there is still the possibility to abuse it. This is something you can only overcome by building up mutual trust between the involved groups.