Dependency Checker
Paste a lockfile or manifest — npm, Python, Go, Rust, Ruby, PHP, Java or .NET — to check every dependency against real CVE/GHSA data from OSV.dev, and generate a CycloneDX SBOM.
Frequently Asked Questions
Which languages and files does it support?
npm (package.json, package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml), Python (requirements.txt, Pipfile.lock, poetry.lock), Go (go.mod), Rust (Cargo.lock), Ruby (Gemfile.lock), PHP (composer.lock), Java (pom.xml, gradle.lockfile) and .NET (packages.lock.json). Paste the file as it is — the format is recognised from its contents.
Where does the vulnerability data come from?
OSV.dev — the open, aggregated vulnerability database Google maintains, pulling from GitHub Security Advisories (GHSA), the Python, Go and RustSec advisory databases, and more. It's the same underlying data source osv-scanner uses, and it carries the GHSA advisories behind `npm audit` and GitHub Dependabot.
Should I paste a manifest or a lockfile?
The lockfile if you have one — it records the exact resolved version of every dependency, transitive ones included, so the vulnerability match is precise. A package.json only has version ranges (like ^4.18.2), so this tool approximates the installed version from the range's lower bound, which can be wrong if a newer patch version was actually installed. A requirements.txt line is checked only when it carries a version, and a pom.xml only for dependencies whose version is written in that file, not inherited from a parent or BOM. go.mod lists the exact versions Go builds with.
How is the CVSS score calculated?
It's computed directly from the CVSS v3.1 vector OSV.dev reports for each vulnerability, using the real published FIRST.org scoring formula — not a rounded-off severity label. "Exploitability" reflects how easy the vulnerability is to trigger (remote, no auth, no user interaction needed = High) independent of how severe the impact is.
What does "no vulnerabilities found" actually mean?
It means OSV.dev has no recorded advisory for that exact package name and version at the time of the scan. It doesn't mean the package has been independently audited for undiscovered vulnerabilities — only that nothing known and disclosed currently matches.
What is an SBOM and why would I want one?
A Software Bill of Materials is a formal, machine-readable inventory of every component in your application — the same idea as a food ingredient label. Some enterprise customers and government contracts now require one. This tool generates a minimal but spec-valid CycloneDX 1.5 SBOM from whatever manifest you paste, with a package URL (purl) identifying each component in its own ecosystem.
Re-check Dependencies on Every Push
Connect a repository on a paid plan and CertNotify re-checks its dependency manifests against OSV on every push. A new CVE in a dependency you have not touched is found on your next push, not the day it is published.