Sonatype Introduces Next Generation Dependency Management | Press Release

Namespace Confusion: Minimizing Risk with Nexus Repository

February 10, 2021 By Michael Prescott

In case you’re here and you’re not sure why you should care about namespaces and routing rules, I highly recommend you start here

Ok now that you know why this matters, let's talk about ways that you can use Nexus Repository to help minimize your risk.

How to Protect Yourself with Nexus Repository Manager

If you’re using NXRM 3, you can protect your organization immediately using a feature called repository routing rules.

Routing rules let you specify which components can be downloaded from which repositories, using regular expressions that filter component paths. This can be used to prevent coordinates associated with your own organization from being fetched from remote repositories.

Here is an example routing rule that blocks any Sonatype-namespaced Java components from being fetched from a proxy of maven central:

Nexus Repository Routing Rules to Protect Against Namespace Confusion

 

The regular expression you need varies from ecosystem to ecosystem, because the repository/path structures are different. Here are examples for npm, PyPI, RubyGems and NuGet.

Blocking an Entire Namespace

Blocking org-internal coordinates is a lot easier if you’re using namespaces that clearly identify components made by your organization. npm coordinates can have explicit namespaces, so you can filter them with a single expression:

Ecosystem

Blocking Rule for a Namespace/Scope

npm

^/@sonatype/.*$

 

Blocking by Component Name Prefix

Some ecosystems don’t support explicit namespaces, but in many cases component names have a prefix that identifies the publishing organization.

Ecosystem

Blocking Rule for a Component Name Prefix

PyPI

^/.*/importlib_.*$
(blocks importlib_metadata etc.)

RubyGems

^/.*/rspec-.*$
(blocks rspec-expectations etc.)

NuGet

^/DotNetNuke\..*$
(blocks DotNetNuke.Core/7.0.0 etc.)

 

Blocking Specific Components

If your organization creates components that are neither namespaced nor prefixed, you’ve got more work to do. You’ll need to create a blocking matcher for every component that your organization uses:

 

Ecosystem

Component Name

npm

^/ajv/.*$

PyPI

^/.*/peppercorn-.*$

RubyGems

^/.*/activesupport-.*$

NuGet

^/angularjs/.*$

 

Testing your Rules

Nexus Repository comes with a global routing rules preview so you can easily tell what will be fetched from where. This is an example test to ensure that a Sonatype-specific component (nexus audit) will never be fetched from maven central.

Testing Rules in Nexus Repository to Protect Against Namespace Confusion

If you’re concerned about components that are already cached in your proxy repositories, there’s no need to worry: blocking rules don’t just prevent remote fetches, they prevent matching components from being served at all.

For more information, see the help documentation for routing rules in NXRM 3.

Tags: Nexus Repository, namespace, Product

Written by Michael Prescott

Michael is Sonatype's Nexus Repository Product Owner. He takes a functional approach to problem solving and works closely with his team to find solutions to software development issues.