depproof

Guide · npm

Scan npm dependencies for vulnerabilities — self-hosted, from the lockfile

Here’s how to find known CVEs across your whole npm dependency tree — direct and transitive — straight from your lockfile, and fail the build on a severity you choose. Open advisory data, self-hosted, with no npm install and nothing sent to a SaaS.

Updated 25 Jul 2026 · by the depproof team

Why not just npm audit?

npm audit is a fine first check, but it’s npm-only, tied to the registry, and part of your install step — which doesn’t fit a locked-down pipeline, a monorepo that also ships Java, or a check on code you only have the source for. SaaS scanners avoid the install but want your code in their cloud.

depproof reads your lockfile and screens every dependency against OSV.dev — open, portable advisory data, not a proprietary database — on your own infrastructure, and returns a pass/fail you can gate a PR on.

Option 1 · GitHub Action

Add this to a workflow. depproof reads your lockfile, checks the full tree for known vulnerabilities, and fails the job when it finds one at or above your threshold — no npm install in the job. 

# .github/workflows/vuln-scan.yml
name: vuln-scan
on: [pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: depproof/depproof-action@v1
        with:
          fail-on: high  # critical | high | medium | low | none

Option 2 · Docker container

The same scanner ships as one public image — run it in any CI, or locally. It exits non-zero when it finds a vulnerability at or above your threshold, so it drops straight into a pipeline step. 

docker pull ghcr.io/depproof/depproof:v0

# scan the current npm project for vulnerabilities — no install
docker run --rm -v $PWD:/work -w /work ghcr.io/depproof/depproof:v0 \
  scan --discover --root /work --fail-on high --html --output-dir /work

Fail the build on the severity you choose

fail-on is the gate. Pick the bar that matches your risk appetite:

  • critical — fail only on the most severe (the default).
  • high — fail on high and critical (a common CI bar).
  • medium / low — tighten the threshold further.
  • none — report-only; never fails, findings still land in the artifacts.

What you get

  • Known CVEs and malicious versions across the whole tree — direct and transitive, each with its severity.
  • A pass/fail exit code your CI can gate on, at the threshold you set.
  • An HTML report you can read and a CycloneDX SBOM — the vulnerabilities and the component inventory in one run.

What this covers — and what it doesn’t

Being precise, because security claims are easy to overstate:

  • Known vulnerabilities and known-malicious packages. depproof surfaces everything OSV records for your dependencies — including OSV’s malicious-package advisories (OSV aggregates the OpenSSF malicious-packages data), so a version flagged malicious there shows up in your report. Open and portable — no proprietary database to be locked into.
  • It’s only as broad as OSV. depproof relies on OSV’s recorded advisories — it doesn’t run its own behavioral or heuristic malware analysis or independent typosquat detection, and it doesn’t do reachability analysis (whether a vulnerable path is actually reached). Coverage tracks OSV’s.

Where this fits

Vulnerability scanning is one of three things depproof does in the same run — the others are license and SBOM. From here:

Run your first scan → Read the docs More guides

depproof is free for open source and teams under $1M revenue — see pricing. The action README is the source of truth for exact inputs and the current release. depproof is not affiliated with npm or Snyk; product names are used nominatively.