💡 tl;dr - We built a tool to sandbox package installations (e.g., npm install <pkg>). It’s open source, available as part of our CLI, and supports npm, yarn, and poetry out of the box.

The conventional software engineering wisdom is that developers should be using lockfiles. This ensures that software is being built on a solid foundation, removing the risk of package functionality changing out from under you which may cause unexpected breakages. It also has the nice side effect of improving your security posture by giving you a clear understanding of what dependencies you’re pulling into your system.

Or at least that is what we’re told.

The horrifying truth is that some package managers (looking at you NPM), in the course of generating a lockfile, actually execute code contained in the package manifest. Why this is considered okay is beyond me. But it is, quite frankly, a horrible idea.

Security tooling expects a lockfile to perform accurate analysis. The generation of lockfiles possibly installs malware. What is a developer to do?

Developers Are High-Value Targets

The truth of the matter is: developers are high-value targets. With access to organization infrastructure, SSH keys, network diagrams, and source repositories, developers are the lynchpin in the technology organization. If a developer is breached, it is a failure of the technology organization at large.

Fortunately, we’ve been hard at work developing an open-source, freely available solution to address this problem: Sandboxed package installations.

This capability, called the Phylum Birdcage, allows developers to install open-source packages in an environment that restricts access to the network, filesystem, and environment variables. Any attempt to access a restricted resource (e.g., SSH keys) will result in the installation process being terminated. This allows developers to defend against any CI/CD based software supply chain attacks.

Let’s install a package that attempts to exfiltrate our SSH keys to a “remote” server:

And again with our sandbox:

In the first case, our SSH keys were successfully shipped off to the attacker. However, in the second instance, we violated the sandbox policy, and our SSH keys were never even sent!

Start Protecting Yourself

The sandbox ships as part of our phylum CLI, which can be installed with the following:

curl https://sh.phylum.io | sh -

You can run any package manager command through Phylum to take advantage of the sandbox. For example, installing react via Phylum:

phylum npm install react

To make things easier and more seamless, you can alias the package manager to phylum and run package manager commands as you normally would:

alias npm="phylum npm"
npm install react

Birdcage Bug Bounty

We’re keen on ensuring that our sandbox is blocking threats on developer workstations. As part of this effort, we have set up a simple CTF bug bounty that exercises the package installation sandbox.

There are additional instructions on the linked CTF. However, the gist of it is as follows:

• Build an NPM package that exfiltrates a secret located at /treasure/key
• Send the secret to a remote server http://exfil.phylum.app:9090
• If you provide the correct key, you will get a success response with additional instructions

Get started now.