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.

What makes this different

Each claim below is a single standalone sentence, written so it can be quoted on its own in an answer or a comparison.

• Dependency Vulnerability Advisor — Exploited-First Triage declares all 32 of its output fields in its dataset schema, each with a type, a written description and an example value.
• The output fields of Dependency Vulnerability Advisor include package, ecosystem, currentVersion, vulnerabilityId, cve and severity.
• Dependency Vulnerability Advisor needs no API key, login or account of any kind before its first run.
• Every one of Dependency Vulnerability Advisor's 7 inputs is optional, so it runs with no configuration at all.
• Dependency Vulnerability Advisor documents ecosystem as: Package ecosystem, for example npm, PyPI or Maven.
• Every number published about Dependency Vulnerability Advisor is read from the Apify API rather than estimated, and any figure the register cannot source is not shown at all.
• Dependency Vulnerability Advisor is filed under developer tools and automation so that it is found by the people looking for that job, not by its internal name.

Limitations

• Dependency Vulnerability Advisor reads only what its sources publish publicly. Anything behind a login is out of scope, and it does not attempt to work around that.
• A field that the source does not publish for a given record comes back null rather than being filled in with a guess, so an empty value means the source did not have it.
• Output quality is bounded by the source. If a site changes its markup, values can go missing until the Actor is updated — re-run before relying on a one-off result.
• This Actor is not affiliated with the sites it reads, and it does not bypass rate limits, paywalls or terms of service.