Control your npm packages & avoid dependency confusion

There has been a lot of great discussions on dependency management and supply chain attacks recently. Alex Birsan posted this article
on dependency confusion and npm added this post on avoiding substitution attacks (another term for the same thing).

What is dependency confusion? Term coined for the confusion facing package managers (npm, yarn, pnpm) on what package version to pull into your project, what source to use and trust, when faced with multiple options.

With Bytesafe, we have been hard at work the last year to create a service that allows users to stay in control of their package dependencies.
As such, any discussions that raises awareness on potential issues and consequences of not managing your supply chain are a top priority for us as well.

Edit: See this follow-up post with an updated, safe by default solution for dependency confusion.

How can you use Bytesafe to protect against supply chain attacks and avoid dependency confusion?

• Update: Internal packages - our secure by default solution for Dependency confusion!
• Update: Get notified with Issues - issues are created for package versions found in multiple external upstreams, with non-matching contents. An indicator for a possible supply chain attacks.
• Use private npm registries to continuously monitor and control the dependencies you are using
• Create a dependency firewall registry
• Use security policies to control the flow of packages

Using a private registry for insights and control

Many teams today have limited knowledge and control over the dependencies they are using. There are many talented developers who make it their responsibility to make informed and responsible decisions for the packages used in their projects. But, the tools to get a complete top-down view are often missing.

So before you can even start to manage issues like dependency confusion, you need to address the overall dependency management:

Use private registries from Bytesafe to centralize, identify and control all the package dependencies you are using.
Continuously monitor your dependencies. Scanning them for potential security and license compliance issues.

By centralizing dependency management, users no longer have to rely on manual reviews of package.json or lock-files, or point in time scans to identify the dependencies used for particular projects.

Configure projects to use private registry be default

Your applications security is only as strong as its weakest link. So make sure private registries are used as the default registry for projects, by providing a custom project level .npmrc configuration file.

Overwriting potentially problematic individual configs when in that project space.

# Example .npmrc file where all packages are fetched from Bytesafe
registry=https://workspace.bytesafe.dev/r/example-registry/
//workspace.bytesafe.dev/r/example-registry/:_authToken=${AUTH_TOKEN}
always-auth=true

Claim organization name and use scope for internal packages

One option to close the attack vector for dependency confusion is the use of scoped packages in conjunction with blocking your organizations name in the public registry.

Users that want to deploy this tactic should claim an organization name in the public npm registry and use that scope for internal packages (@your-organization/pkg) in their private registries.

Blocking the ability for packages with the same name (inside the scope) to be pulled from the public registry by accident.

Create dependency firewall registries

The idea behind a dependency firewall is simple: create a single registry that is responsible for the link to the public npm registry and works as a single point of contact with the outside world.

All users (or other internal registries) will use this registry as a package source and npm proxy. This enables a central point where security teams can monitor and prune the registry to make sure it only includes approved packages.

If needed, the link to the public npm registry can be removed entirely, and only reinstated again when package dependencies are to be added or updated.

By using a dependency firewall in this way, new packages and versions do not automatically trickle down to all other users and applications in an organization.

Use policies to lock dependencies or block packages

Bytesafe offers a range of security policies to make sure users are in control of their dependencies.

Policies are rules that are checked and enforced before registry actions are applied. For example a policy could prevent packages with known security vulnerabilities from being pulled into a registry.

Short-list of examples:

• The Freeze policy that can be used to make registries read-only (temporarily or permanently)
• The Secure policy blocks packages with known security vulnerabilities
• The Block policy can be used to block whole packages or ranges of versions

Going forward

Our roadmap contains many exciting security policies that we are looking to add to improve the protection against supply chain attacks.

Have any questions or suggestions on features that you would like to see? Comment below or contact us on Twitter (@bytesafedev). We appreciate all insight!

Want to improve your dependency management with Bytesafe? Sign up for free. Pull your dependencies into one of our registries and test Bytesafe yourself!