Avoiding dependency confusion with Bytesafe

Cover image

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, raising awareness on potential issues and consequences of not managing your supply chain are a top priority for Bytesafe.

Recently there has been a lot of great discussions on dependency management and supply chain attacks. Alex Birsan posted this article on dependency confusion and how he used it to hack companies like Microsoft and Apple. And npm added this great post on avoiding substitution attacks (another term for the same thing).

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

Read more to see how we can secure your code supply chain.

What is dependency confusion? Term coined for the confusion of package managers on what package version to pull into your project, from what source, when faced with multiple options.

Using a private registry for insights and control

The potential security issues related to dependency management stretch far beyond the case of dependency confusion.

Most organizations today have limited knowledge and control over the dependencies they are using across all different teams. There are many talented developers who make it their responsibility to make responsible decisions for the dependencies their projects are using, 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 address the overall dependency management:

bytesafe-package-management

Use a Bytesafe private registry 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.

With our registries, 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.

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. Scoped packages are fully supported with Bytesafe private registries.

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). Blocking the ability for packages with the same name (inside the scope) to be pulled from the public registry.

Configure projects to use Bytesafe registries

Make sure Bytesafe 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

Create dependency firewall registries

Since all Bytesafe workspaces allow for unlimited private registries, users can opt for configuring several levels of registries.

One such workflow would include using a dependency firewall registry.

The idea 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 other internal registries will use this single registry as a package source. 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. Or why not clone entire registries, when new dependencies are needed (rolling registries, instead of automatically updating their composition)?

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.

approved packages
pull
pull
install
install
install
install
registry.npmjs.org
Firewall registry
Dev registry 1
Dev registry 2
Developer
Developer
Developer
Developer

Use policies to freeze dependencies

Organizations can also make use of Bytesafe’s range of security policies to make sure they are in control of their dependencies.

bytesafe-offers-a-wide-range-of-policies

One example is the Freeze policy that can be used to make registries read-only (temporarily or permanently).

Block internal package names

The Block policy can be used to block whole packages or ranges of versions from being pulled into a registry.

By blocking internal package names in a firewall registry, external packages substituting internal packages is no longer an option. This allows organizations with strict security requirements to stay in complete control.

Immutable vs mutable package versions? By default Bytesafe allows for mutable versions to support patching of public packages. Users that require immutable versions for security aspects, can enable this for registries with the related policy.

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 suggestions on features that you would like to see? Send us your suggestion, we appreciate any insight!

Want to improve your dependency management with Bytesafe?

If you have questions or want to discuss how Bytesafe can best assist with securing the code supply chain for your team? Contact us directly using either email or the support chat.

New user? Sign up for a free trial and test Bytesafe yourself!

Security is never easy. Let us guide you through the jungle!

We’ll keep you up to date on supply chain security and send you the latest information.