Dependency Vulnerability Scanner
Scan a lockfile for known vulnerabilities. The file is read in your browser; only package names and versions are sent.
Looks up live data Your lockfile is read in your browser and is not uploaded. Only a list of package names with exact versions (shown to you before you press Scan) is sent to our server, which asks OSV.dev for known vulnerabilities and returns them. We do not keep a record of your scan; the answer may sit in a temporary cache for about a minute. A Cloudflare Turnstile bot check runs when you press the button (it loads a script from challenges.cloudflare.com and may show a short challenge).
Drop a lockfile here, , or paste its contents below.
package-lock.json · yarn.lock · pnpm-lock.yaml · requirements.txt (pinned) · Pipfile.lock · poetry.lock · go.mod · go.sum · Cargo.lock · composer.lock · Gemfile.lock
What will be sent
Only these lines, one per package (ecosystem, name, exact version). Your lockfile itself is not uploaded, and nothing else from it is sent.
Results come from OSV.dev, an open vulnerability database that combines GitHub advisories, CVE data and ecosystem databases. A clean result means no known issue for those exact versions, not that the code is safe.
Report a problem with this tool
About this tool
Modern projects depend on hundreds of packages, and any of them can have a published vulnerability. A lockfile records the exact version of each package you install, which is what makes it possible to check them. Drop your lockfile here, or paste it, and the page reads it in your browser: package-lock.json (versions 1 to 3), yarn.lock (classic and berry), pnpm-lock.yaml, pinned requirements.txt, Pipfile.lock, poetry.lock, go.mod, go.sum, Cargo.lock, composer.lock or Gemfile.lock. It then shows you exactly what will be sent, which is only a list of the ecosystem, name and exact version of each package, never the file itself. When you press Scan, our server asks OSV.dev, an open database that combines GitHub security advisories, CVE data and ecosystem databases such as PyPI and RustSec, which of those exact versions have known issues. Results are grouped so the same vulnerability published under several ids (GHSA, CVE, PYSEC) appears once, sorted by severity, with the version that fixes it. A scan is limited to 1200 packages and advisory details are read for the first 100, the rest are listed with links. Results were compared with Google's osv-scanner on real lockfiles from public projects. A clean result means no known issue for those versions, not that the software is safe; it also does not tell you whether your code actually uses the vulnerable function.
How to use it
- Drop a lockfile on the page, or paste its contents.
- Check the package count and the lines that will be sent.
- Press Scan. A short bot check may run first.
- Update the packages listed, starting with Critical and High, to the fixed versions shown.
Common problems
- My requirements.txt shows only a few packages
- Only lines pinned to an exact version (name==1.2.3) can be checked. Generate a fully pinned file with pip freeze or pip-compile.
- It says the lockfile format is not recognised
- Use the lockfile, not the manifest: package-lock.json rather than package.json, Cargo.lock rather than Cargo.toml, composer.lock rather than composer.json.
- A package shows a vulnerability but my code does not use that part
- The scan reports every known issue for that version. Judge the severity and whether the affected function is reachable, and upgrade when a fixed version exists.