Dependency Vulnerability Advisor — Find the Fix, Not Just the CVE

Every scanner tells you that you're vulnerable. That's the easy half — and it leaves you with a list of CVE IDs and an afternoon of cross-referencing to work out what to actually upgrade to.

The fixed version is sitting right there in the advisory data those scanners already read. This returns it, as an upgrade plan.

Source: OSV.dev (Google's open-source vulnerability database). No API key, no login, no anti-bot.

What makes the output different

A normal scanner:

lodash@4.17.15 — GHSA-29mw-wpgm-hmr9, GHSA-35jh-r3h4-6jhm, GHSA-p6mc-m468-83gw…

This:

Upgrade lodash 4.17.15 → 4.17.21 (clears 6 of 6).

And where a clean fix isn't possible, it says so instead of pretending:

Upgrade django 3.2.1 → 3.2.25 (stays on 3.x, clears 48 of 61). The remaining 13 need 5.2.17 — a major-version upgrade.

That second line is the whole point. Telling someone on Django 3.2 to "just upgrade to 5.2" is technically the only way to clear everything and completely useless as advice. You get both: the bump you can do this afternoon, and the honest cost of finishing the job.

What you get

Field	Description
package · currentVersion · ecosystem	What you're running
fixedVersion	The version that fixes this finding
upgradeTarget	One target that clears everything for this package
safeTarget	The highest fix on your current major version
clearedBySafeTarget	How many findings that safer bump resolves
needsMajorUpgrade	Whether finishing the job crosses a major version
recommendation	"Upgrade now" / "this week" / "next opportunity" / "low priority"
severity · severityRank · cve · cwe	Standard triage fields
advisoryUrl · summary · published	The advisory itself

Supports npm, PyPI, Go, Maven, NuGet, Packagist, RubyGems, crates.io, Pub, Hex.

Input

{
  "packages": ["npm:lodash@4.17.15", "pypi:django@3.2.1", "npm:@babel/core@7.0.0"],
  "minSeverity": "MODERATE"
}

Or point it at a manifest:

{ "manifestUrls": ["https://raw.githubusercontent.com/you/repo/main/package-lock.json"] }

A lockfile is best — it lists what you actually run. A package.json range like ^4.0.0 doesn't say which version is installed, so ranges are resolved to their base version and that's an approximation.

Sample output

[
  {
    "package": "lodash",
    "ecosystem": "npm",
    "currentVersion": "4.17.15",
    "vulnerabilityId": "GHSA-29mw-wpgm-hmr9",
    "cve": "CVE-2020-28500",
    "severity": "MODERATE",
    "summary": "Regular Expression Denial of Service (ReDoS) in lodash",
    "fixedVersion": "4.17.21",
    "upgradeTarget": "4.17.21",
    "needsMajorUpgrade": false,
    "recommendation": "Upgrade at the next opportunity: lodash 4.17.15 → 4.17.21.",
    "advisoryUrl": "https://github.com/advisories/GHSA-29mw-wpgm-hmr9"
  }
]

The full per-package plan is in the UPGRADE_PLAN key-value record.

Typical uses

• Before a release — one run, one list of bumps.
• Scheduled audit — new advisories land daily against versions that were clean yesterday. This is a monitoring job, not a one-off.
• Inherited codebase — find out how bad it is, and what the cheapest safe move is.
• Client reports — an upgrade plan is a sellable deliverable; a CVE list isn't.

Pricing

$2.00 / 1,000 findings ($0.002 per result), plus a near-zero start fee. A typical project audit is well under a dollar. Never charged beyond maxItems.

⚠️ Read before you act

• A finding means your version is in a vulnerable range — not that you're exploitable. It doesn't prove your code reaches the affected function. Triage before you panic.
• Only pinned versions can be checked. A range in package.json is resolved to its base version, which may not be what's installed. Use a lockfile for accuracy.
• OSV sometimes lists a fix in a version line that was never released (a "not fixed here" placeholder). Where fixes span release lines, allFixedVersions shows every one so you can sanity-check the target before installing it.
• Advisories are filtered to your exact package. One advisory often covers a whole family (lodash, lodash-es, lodash.template) with different fixed versions — a real bug found during testing, where a sibling package's version could otherwise leak into your recommendation.

FAQ

• Do I need an API key? No.
• Which ecosystems? npm, PyPI, Go, Maven, NuGet, Packagist, RubyGems, crates.io, Pub, Hex.
• Does it scan private repos? No — it reads public manifest URLs or an explicit package list. Nothing is uploaded.
• Is it the same as npm audit? Same database family, different output: this gives you the cross-ecosystem upgrade plan, including the "stay on your major version" option that npm audit doesn't.

Related actors

• npm Package Info — maintenance health and abandonment risk for a package.
• GitHub Repository Scraper — activity and health of the upstream project.