Avoiding dependency confusion 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, 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?

• 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 our private registries to continuously monitor and control the dependencies you are using
• Create Dependency Firewall registries
• Use Bytesafe Policies to control the flow of packages

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

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:

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.

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.

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.

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.

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!