Dependency vulnerability scanner that reads your lockfile
A manifest says ^4.17.0; the lockfile says what is actually installed. RepoVerse checks the installed versions — direct and transitive — against the OSV vulnerability database and tells you which upgrade clears the most advisories.
Lockfiles it understands
Exact versions come from the lockfile when there is one; without one the floor of each declared range is checked and the report says so.
- npm package-lock.json (v1, v2, v3) and npm-shrinkwrap.json
- yarn.lock (classic and Berry) and pnpm-lock.yaml
- Pipfile.lock and poetry.lock for Python
- Cargo.lock for Rust, composer.lock for PHP, Gemfile.lock for Ruby
Direct, transitive, dev — and through what
A vulnerable package you declared is a version bump; one pulled in by another dependency is a bump of that dependency. The report says which, names the direct dependency that brings a transitive package in, and marks development-only packages so production risk is read first. Transitive development tooling is left out of the lookup entirely.
The fix for your version line
Advisories for packages with several maintained lines list one fix per line. The fixed release shown is the one on the line you are actually using — 1.1.12 for someone on 1.1.11, not a jump to 5.x — and each package gets a single upgrade target that clears every advisory against it, or a note when no fix exists and the package should be replaced. Deprecated and long-unmaintained npm packages are flagged too.
Questions
- Which vulnerability database does it use?
- OSV.dev, which aggregates GitHub Security Advisories, the Python, Rust, Go and RubyGems advisory databases and others, keyed on exact package versions.
- Does it check transitive dependencies?
- Yes, from the lockfile. Each transitive package shows which direct dependency brings it in. Transitive development-only packages are skipped because they do not ship.
- What if my repository has no lockfile?
- The lowest version each declared range accepts is checked and marked as a range floor, because the version you really have may already be fixed. Committing a lockfile makes the result exact.
Related
- GitHub security scanner for code, secrets and dependenciesScan a GitHub repository for injection flaws, leaked secrets and vulnerable dependencies. Data-flow traces from request to sink, lockfile-aware, with fixes.
- Vulnerable dependencies: the code you did not writeMost application code is third-party. How vulnerable dependencies get into a project (CWE-1395), why the lockfile is what matters, and how to pick the upgrade that fixes it.
- Find vulnerable JavaScript libraries on a live websiteFind outdated, vulnerable JavaScript libraries on any website — jQuery, lodash, Bootstrap, moment, DOMPurify, Next.js — even inside minified Vite and webpack bundles.
Updated 2026-10-11