I made supply-chain security a blocking step of npm install

Matheus Agostinho — Thu, 18 Jun 2026 01:30:19 +0000

The gap

npm audit runs after the install. By then the package — and any
postinstall script it shipped — is already on your machine. For
supply-chain attacks, "after" is too late.

So I built Vault: an npm-compatible, pnpm-style package manager (written
in Rust) that makes the security check part of install itself.

## What it does before touching node_modules

Blocks known CVEs. It audits the resolved graph (OSV + a static scan) and refuses to install critical/high vulnerabilities. --force exists, but you have to mean it.
No lifecycle scripts by default. postinstall is the classic malware entrypoint; Vault doesn't run it unless you allow it, and installs run in a Landlock sandbox.
Takeover signals. It warns when a package was published moments ago or when its maintainer count suddenly drops.

## A real block

A project had "vite": "^5.4.11". npm/pnpm happily resolve that to 5.4.21
and install it. That version sits inside the affected range of
GHSA-fx2h-pf6j-xcff (CVE-2026-53571, CVSS 8.2). Vault:

✗ BLOCKED vite@5.4.21: critical/high CVE(s): GHSA-fx2h-pf6j-xcff
error: security policy blocked install

One bump to the patched line and the install went through clean.

## Isn't auditing slow?

It's pnpm-style under the hood (content-addressable store + hard links). In
my tests it lands within ~0.2s of pnpm on a warm cache while running a full
audit every install. It's not faster than pnpm — the point is you don't pay
a real speed tax for the safety.

## Try it / break it

It's early (v0.1.3) and I want the rough edges found.


bash
  npm i -g vaultpm   # bins: vault / vt
  vault install

  Repo: https://github.com/Matheusagostinho/vaultpm — issues and harsh feedback
  very welcome.

DEV Community: Matheus Agostinho

I made supply-chain security a blocking step of npm install

The gap