Nexus Repository Manager 3.17 introduces a new feature that allows organizations to better protect their supply chain dependencies against hijacking attacks. This new feature, known as Repository Routing, allows an administrator of a Nexus Repository Manager instance to apply certain routing rules when making requests to upstream repositories.
To preface this discussion, let’s go over the types of repositories that exist within NXRM.
- First, we have Proxy Repositories which allow for the proxying of public repositories such as npmjs.com, PyPi.org, maven-central, etc.
- Second, there exist Hosted Repositories. These are private, locally hosted repositories which are generally used to store proprietary components.
- Then, there are Group Repositories which allow for the aggregation of proxy and/or hosted repositories which are made available under a single repository URL.
Namespace Squatting
So, how does all of this play into organizations’ security concerns regarding their proprietary dependencies? What can arise from the exposure of private package names is Namespace Squatting. This is the practice of defining or using previously unused terms in someone else’s namespace without their permission. A bad actor with knowledge of an organization’s namespaces could take that information and publish components with company internal namespaces to public repositories. This could lead to the unintentional consumption of these bad packages, possibly making your applications and organization prone to attacks.
Repository Rules
How can you prevent something like namespace squatting from happening to your organization? This is where Repository Routing Rules come into play. With the whitelisting or blacklisting of paths, you can prevent developers from sending proprietary package requests to proxy repositories.
Shown below, you can create a repository routing rule to prevent developers from pulling a private package from a public repository. In this example, company Pied Piper uses proprietary library piedpiper-middle-out throughout their applications.
Unfortunately, this information has been exposed and an evil hacker has decided to upload a malicious package by the same name to npmjs.
Luckily the repo admin has already taken steps to prevent their developers from inserting this package into their applications. Here’s how they did it:
The Routing Rules section of the interface can be found in the Administration section under Repository. A user will need to have the nx-all privilege to view or make changes to routing rules.
To edit a routing rule select it from the list or to create a new one click the Create Routing Rule button in the toolbar
A repository rule was created for private Pied Piper packages, so any requests for these packages made to a public repository will be blocked by Nexus Repo. The regEx specified in the Matchers section shows that any request for an internal package (i.e. any package that begins with “piedpiper”) will be identified and blocked.
After a rule is created, it needs to get applied to a repository. In the repository configuration page, the repository routing rule can be specified. In this case, the Pied Piper admin applied it to the npmjs proxy repo.
Repository routing delivers rule-based control over which components are fetched from specified sources. This control keeps your dependency supply chain secure by only looking in the right place for each component. With the release of Nexus Repository Manager 3.17, DevOps teams can start using repository routing rules to accelerate development, while safely knowing exactly where they are getting their components.
For more information on how to create/modify, test, or delete certain rules, refer to the Nexus Repository Manager 3 Routing Rules configuration details.
Review the 3.17 release notes to learn more about new format support for APT and Go and a new set up wizard and connect with other users at the Sonatype Community for additional product knowledge, useful documentation, and helpful video tutorials.
Sources:
W3.org "Namespace Squatting"
Pied Piper
