Mitigating Supply Chain Attacks

I've heard people say that they would never trust software written in JavaScript because of the growing number of npm supply chain attacks. Kinda based, but also overly absolutist in an unproductive way.

Since we have a JS product, we take these concerns seriously and have steps in place to mitigate the risks (detailed below). With proper handling, JS products can be just as safe as those in other ecosystems.

What are Supply Chain Attacks

Basically, an attacker gains access to the publishing credentials for a highly-used package, and publishes a maliciously crafted version of the package. Any packages or products that transitively depend on this package may then unwittingly install the malware when they install their product or upgrade their dependencies. So it may be a dependency of a dependency of a dependency of a package which can poison the product.

These malware packages are often quickly noticed within a few days, but anyone caught installing these packages during that time will be affected.

These malware packages cause extreme damage, often targeting exfiltration of additional credentials, like cryptocurrency wallets or AWS access tokens. No bueno.

The vast majority of supply chain attacks occur via the npm package registry. Why? Probably because JavaScript remains one of the largest, most popular language ecosystems and package reuse is highly encouraged. There's billions of downloads from npm per week. So it's a juicy target.

What We Do

Use a Lockfile

So if npm supply chain attacks occur when a user upgrades a project dependencies, we have to make sure that all upgrades are audited and intentional. This starts with a project lockfile.

A lockfile is a snapshot of exact versions of all dependencies and transitive dependencies for a project. It ensures that only those exact versions specified in the lockfile will be installed.

Our code includes a lockfile, so checking out the code and installing dependencies will always install the pre-selected dependencies, and can never expose us to a new supply chain attack.

Audit Lockfile Changes

It's very important that every update to the lockfile is treated carefully, since updating the lockfile to a malicious version of a dependency can open up our developers or users to these supply chain attacks. We conservatively update the lockfile and don't update dependencies to newly-published versions proactively. We review diffs manually and use automated tooling to flag suspicious changes.

Enforce a Lockfile in Production

The problem with lockfiles is that they are limited to only apply within a local project. There's no way to fully enforce a lockfile from a published package. For this reason we emphatically warn against installing Lodestar via npm.

We only support and promote deployments which respect the lockfile.

1. Build from source
2. Prebuilt binary
3. Prebuilt docker image

Switch to PNPM

We're switching to the pnpm package manager, which has been championing features to mitigate supply chain attacks. This should help us more robustly mitigate these attacks.

Minimize External Dependency Attack Surface

We intentionally are very selective about which dependencies we rely on, choosing to copy or vendor simple code rather than fully embracing the entire npm package ecosystem. Additionally, implementing our zig roadmap will further reduce the external dependencies we rely on.