How to control which libraries are available in our Nexus repo


#1

I want to create a configuration in which projects get their dependencies from a local repo that will not download from the internet. A repo manager (person) will take care that the right libraries are available in that local repo. This way we can prevent developers from downloading just any dependency.

What is the best way to do this? We are currently using Sonatype Nexus Pro.


#2

Hi Christine - What will be the criteria for determining the ‘right’ libraries? Most customers I talk they focus on known vulnerabilities and licenses. What they quickly realize is that a ‘clean’ library today, could be a vulnerable library tomorrow. So a library’s status (clean, vulnerable, etc…) only applies to a certain point in time.

I also see many customers with a process where a person is the one that vets out what a ‘good’ library is for download, but this quickly becomes a bottleneck. This person must not only make sure the requested library is OK for use, but also all of its dependencies, which can go many levels deep.

Having said all of that, you can create a hosted repo where the repo manager person can upload the ‘right’ libraries. That person can use thinks like our OSS Index (https://ossindex.sonatype.org/) to check for vulnerabilities. Build tools/developers would need to point to this hosted tool. For example, for those using something like Maven, they would set their ‘mirror of’ setting to this hosted repo.

If you want to make this more automated, I encourage you to check out our Firewall and Lifecycle products.


#3

My question was not “which are the right libraries”. My question was “how do I control which libraries are in our repo”.
I read about your Firewall product, as one of you told me that what used to be “Procurement” is now in Nexus firewall. I can’t find detailed documentation on this feature in Firewall. I wouldn’t mind having a trial license for Firewall (or whatever I need for this feature) to try it out.


#4

Hi Christine,

As Fernando mentioned - At a high level this would require setting up hosted repositories, configuring permissions for who is allowed to add components (repo manager) and who is able to pull from that repository.

Your developers would configure their clients to look at your hosted repo instead of the public repo. Some of this is dependent on what format(s) we’re talking about.

We actually have a new online course on Repo that covers some of this: Lesson 3: Repository Types

I’ll reach out to you about the Firewall trial and get you connected with the right person.


#5

Nick,
I am already in touch with one of your sales people. All I want to do is have a quick hands on look at the relevant modules of Nexus 3 and/or Nexus Firewall before we decide what to advise our client.
What I’m looking for is what was called “procurement” in Nexus 2.