DEV Community

Cover image for Automatic protection from dependency confusion
Andreas Sommarström
Andreas Sommarström

Posted on • Edited on • Originally published at bytesafe.dev

Automatic protection from dependency confusion

Dependency confusion occurs when a system or user is tricked into fetching a package version from a public registry, instead of the intended trusted package with the same namespace from your private registry.

Like other supply chain attacks it’s all about injecting non-intended packages into a vulnerable supply chain, where malicious code can be executed on installation. A critical security threat for your supply chain if left uncontrolled. And a problem that potentially gets even worse in automated environments like CI/CD pipelines, if left unnoticed.

My previous post on the topic was focused on how to use security focused package management to improve control of the software supply chain.

This post focuses instead on a solution that automatically protects your supply chain against dependency confusion. A scalable solution that is safe by default and prevents internal packages from being replaced by packages from external sources, without requiring complex configurations.

How to automatically protect against dependency confusion

Enforcing this protection from dependency confusion is based on using Bytesafe registries for the private and public npm packages you depend on.

Alt Text

Bytesafe offers fully managed and private npm registries that allow users to better control their supply chain and secure the private and public packages they depend on.

With Bytesafe any package version marked as internal, either automatically or manually, will be protected from dependency confusion.

The solution in short:

  • Package versions published, pushed or uploaded to an internal registry will automatically be flagged as internal
  • Fetching new versions of internal packages from upstream sources, will only consider upstreams with internal versions of the same package

It’s as simple as that. Package versions added directly by users are automatically marked as internal, making sure internal packages are not exposed by mistake. And the best part, all the complex logic behind resolving dependencies safely is handled by Bytesafe, instead of being pushed on to our users.

Packages without the internal flag will function as they always have, with full access to public upstreams.

Users can continue to use registries for both public and private packages, enjoying the benefits of a single source of truth for all package dependencies. While simultaneously being fully protected from dependency confusion.

Example: Publish internal packages to a private registry

Publishing internal packages to a private registry allows them to be shared and available for other team members and systems.

$ npm --registry 'https://workspace.bytesafe.dev/r/your-internal-registry/' publish

...

+ your-internal-package@4.5.6
Enter fullscreen mode Exit fullscreen mode

With the target registry flagged as internal the version will automatically be flagged internal as well. Preventing it from being substituted by package versions from untrusted external sources.

example-internal-package-in-bytesafe

Protection during dependency resolution (npm install)

The core protection of internal packages is evident when resolving dependencies from upstream. This is typically the case when using npm install to install dependencies for a project and npm attempts to fetch all available versions.

Any attempt to fetch new versions of internal packages will only use upstreams that contain other internal versions of the packages. All other sources will be ignored for the purpose of this action.

Users can securely install any internal version from their registries, without ever having to worry about the possibility of the package being replaced with a malicious package from any external registry. A protection that scales to all users and systems.

Example: Using a Bytesafe private registry together with registry.npmjs.org as an upstream for public packages

internal-registry-example

  • Package published to the private registry will be flagged internal
  • Install of internal package by other users / systems will never fetch versions from registry.npmjs.org as it does not contain internal versions
  • Installing any public package will work as normal, with registry.npmjs.org as a valid upstream

Getting started - How to protect your supply chain

Any new Bytesafe workspaces and registries come with protection from dependency confusion by default - No additional actions required.

  1. Create your own Bytesafe Workspace
  2. Publish your internal packages to the private registry. They will automatically be marked internal.
  3. Install/add your other public dependencies. All dependencies are continuously monitored for security issues.

With both public and private dependencies now in one single source of truth, you can distribute this secure source to all team members and systems. A solution that scales across your whole organization.

Upstream issues - additional layer of defence against supply chain attacks

Bytesafe also detects upstream configuration issues that could indicate a supply chain attack.

upstream issues in bytesafe

Upstream issues are opened when a package version is found in multiple external upstreams, with non-matching contents. Issues trigger notifications, warning you of a potential dependency confusion attack.

Thanks for reading!

Follow Bytesafe on Twitter Bytesafe - A better way to control your software supply chain | Product Hunt

Top comments (0)