Audit what your npm dependency tree can execute

Incident day, zero install

# A named incident just hit the news — am I affected?
npx lockwarden check --incident node-ipc-may26

# Or check specific package versions against your lockfile:
npx lockwarden check node-ipc@9.1.6

Answers come from your resolved lockfile — every transitive path by which the package enters your tree, not just what package.json claims. Exit 0 clean, 1 hit, 2 error. Nothing is uploaded anywhere; there is nowhere to upload it to.

A different question

Everyone else asks “is this package known-bad?” — lockwarden asks “what can this dependency tree execute, and what changed?”

Day-zero structural detection

Advisory databases lag attacks by design. lockwarden scores the execution surface a version bump introduces — a new install script, a new binding.gyp, a 25x file-size jump, a new transitive dep in a patch release. Legitimate native packages carry build hooks forever; attacks introduce them. Delta scoring needs no feed to fire.

Nothing leaves your machine

No account, no telemetry, no backend — ever. 2026 malware actively terminates CI security agents and blocks their telemetry domains; lockwarden has no endpoint to attack. Advisory data ships vendored inside the npm package, and —offline hard-fails if any network call is even attempted.

The 2026 vectors

Beyond lifecycle scripts: binding.gyp / node-gyp hooks that run even with scripts disabled, AI-agent hooks and MCP manifests that fire on session start, IDE folder-open task files, and tampered dependencies pre-baked inside vendored node_modules that no registry-level scanner ever sees.

From one-liner to PR gate

# .github/workflows/lockwarden.yml — the whole integration
- uses: itsraghul/lockwarden/packages/action@v1
  with:
    diff-base: ${{ github.event.pull_request.base.sha }}

Delta-scored review of every dependency bump, findings in the GitHub Security tab you already use. Set up the Action →