LavaMoat is a set of tools for securing JavaScript projects against a category of attacks called software supply chain attacks.

This genre of attack occurs when a malicious dependency makes its way into a developer's application. An attacker could use the dependency to then steal important secrets (like credit card numbers, private keys, or data) or make the application vulnerable to a range of other attacks.

These attacks have already hit e.g. the cryptocurrency ecosystem and present a significant risk for the developers and users of wallets and apps.

In order to help mitigate the risk of such an attack we are building a suite of tools that aim to tackle the supply chain security at various stages of software lifecycle i.e. at the installation of the package, at build time and most of all - at runtime.

The goal of LavaMoat is to bring added protections to modern JavaScript apps without having to rewrite them from scratch and automate a good first-start security configuration.

1. disable/allow dependency lifecycle scripts (eg. "postinstall") via @lavamoat/allow-scripts
2. run your server or build process in lavamoat-node
3. build your ui with LavaMoat for Browserify

Even starting with adding just step 1 - the allow-scripts is a great improvement to your supply chain security.

Lavamoat's allow-scripts configures your project to disable running install scripts by default and gives you a configuration section in package.json where the allowed ones can be listed.
It also installs a package with an install script that fails installation as early as possible if the configuration is accidentally removed.

No new install scripts showing up in your dependencies will run unexpectedly. That way you eliminate the most popular attack vector of malicious packages in recent years.

You can use lavamoat to prevent malicious code introduced into a package from running.

The LavaMoat runtime reduces the supply chain risk by:

1. Prevent modifying JavaScript's primordials (Object, String, Number, Array, ...)
2. Limit access to the platform API (window, document, XHR, etc) per-package

Both are provided by SES containers. Platform API access is granted by a policy file that LavaMoat can generate and allow the project to selectively customize. All details of policy file structure are documented in the Policy file explained doc.

SES is the sandbox used in LavaMoat. See SES's secure computing guide to learn more about the risks of untrusted javascript.

Run your server or app building code with protections via LavaMoat Node

When using LavaMoat in the browser, you can just use your favorite bundler if there is an available plugin.

App bundles have two major components:

1. Runtime (aka kernel / loader / prelude / trusted computing base) This is the code that initializes and runs the bundle. For example, the implementation of the require function.

2. Module sources This includes the js content of the module sources, and sometimes some config information like module name aliases.

LavaMoat modifies the bundle's runtime to enforce the configured constraints.

• LavaMoat Browserify

The lavamoat viz is a tool to visualize an application's dependency graph and assess package dangerousness.

• HackerNoon - I’m harvesting credit card numbers and passwords from your site. Here’s how
• Agoric - POLA Would Have Prevented the Event-Stream Incident
• Snyk - Why npm lockfiles can be a security blindspot for injecting malicious modules
• Bytecode Alliance - Building a secure by default, composable future for WebAssembly

• Making 'npm install' Safe - Kate Sills - QCon 2020 ~40min
• JavaScript Supply Chain Security - Adam Baldwin - LocoMocoSec 2019 ~25min
• Analysis of an exploited npm package – Jarrod Overson - Amsterdam JSNation Conference 2019 ~25min
• How Malicious NPM Packages Make Your Apps Vulnerable - SnykLive stream 2022 ~1h

Made with love by MetaMask

Funded by ConsenSys

Runs on Agoric