OSV dependency lookup
Open a lockfile or SBOM, see exactly which package names and versions would be sent, and look them up in the OSV.dev vulnerability database: severity, fixed versions, known exploitation and a link for each advisory.
Check dependencies against OSV
Open or paste a lockfile or SBOM. This page reads the exact versions locally, shows you the request, and sends only package names and versions to the OSV.dev vulnerability database when you choose to.
Nothing leaves this browser until you press Send. The file is read on this page. The request to api.osv.dev holds only the ecosystem, name and version of each package you leave in it; packages from git, local paths or registries other than the public one are left out unless you include them. Like any web request, it also shows OSV.dev your IP address and browser. No cookies or referrer are sent.
Loading the lockfile reader… If this remains visible, refresh the page.
Vulnerability report
| Package | Advisory | Severity | Fixed in |
|---|
Exploit prediction (EPSS), optional
FIRST’s Exploit Prediction Scoring System estimates the probability that a CVE is exploited in the next 30 days. Adding it sends these CVE IDs, and nothing else, toapi.first.org:
“Known exploited” comes from a snapshot of CISA’s Known Exploited Vulnerabilities catalog (version 2026.10.08, released 8 October 2026, 1,739 entries), which ships with this page because cisa.gov does not allow browser requests. Entries added since then are missing: check the live catalogbefore you rely on a “no”. KEV data is CC0 1.0; its use here implies no endorsement by CISA.
What is checked
- Exact versions from package-lock.json (lockfile versions 1 to 3), requirements.txt pins (== and ===), poetry.lock, uv.lock, go.sum, Gemfile.lock and composer.lock, and the Package URLs of a CycloneDX or SPDX JSON SBOM
- What is not checked, and why: version ranges, git and local-path packages, workspace links and SBOM components without a Package URL
- Every advisory OSV.dev lists for each version, grouped when records alias each other (a GHSA entry and the PYSEC entry for one CVE appear once)
- Severity from the record’s CVSS v4.0 or v3.x vector, scored on this page, or the source database’s own rating; the fixed versions of the affected ranges; links to each record
- Known exploitation from a dated snapshot of CISA’s KEV catalog, and optional EPSS scores from FIRST, sent only after a second confirmation
Source specifications
- OSV.dev API: POST /v1/querybatch
- OSV schema (affected ranges, severity, aliases)
- OSV data sources and their licences
- CISA Known Exploited Vulnerabilities catalog
- FIRST EPSS API
- CVSS v3.1 Specification Document (scoring of v3 vectors)
- OSV-Scanner, the command-line tool for CI
Data and attribution
Advisory records come from OSV.dev, which aggregates databases under their own licences (for example the GitHub Advisory Database, PyPI and Go databases under CC BY 4.0); each row links its record. CISA’s KEV data is CC0 1.0, and its use here implies no endorsement by CISA or DHS. EPSS scores are FIRST’s, published freely at first.org/epss. CVSS is owned by FIRST and used by permission.
Guides and practice
All toolsRespond to an exploited or malicious dependency
When a dependency vulnerability is being exploited, or a package version is malicious, triage gives way to incident response: find every running copy, contain it, patch and redeploy, hunt for exploitation, rotate secrets and close on deployed evidence.
Triage new dependency vulnerability findings
Turn a weekly batch of Dependabot, OSV-Scanner or npm audit findings into a short list of distinct, shipped, reachable issues, each routed to one outcome: fix, not affected, accept or escalate.
Use VEX without losing vulnerability evidence
Produce and consume precise vulnerability status statements tied to the product, version, justification and evidence.