SBOM Vulnerability Scanner
Drop in a lockfile or SBOM and check every pinned version against known vulnerabilities — parsed locally, matched against the OSV database.
A lockfile is the exact list of versions your build actually installs — and every pinned version is a bet that no one has found a hole in it since. This scanner reads that list (package-lock.json, requirements.txt, go.mod, or a CycloneDX / SPDX SBOM), sends only the name-and-version pairs to the public OSV.dev vulnerability database, and reports which packages have known vulnerabilities, how severe they are, which version fixes each one, and whether any of the CVEs are on CISA's Known Exploited Vulnerabilities list. The companion guide is your lockfile hiding vulnerabilities? explains what the results do — and do not — prove. If the scan flags a CVE, the Bulk CVE Triage desk puts it in exploitation context.
Last updated:
Your lockfile or SBOM
Accepted: package-lock.json, requirements.txt, go.mod, CycloneDX JSON, SPDX JSON. Maximum file size 5 MB.
The format is detected from the filename and the contents; you can also pick it yourself below.
🔒 Your lockfile is parsed in your browser and never uploaded. Only package names and versions go to OSV.dev; only CVE ids go to our own checker for KEV flags.
Scan results
No scan yet. Upload or paste a lockfile or SBOM above and press “Scan for vulnerabilities”.
No known vulnerabilities found
None of the scanned versions matched a vulnerability in the OSV database. That means no one has reported one for these exact versions — it is not a guarantee the code is safe. Unreported vulnerabilities, malicious packages and typosquats are invisible to this check; the article explains the boundary.
Your lockfile never leaves this page
Parsing happens entirely in your browser: the file you drop in — or the text you paste — is read locally and never uploaded anywhere. Only the extracted package names and versions are sent out, to the public OSV.dev vulnerability database (no account, no key), so it can match them against known vulnerabilities. CVE ids from the matches are then sent to this site's own checker for a CISA KEV lookup. Nothing else leaves the page: no file contents, no paths, no project names.
Scan limits
At most 500 packages are scanned per run — any extras are listed as not scanned. At most 200 vulnerability details are fetched. Results come from the OSV database for the exact versions in your file; a package version the database has never seen returns no match, which is not the same as a clean bill of health.
The honest limits
“No vulnerabilities found” means none in the OSV database for these exact versions. It does not mean the code is safe: vulnerabilities nobody has reported yet, malicious packages, typosquat names and compromised releases are all invisible to a version-matching check.
A match is version-exact. If your file pins a range instead of an exact version, it is skipped and listed as such — the scanner will not guess which version you actually installed. The same applies to packages whose ecosystem the scanner cannot map: they are listed as skipped, never silently dropped.
KEV flags come from a single lookup against this site's own checker (CISA KEV data, refreshed daily). If that lookup fails or is rate-limited, the scan still completes — the KEV column simply says “unknown” instead of blocking your results.
Why the pinned version is the attack surface
A lockfile exists because “latest” is not a version. It records the exact tree your build installed, so every machine and every deploy gets the same code. That determinism is also what makes the lockfile scannable: a vulnerability database is keyed by exact package and version, so a pinned version can be judged in a single lookup, while a floating range cannot. The scan is therefore only as good as the file — commit the lockfile, keep it fresh, and the scanner can tell you the truth about what you ship.
The check itself is deliberately narrow. OSV.dev aggregates vulnerability records from GitHub advisories, the NVD and the language ecosystems, and matches them against your versions. What it cannot do is judge the code: a package with no known CVE can still be malicious, abandoned, or a lookalike of a package you meant to install. Version matching is a fast, cheap first filter — the one that catches the lodash you forgot to upgrade — not a security audit.
Why a KEV flag outranks a high CVSS score
A CVSS score measures how bad a vulnerability would be if exploited. The CISA Known Exploited Vulnerabilities catalog measures something else: whether it is actually being exploited, in the wild, right now. A medium-severity CVE on the KEV list deserves a patch this week; a critical CVE nobody has weaponised can often wait for the next planned upgrade. That is why this scanner badges KEV rows separately and why the results sort by worst severity first — but the KEV badge is the one to act on first.
Fixed versions carry their own risk. The fix for a vulnerability is usually a minor or patch release, but “fixed in 4.17.21” can also mean a behaviour change that breaks your build, and some vulnerabilities have no fixed version at all — the scanner says so plainly instead of inventing one. Patch the KEV items first, then the criticals with a published fix, then schedule the rest; pin the new versions, commit the lockfile, and re-scan. The same loop belongs in CI, where it runs on every pull request instead of once a quarter.
Licences in this SBOM
Licences listed here come only from licence fields carried in the SBOM itself. Lockfiles (package-lock.json, requirements.txt, go.mod) carry no licence data, so nothing is shown for them — this page does not look licences up per package, because no public database reliably provides them.
Lockfile and SBOM terms, pinned down
Lockfile. A file that records the exact version of every package a build installs — package-lock.json for npm, requirements.txt with == pins for Python, go.mod/go.sum for Go — so installs are reproducible.
SBOM. Software Bill of Materials: a machine-readable inventory of every component in a piece of software, usually in CycloneDX or SPDX format. It is the lockfile generalised to the whole supply chain.
OSV.dev. Google's public vulnerability database, aggregating advisories from GitHub, the NVD and the language ecosystems, queryable by exact package name, ecosystem and version.
GHSA. A GitHub Security Advisory id (GHSA-xxxx-xxxx-xxxx). Most npm, PyPI and Go vulnerabilities in OSV carry one, usually alongside a CVE id.
CVE. Common Vulnerabilities and Exposures: the shared numbering scheme (CVE-YYYY-NNNNN) that lets every database, scanner and vendor talk about the same vulnerability.
CVSS. Common Vulnerability Scoring System: a 0–10 score for how severe a vulnerability would be if exploited. 9.0+ is CRITICAL, 7.0+ HIGH, 4.0+ MEDIUM, below 4.0 LOW.
KEV. CISA's Known Exploited Vulnerabilities catalog: vulnerabilities confirmed exploited in the wild, each with a remediation due date. A KEV flag means “patch now”, whatever the CVSS says.
Fixed version. The first version of a package in which a vulnerability is no longer present, taken from the advisory's affected-range events. Some vulnerabilities have none published yet.
Purl. Package URL (pkg:npm/[email protected]): a standard way to name a package with its ecosystem and version. SBOMs carry purls, which is how the scanner knows which ecosystem a component belongs to.
Frequently asked questions
Does my lockfile leave my browser?
No. The file is parsed locally and never uploaded. Only the extracted package names and versions are sent to OSV.dev, a public vulnerability database, and only the CVE ids from the matches are sent to this site's own checker for the KEV lookup. File contents, paths and project names never leave the page.
Why is a package listed as “skipped”?
Three reasons: the line is not an exact pin (a range like ~= or >=, an -r include, a replace directive), the ecosystem cannot be mapped to one OSV.dev supports, or the scan hit the 500-package cap. Skipped entries are always listed with their reason — nothing is dropped silently.
“No vulnerabilities found” — am I safe?
Not necessarily. It means no vulnerability has been reported for these exact versions in the OSV database. Unreported vulnerabilities, malicious or typosquat packages, and compromised releases do not appear in any vulnerability database. Treat the scan as a first filter, not a clean bill of health.
What should I fix first?
Start with anything carrying a KEV badge — those vulnerabilities are being exploited now, and CISA sets a due date for each. Then the CRITICAL and HIGH rows that have a published fixed version, starting with the packages your application actually imports. Use the Bulk CVE Triage desk for the exploitation context behind each CVE.
A vulnerability has no fixed version. What now?
First check whether a newer version exists that the advisory has not recorded yet — advisories lag releases. If there really is no fix, your options are to remove the dependency, replace it, or mitigate the vulnerable code path (for example, stop passing untrusted input to the affected function) and watch the advisory for an update. Re-scan after any change.