Known vulnerabilities
Exact versions are matched against OSV.dev, which aggregates GitHub Advisory, PyPA and other sources. You get CVSS-based severity, the fixed version and a fix-first order.
Dependency audit from a lock file: vulnerabilities, licenses and SBOM
Upload your project's dependency files: package-lock.json, yarn.lock, package.json, requirements.txt, pom.xml or build.gradle. We show known vulnerabilities with the fixed version, licenses with a risk class, deprecated and long-unmaintained packages, cloud vendor SDKs and a rough work estimate. Download a CycloneDX SBOM right away.
Files are parsed in your browser and never uploaded. Before the check you'll see exactly which package@version pairs will be sent, and can exclude internal ones.
Drop your dependency files here
Up to 12 files, 15 MB each. A lock file gives the most complete result.
Supported: package-lock.json, npm-shrinkwrap.json, yarn.lock, package.json, requirements*.txt, pom.xml, build.gradle, build.gradle.kts. Not yet: pnpm-lock.yaml, poetry.lock, Pipfile.lock, go.mod, Cargo.lock, composer.lock, Gemfile.lock.
Your files stay with you. Parsing happens in the browser; files are not uploaded. Next you'll see which package@version pairs will be sent to our server and on to the public OSV.dev vulnerability database and the deps.dev package index; internal packages can be excluded. We don't store this list or write it to logs.
What the tool checks
Manifests are parsed in your browser; only the package@version pairs you approve are sent to the server. Every finding comes with an explanation and a next step.
Licenses
The license is taken from the lock file or registry and classified: permissive, weak or strong copyleft, paid, undetermined. OR and AND expressions follow SPDX rules.
Package freshness
We flag deprecated packages, packages without releases for years, and versions far behind the latest. The risky combo is “unmaintained” plus “vulnerability without a fix”.
When it helps
Accepting a project from a contractor
See the dependency inventory, known vulnerabilities and license risks before signing off, instead of taking it on trust.
An SBOM for a customer or audit
Produce a CycloneDX component list in minutes without setting up tooling in CI.
Sizing technical debt
Find out how many packages need updating and roughly how many hours it takes before planning a sprint or budget.
Ready to try?
Download LiMP VPN for free and feel the difference within a minute.
What an SBOM is and why you need one
An SBOM (Software Bill of Materials) lists every third-party component of a program with its version and license. It's requested at project acceptance, in security audits and when handing a product over to a customer: it shows what the application is built from and what it relies on.
CycloneDX is an open SBOM format standard. A CycloneDX JSON file is understood by Dependency-Track, vulnerability scanners and most software supply-chain tools.
What the tool doesn't do
- It doesn't analyse source code (it isn't SAST) and doesn't tell whether vulnerable code is reachable in your app.
- It doesn't check container images, OS packages or private registries.
- It doesn't open pull requests or fix anything by itself.
- It doesn't replace continuous checks in CI. If you already run Dependabot, Renovate, Snyk, OSV-Scanner or Dependency-Track, use this for one-off jobs: acceptance, estimates and documents.
Why a lock file matters
package.json and requirements.txt usually contain version ranges such as ^4.17.0. Only the lock file knows which version is actually installed. Vulnerability databases match exact versions, so without a lock file the check is incomplete: packages with ranges are listed but not checked.
Dependency audit FAQ
No. Files are read in your browser. After you confirm, only package@version pairs are sent to the server. We don't store this list or write it to logs.
Package name and version: to OSV.dev for vulnerabilities and to deps.dev for licenses and release dates. You can exclude internal packages before the check; packages from private registries are excluded automatically.
A list of a program's components in a standard format (CycloneDX here). It's used for project acceptance, customer handover, audits and third-party component documentation.
No. The record applies to the package version. The tool doesn't determine whether the vulnerable code is called in your app. Updating to the fixed version is still usually worth it.
No. It means there are no known records for those versions at the time of the check. Packages without an exact version can't be checked, and new vulnerabilities are published all the time.
The package's last release was long ago. It's a signal, not a verdict: small finished libraries can go years without changes. The dangerous combo is “unmaintained” plus “vulnerability with no fix” — such a package needs replacing.
A library that is itself open source but only works with one company's service: AWS, Firebase, Sentry, Stripe and so on. It's a reference note about vendor dependency, not a ban or legal advice.
Those run continuously in your CI. This is a one-off check with nothing to install or configure: handy for project acceptance, tech-debt estimates and preparing an SBOM.