Using LavaMoat To Solve Software Supply Chain Security
- Popularity: It’s used on the front-end and the back-end
- Mutability: Everything is changeable by default
The Copay Wallet Hack of 2018 got Kumavis interested in solving this problem and is the primary case study for designing LavaMoat. Copay was a self-custodial Bitcoin wallet from BitPay that was the target of a supply chain hack resulting in stolen user funds. An npm dependency used by the wallet was controlled by an attacker allowing them to deploy the attack.
So, what’s the fix? A couple of arguments have been made to solve this problem.
Never use dependencies? Nah.
While it might be safer, are you going to give up on open source—the wealth of the commons that forms the foundations we all build on? On sharing and collaborating? If you’re trying to build something complex, do you really want to spend time recreating the wheel?
Yeah, neither do we.
Audit all dependencies always? Nah.
This is a good idea, but, how many dependencies do you have? Hundreds? Thousands? Tens of thousands? It’s not practical–although if you want to perform a manual audit, LavaMoat will help you prioritize the most dangerous ones (more on that later).
And even if you do have time to really look at the package of differences are you going to be able to catch a security vulnerability?
Hard thing to bet on. So let’s explore a different solution:
Instead of never using dependencies or auditing all your dependencies always, let’s take a look at LavaMoat’s security kernel that wraps packages in compartments and only gives them access to what they need.
Because, remember, in order for malicious code to attack your system, it needs permission to do so. LavaMoat's kernel goes through the third-party code that you’re pulling into your project, determines what the dependencies need to run, and gives those dependencies only that.
LavaMoat is currently protecting tens of millions of users at MetaMask and runs at three different times during each development process: Installation of dependencies, build, and runtime.
To put things into perspective, check out this dependency graph visualization dashboard:
The list of your dependencies are on the left and the graph is depicted as a neural network on the right. The colors are based on a heuristic of dangerousness: for example, the green ones don’t import any powerful platform APIs.
__The idea here is to help you prioritize auditing your dependencies. __
So how do you implement this?
Taking the three development phases into account:
- Install: @lavamoat/allow-scripts
- Build: lavamoat-node
- Runtime: lavamoat-x plugin for your bundler
And that should act as a moat for malicious code.
Building software at scale
If you’re interested in helping us, LavaMoat is open-source! We are trying to get plugins for as many bundlers as possible and want to make it easier to review policies and add tight lockdowns when giving network access to packages. You can contribute here.
And sign up for our developer newsletter for more updates! Happy building.
Keep reading our latest stories
releases, security news, and more