Why you should use an npm proxy

Cover image

This short post talks about how using an private npm proxy helps improve control and security when using JavaScript packages in general and npm in particular.

Want to visualize your package dependencies? Enforce security policies? Manage your dependency on the public npm registry? Setting up an npm proxy is for you!

Why an npm proxy is a good idea

Millions of developers use the public npm registry every day and with its >1.3 million packages it is an important asset in the JavaScript ecosystem (recent news that GitHub has acquired npm, Inc only emphazises that).

But with the convenience of the public npm registry and the development speed all those available open source packages entail, comes downsides for keeping track of and managing all those dependencies.

Therefore, taking steps to improve control over dependencies and overall security when using npm is a necessity for any organization that want to manage their code supply chain (and not blindly trust code from external sources).

And one of the first things that is usually mentioned for improved npm security is the use of an npm proxy.

Control over dependencies - How?

There are multiple ways an npm proxy enables better dependency control:

  • Central registry: an npm proxy acts as a central registry for all your required package versions. Private and public together, possibly from multiple upstream sources.

  • Visualization of dependencies: With all required packages in one place it enables identification of a potential issues. Additionally the proxy caches your packages, removing the worry that a essential package version will be unpublished in the future.

  • Single source: With all developers using the same proxy registry, all users make use of the same package source and versions. Removing the potential issue of unknowingly building with different versions of a dependency.

Improved security - How?

Using an npm proxy enables a layer of separation between your organization and the outside JavaScript world.

  • Policies: an npm proxy introduces an important layer where you can enforce the security policies your organization require.
  • License compliance: all dependencies in one place to review or scan for problematic licenses
  • Security scanning: review dependencies for known vulnerabilities and security problems

Using Bytesafe as a proxy

Bytesafe’s hosted private registries by default works as an npm proxy. All that is required is a configured upstream to your registry. Enabling the benefits of both an npm proxy and the additional benefits that Bytesafe offers to your workflow.

Example setup

First lets look at what a setup using Bytesafe as an npm proxy may look like (and the workflow and flow of packages that would entail) .
Image below is for the default setup that comes pre-configured with your intial default registry.

npm-proxy-setup

When using Bytesafe, developers configure their npm client to interact with the Bytesafe private registry instead of the (default) public registry.

$ npm --registry https://example.bytesafe.dev/r/default login

Username: bytesafe

Password:

Email(this IS public): your@email.com

Logged in as bytesafe on https://example.bytesafe.dev/r/default.

$ npm --registry https://example.bytesafe.dev/r/default install

...

Using npm client with a Bytesafe registry

With the npm client no longer directly link to the public registry, it results in the following workflow:

  • Developers publish/install package versions to/from the Bytesafe private registry - no interaction directly with the public registry. No need to change any behavior or usage patterns. Using regular tools and clients.
  • Bytesafe proxy holds all public and private packages and their required dependencies. If a package is required that is not in the Bytesafe registry it is pulled from upstreams. As developers publish their packages to the proxy, final push to the upstream registry is performed from Bytesafe.
  • Upstreams registries provide Bytesafe with package versions and is the target for push of packages from proxy. Upstreams can be either a single registry or multiple registries.

For additional insights on how to best configure your registries with upstreams to suit your organization, read my previous blog post on the subject.

Benefits of using Bytesafe

So why should you use Bytesafe as your npm proxy? Let’s revisit some of the arguments on why npm proxy is a good idea:

Central hub for all your required package versions

Bytesafe allows you to create multiple registries, and each registry can connect to multiple upstreams. So not only does Bytesafe work as the central hub for one of your upstream sources, rather multiple! Coupled with Bytesafe’s web console you are able to get a true visualization of all your JavaScript dependencies.

Private and public packages together

Push your private packages to Bytesafe, and they remain just that, private.

Want to publish your packages to the public npm registry? Do that from Bytesafe, ensuring that the correct person publish packages at the correct time.

Don’t want to keep track of and distribute npm authentication tokens amongst your team? By adding the token to the Bytesafe registry, you no longer need to distribute it to team members manually or keep track of it. And a more full-fledged and fine-grained IAM is planned for upcoming releases.

Always want to publish latest version of your package to upstream registries? Make use of Bytesafe’s Forward plugin to automatically push packages to upstreams (like the npmjs public registry).

Local cache of packages

Bytesafe acts as a cache for your required packages. All package versions that is pulled into Bytesafe, either via install to local projects or pulls, are stored as local copies for your needs. No need to worry that dependencies will be made unavailable, by unpublishes or other reasons.

Having a local cache for your dependencies also enables the ability to patch package versions with local changes. Need a change in one of your key dependencies, but the package maintainers are no longer supporting it? Make the change yourself and push it to your Bytesafe registry, overwriting the version. Your project that depend on the package continue as normal.

Multiple registries, each with its own purpose

Configure multiple registries to fit different scenarios and needs. Want a new registry for each sprint? Want to persist a deployment cycles dependencies as they were at release? Bytesafe’s multiple registry supports that.

Want to test releases before you push them to the public npm registry? Configure a staging registry with all dependencies and make sure all involved are testing using the same package versions.

Security scanning / License compliance

Upcoming features of Bytesafe will include security scanning and license compliance. For now Bytesafe enables both these functions, by holding and visualizing all your organizations dependencies at one place (including license information). And the first step to finding potential issues, are knowing about them.

A layer to enact security policies

Using a Bytesafe registry enables your organization to enforce whatever security policies and practices you require. Want complete control of available packages, restrict who has access and can release packages? Bytesafe enables this.

Add to that upcoming security features of Bytesafe, like whitelisting / blacklisting of packages to further strengthen your npm security.

For complete control over your open source dependencies, manually add what package versions are available in your Bytesafe registry

Hosted, reliable and fast

Bytesafe removes the need to self-host and self-manage an npm proxy. Its hosted solution is deployed in AWS and makes use of its reliable infrastructure.

And more…

For more information on how to make Bytesafe work for you and improve your workflow, see our previous posts on Plugins & Policies for more information.