Preventing Namespace Confusion
The features discussed in this section require Nexus Repository Manager Pro and IQ Server with the following licenses: Repository and Firewall.
There is a software supply chain attack that exploits the circumstance that many components have no namespace among their coordinates and package management tools can fetch components from multiple sources. Imagine you have a proprietary npm component called
network-utilities that you published to your private npm registry and is being used as a dependency in your applications. Further imagine somebody, unrelated to your organization, published a package with the exact same name to the public npm registry. When your developers or CI servers run
npm install network-utilities while building your application, which package exactly is being installed now? The question becomes even more difficult to answer when one considers the common practice of using version ranges for dependencies, thereby asking the package management tool to automatically resolve newer versions of a component, from whereever they are found.
It doesn't require much imagination to see why confusing your proprietary component with a public component that merely has the same name but a totally different author is dangerous. And considering that the mere installation of a package can already execute code from it, for instance using npm's preinstall scripts, it becomes clear that one should block the installation of such components as early as possible. The following describes how Nexus Firewall helps you defend against this.
In a nutshell, you configure Nexus Repository Manager to submit the names of all your proprietary components to IQ Server. A policy in IQ Server will then flag any component requested from a proxy repository that has a name which matches the name of any of your proprietary components, allowing Firewall to quarantine the component.
In detail, these are the necessary steps to protect against dependency/namespace confusion:
- Connect Nexus Repository Manger to IQ Server
Select the hosted repositories in Nexus Repository Manager that contain your proprietary components by ticking the equally named checkbox in their configuration or using the System > Proprietary Repositories view.
If some of these hosted repositories not only contain your proprietary components but also patched/rebuilt 3rd-party components, we recommend you first move these components into a separate repository. Otherwise, the names of those 3rd-party components will be mistaken as being proprietary and will have to be excluded from the IQ Server policy below.
- Ensure your IQ Server installation contains a policy that fires on name conflicts between public and your proprietary components. Our reference policies contain such a policy and can serve as inspiration for your configuration.
- Enable Quarantine for the proxy repositories in Nexus Repository Manager that contain external/untrusted components.
From here on, all components that are newly fetched from the proxied remote repositories will be evaluated with regard to dependency/namespace confusion. Components that were quarantined due to the IQ policy can be reviewed in the repository results view. In that view you will also find a button to re-evaluate all pre-existing components from the proxy repository to consider the new policy configuation, showing you whether any of those components that were downloaded in the past are violating the new policy and hence suspicious.