Dependency scanning you can actually verify.

No. DepAudit parses the lockfile in your browser and never uploads the file. Only package names and versions are sent to the server, you are shown the exact list before it is sent, and anything resolving from a private registry is withheld automatically. This matters because a lockfile is a map of an organisation’s internal package namespace, and dependency-confusion attacks begin with learning an internal package name.

DepAudit scans all eight ecosystems it covers — JavaScript, Python, Java, .NET, Go, Ruby, PHP and Rust — across 28 file formats. For JavaScript: package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock (both Classic and Berry), bun.lock, and package.json for a best-effort check. For Python: poetry.lock, pdm.lock, uv.lock, Pipfile.lock and pylock.toml (PEP 751), plus requirements.txt and pyproject.toml. For Java: the output of `mvn dependency:tree`, and gradle.lockfile. For .NET: packages.lock.json. It also scans go.mod, Gemfile.lock, composer.lock and Cargo.lock. A Maven pom.xml is deliberately not scanned: it usually records no versions at all, because they are inherited from a parent POM, so only Maven itself can say what actually resolves.

DepAudit queries OSV.dev for advisory records, deps.dev as an independent second opinion on which advisories affect a given version, npm’s own advisory data as a cross-check, CISA’s Known Exploited Vulnerabilities catalogue for evidence of active exploitation, and FIRST’s EPSS for the forecast probability that a vulnerability is exploited in the next 30 days. Every finding names the database it came from, carries that source’s licence, and links to the original advisory record.

Because the version an advisory names as fixed is often not a version you can safely install. DepAudit walks candidate versions in ascending order and rejects any that are still vulnerable to another advisory, deprecated, yanked, or never published, so the first survivor is the smallest safe upgrade. For lodash 4.17.15 every advisory names 4.17.21 as the fix, but 4.17.21 is still affected by two further advisories and 4.18.0 is deprecated by its publisher, so the correct answer is 4.18.1.

A package.json declares version ranges and contains no transitive dependencies at all, which is where nearly every finding lives. DepAudit will scan one, but it resolves each range to the version a fresh install would pick today and labels the result best-effort. A lockfile records exact resolved versions and the full dependency tree, so it produces an exact answer. DepAudit always states which of the two you gave it.

No. DepAudit runs entirely in a web page with no sign-up, no CLI to install and no repository permissions to grant. Nothing is stored: the scan is not saved, and the raw file never leaves the browser tab.

DepAudit separates findings by whether they actually ship — runtime, build-time or unattributable — instead of reporting one undifferentiated count, and it orders them by evidence of real-world exploitation before severity, so a vulnerability CISA records as under active attack outranks a higher CVSS score nobody has ever exploited. Severities are shown per source rather than merged, unreviewed and disputed advisories are excluded from the headline count, and malware is treated as a separate incident-response state rather than a worse severity.

Yes. DepAudit is free to use with no account and no usage limits, and it is built on openly licensed advisory data: the GitHub Advisory Database under CC-BY 4.0 and the CISA KEV catalogue under CC0, among others.