Namespace confusion: Minimizing risk with Sonatype Nexus Repository

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 Sonatype Nexus Repository to help minimize your risk.

How to protect yourself with Sonatype Nexus Repository

If you're using Sonatype Nexus Repository, 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:

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:

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.

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:

Testing your rules

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

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.