Dependencies with known CVEs
A tool that just finds "lodash is outdated" isn't very actionable. Vetora matches the package-lock.json you provide against OSV.dev (Google/OpenSSF's open vulnerability database, which aggregates GitHub Security Advisories and NVD), then enriches every match with three concrete pieces of information.
What each finding contains
- The CVE (or GHSA identifier if there is none) and a summary of the flaw.
- The CVSS score, computed from the official vector (e.g.
CVSS:3.1/AV:N/AC:L/...) — not just a vague "high" label. - The exact patched version to install.
- Whether the CVE is listed in the CISA KEV catalog — meaning actively exploited in the wild, not just theoretically exploitable.
- The EPSS score — the estimated probability that this specific flaw gets exploited in the next 30 days.
Current coverage
Not a universal scanner, but not limited to a single ecosystem either — plenty for apps generated by Bolt, Lovable, v0, or Cursor, which sometimes rely on a Python or PHP backend on top of the Node.js frontend. Five formats are read: package-lock.json (npm, lockfileVersion 2/3), yarn.lock (classic v1 and Berry), pnpm-lock.yaml, requirements.txt (Python — only packages pinned with ==, a version range doesn't have a single resolved version to query) and composer.lock (PHP). Maven (Java) and Go aren't supported yet.
The fix
In the vast majority of cases: update the package to the indicated patched version. If there isn't one yet, assess the real risk (is the vulnerable code even reachable?) before considering a replacement.
Check whether your site is affected by this vulnerability.
Scan my app