Lockhound

For JavaScript and TypeScript teams

npm, Yarn and pnpm dependency security that ranks what matters

Lockhound reads package-lock.json, yarn.lock (classic and Berry) and pnpm-lock.yaml across your GitHub repositories, flags exploited and malicious packages first, and keeps dev-only noise out of the way.

A typical JavaScript project installs hundreds or thousands of packages, so npm audit on an older app produces a wall of findings. Most of them are in build tooling that never reaches users. Lockhound reads the same lockfiles and sorts the wall into a short list.

Lockfiles it understands

  • npm: package-lock.json and npm-shrinkwrap.json (lockfile versions 1, 2 and 3), including workspaces, nested node_modules and npm aliases.
  • Yarn: yarn.lock from Yarn classic and Yarn Berry, including aliases, patched packages and workspaces.
  • pnpm: pnpm-lock.yaml from lockfile versions 5, 6 and 9, including workspaces, peer-dependency variants and pnpm 10's two-document lockfiles.

For each package it works out the dependency scope by walking the dependency graph from package.json. A package reached only through devDependencies is marked dev-only. A package reached through dependencies ships.

From hundreds of findings to a few

Lockhound puts every finding in one of four priorities:

  1. Fix now: a malicious package, or a vulnerability CISA lists as exploited in the wild.
  2. Fix soon: critical or high severity in a package that ships.
  3. Plan a fix: critical or high in dev-only tooling, or medium severity that ships.
  4. Routine maintenance: everything else.

EPSS, the probability of exploitation, orders findings within a priority but never raises one. A critical prototype-pollution bug in a test helper waits, and a medium bug under active exploitation in your server framework doesn't.

Malicious packages

npm is the most targeted registry for malicious packages: typosquats, hijacked maintainer accounts and self-spreading worms. Lockhound flags any installed version that appears in the OpenSSF Malicious Packages database, puts it at the top of the list, and tells you to remove it and rotate secrets. It also looks for malware committed straight into your repository, such as build configs and VS Code tasks that run on folder open.

Upgrades that are actually safe

For every vulnerable version, Lockhound suggests the upgrade that fixes its advisories, then checks that version against every known advisory too. You get the right command for your tool:

npm install axios@^1.7.4        # a direct dependency
npm update follow-redirects     # a transitive one

If the parent package pins an old range, Lockhound says so, so you know to upgrade the parent instead.

Every pull request

A GitHub check on each pull request that touches a lockfile or package.json fails only on newly introduced risk. It also checks the files a pull request changes for known malware patterns.

Check a lockfile now without signing up, or connect GitHub to monitor every repository.

Read next