lavamoat/ipfs-registry

Signed package registry backed by IPFS

LavaMoat

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.

Watch the introduction video

How to secure your app against supplychain attacks

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.

How LavaMoat works

Install scripts

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.

Runtime protections

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.

SecureEcmaScript (SES)

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

LavaMoat runtime protection in Node.js

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

LavaMoat runtime protection in the browser

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

lavamoat-viz

[!WARNING] lavamoat-viz is currently unmaintained; we have tentative plans to resume development in the future.

lavamoat-viz is a tool to visualize an application's dependency graph and assess its security risk.

Scuttling security feature

LavaMoat offers further (yet advanced) security enhancement to LavaMoat protection which is known as scuttling - an optional feature which is turned off by default and can enhance the security LavaMoat will apply to your application. Before using it, make sure to get yourself familiar with it and with the implications of using it by reading its doc file.

Further reading on software supplychain security

Articles

• 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

Videos

• 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
• Object-capability security for JavaScript applications - KU Leuven Cybersecurity seminar 2022 ~1h

Supporters

Made with love by MetaMask

Funded by ConsenSys

Runs on Agoric

ipfs-registry's Issues

Package level publish permissions

Currently permissions are applied at the namespace level.

Namespace owners should be able to restrict user's publish permissions to certain packages.

• Create namespace user
• Remove namespace user (only owners can remove administrators!)
• Add package restriction to existing user
• Remove package restriction from existing user

Support local file layer

Support writing packages to the local file system.

Simple Layer implementation backed by tokio::fs::File.

We can use this to build a caching Layer that can be executed for fetch requests.

Create table indices

Support maintenance status

So consumers can be made aware whether a package is:

• Passively maintained
• Actively maintained
• Unmaintained

Store all object references in the database?

At the moment we only store a single object reference in the database and we try to resolve against all layers when fetching from the storage layer.

This will fail when the ObjectKey type does not match the kind expected by the storage layer.

We can store all object references in the database and then try each layer in turn using the correct kind of object key for each layer.

Support signoff by approved addresses

So publishing can be further restricted to ensure all packages are signed off by a selection of specific addresses.

Check TLS support for IPFS storage layer

Consider review and approval process

To establish trust in a package anybody could download the package, review it's contents and sign the package bytes to signal approval of the package.

Packages with lots of approvals would indicate a significant level of trust.

Approvals could signify either:

• Package was used as a dependency and no problems were encountered
• Package was peer reviewed

Use base64 encoding for signature in version record

Consider ENS for namespaces (mitigate namespace squatting)

Allow for ENS lookups to determine the namespace for an owner address which would associate a cost with creating a namespace helping to mitigate namespace squatting.

Consider storing and verify against checksum

For additional integrity checks.

End to end tests

Support deprecating a package

When a package has an obvious better alternative or has been renamed/moved.

Support webhooks for publish event

So that we could implement file system readers (like npmfs) or other functionality such as indexing all packages in a git repository for syncing or create static pages that reflect the contents of the database.

Support collection of authorized publishers for a namespace

Support cargo registry kind and crate archives

To illustrate that the implementation is agnostic of source archives.

Store signature in package definition

Prometheus metrics

Improve CORS config

Strip scope for NPM packages

Package references <namespace>/<package-name>/<package-version> uses a forward slash as a delimiter which means package names may not include forward slashes however NPM uses a slash for scoped package names so we need to strip the scope from package names.

Verify against saved signature on download

Improve package keys for non-IPFS storage layers

Use a checksum of PackageKey::Pointer as a standard key identifier for non-IPFS layers.

Discoverability is provided by the database and this give us a flatter structure.

Consider how we could encode the package checksum into the identifier and whether is is desirable.

Restrict publishing to set of allowed addresses

Confusable protection for semver pre and build strings

Validate namespace string

JSON API endpoints

• List packages for a namespace
• List versions of a package
• Get package definition
• Get raw package document (package.json)

Support download from CID

So that consumers can point directly to an IPFS archive using the CID.

Support yanking packages

Allow package publishers to indicate that a particular version of a package that was published previously has a problem and should be avoided, consumers should use a newer version of the package wherever possible.

Support listing versions in a specific range

Include signature and checksum in publish receipt

Verify publish version is ahead of latest

So that authors cannot publish older versions that do not yet exist.

Validate package name

Add a PackageName type similar to Namespace.