A Dependabot alternative that actually pings you when a CVE drops

A Dependabot alternative that actually pings you when a CVE drops

There is a particular email in everyone's GitHub inbox. Subject: "Dependabot opened pull request #312". Body: a bump from [email protected] to 4.17.21. Authored by a bot at 3:42 AM. Sitting in the queue with eight other identical PRs from the same bot. Last reviewed: never.

This is the failure mode of the current state of dependency-update tooling. The signal exists. It is broadcast on a channel nobody listens to. By the time a real CVE lands — the kind of bug that makes a paragraph in a security newsletter — the noise has trained you to swipe-archive the same email pattern without opening it. Dependabot is technically working. It is also technically a JIRA inbox.

This post is a tour of the alternatives, what each one trades off, and why I think the entire category has been targeting the wrong notification channel since 2019.

The category, briefly

When you ship code that has dependencies, three things can go wrong with those dependencies:

1. A version is outdated. New features and bug fixes exist upstream that you haven't pulled. Mostly cosmetic; sometimes performance-relevant.
2. A version contains a known CVE with a fix available. The package you're shipping has a published vulnerability and someone has cut a release that patches it.
3. A version contains a known CVE with no fix available yet. Worst case: you're vulnerable and there is nothing to upgrade to. Mitigation is application-level or removal-of-dependency.

The first failure mode is fine to handle async. Dependabot's automated PRs are a reasonable fit for it. The second and third — vulnerabilities with action required — are paging events. They're the ones every tool in this category claims to handle. None of them, in my experience, actually does, with one exception that's mostly under-marketed.

Dependabot

GitHub's built-in option. Free. Already on. Well integrated.

What it does: it scans your dependency files (package.json, requirements.txt, Gemfile, etc.) and either files PRs to bump versions on a schedule (Dependabot version updates) or files PRs / opens security advisories when GitHub's advisory database flags one of your dependencies (Dependabot security updates).

What it actually does in practice: it files a lot of PRs. Those PRs queue. The queue is reviewed roughly never, especially at solo-dev or small-team scale where the on-call rotation for "review the bot's PRs" doesn't exist. The signal quality on the security side is real — GHSA is a serious feed — but the delivery channel is wrong. A PR is a 24-hour-async signal; a CVE in a popular dependency is a same-day-paging signal.

Verdict: keep it on for cosmetic version bumps. Do not rely on it for security alerts unless you have a discipline of reviewing the GHSA-flagged PRs daily, which most teams do not.

Renovate

The OSS power-user option. Mend's Renovate is what Dependabot wants to be when it grows up: configurable schedules, grouped PRs, auto-merge for compatible updates, support for dozens of ecosystems beyond npm/pip/gem. Configuration via renovate.json lets you do things like "auto-merge any patch-level update on a green CI" and "group all React-related bumps into one weekly PR."

Same channel problem as Dependabot, though. It's a PR-filer at heart. If you set up Renovate carefully, you'll cut PR noise in half by grouping. You will not turn it into a paging system. The model is "manage the firehose," not "wake me up when something matters."

Verdict: the right pick if you want fine-grained control of bot-PR strategy. Same notification-channel problem as Dependabot.

Snyk

The commercial option. Solid product, particularly if you need policy controls, license compliance, container scanning, and IDE-integrated vulnerability surfacing all in one place.

Pricing is the wall for solo devs and small teams. Snyk's published pricing as of writing has a free tier limited to a small number of tests per month, then steps up to per-developer billing — typically $52/developer/month at the Team plan, with custom pricing above. For an enterprise that already buys this category, that's reasonable. For a solo dev with a Next.js app and three open-source libraries, it's not happening.

The notification side is more configurable than Dependabot's: you can route to Slack, email, Jira, or webhook. So if you do pay for Snyk, the "wake me up when a CVE drops" workflow is achievable — you just need to also be paying for Snyk.

Verdict: the right pick at the enterprise tier where the price is in noise. Wrong pricing model for the audience reading this post.

OSV-Scanner (CLI)

Google's open-source CLI. Reads OSV.dev's advisory feed (the same feed I'll mention in the next section) and matches it against your project's lockfile. Free, fast, AGPL-friendly.

The thing OSV-Scanner does not have is a heartbeat. It is a osv-scanner --lockfile=package-lock.json invocation that returns a list. You have to run it. You have to remember to run it. You have to plumb its output into something that pages you when a new advisory hits, because the tool itself does not. People who plumb osv-scanner into CI as a release gate get the most value — but a CI gate fires when you push, not when upstream publishes a CVE, which is the wrong moment.

Verdict: excellent matcher engine, missing a notification channel. Pair it with a cron and a Discord webhook and you've reinvented part of the wheel. Or use a tool that already did.

Netwarden Apps (the option that actually pings)

Disclosure: I'm writing this on the Netwarden blog. The reason this post exists is that this is the part of our product I'm most defensive of, because no one else is doing it the way I think it should be done. I'll be specific about what's in and what isn't.

When you initialize the Netwarden SDK in your app — @netwarden/apps for JavaScript / Node, netwarden-apps for Python — it reads your resolved lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lock, requirements.txt, poetry.lock, Gemfile.lock, go.sum, Cargo.lock, pom.xml, *.csproj, composer.lock) and reports the package + version pairs to the platform. A daily cron downloads OSV.dev's advisory feeds across eight ecosystems — npm, PyPI, RubyGems, Go modules, Cargo, Maven, NuGet, Composer — and runs the matcher.

When a match lands, three things happen at once:

1. A module_vulnerable finding is created for the project, severity-routed.
2. Email and mobile push notifications fire to the project's notification settings — the same channels that wake you up for an error spike or a downed host. It's the same alert pipeline. Not a separate inbox.
3. The advisory body, the affected version range, and the fixed version are written into the finding so the alert text contains a copy-paste line: npm install [email protected].

The third thing is the part I think the category got wrong. A CVE notification that does not include the upgrade path costs you ten minutes of context-switching to figure out what to do. A CVE notification that says "upgrade to 1.2.4" costs you thirty seconds. The thirty-second one is the one you actually act on.

What's in: daily cross-reference, eight ecosystems, push + email + webhook routing, the same alert preferences as the rest of the product, no extra integration to set up.

What's out: in-PR scanning (we don't gate your CI), license compliance, container image scanning, IDE plugin, malicious-package detection beyond what OSV.dev publishes. If you need any of those, look at Snyk or a SAST/SCA-suite vendor.

Pricing: Free tier, one project. $9/month after that for three projects. Self-hosted edition compiles into a single Bun binary that does the daily OSV pull on its own.

At-a-glance comparison

| Tool | Cost (solo) | Notification channel | Has upgrade line in alert? | Ecosystems | OSS? | |---|---|---|---|---|---| | Dependabot | Free | GitHub PR | No (linked) | npm, pip, gem, maven, nuget, gomod, composer, cargo, etc. | Closed source (GitHub) | | Renovate | Free (self-hosted) | GitHub PR | No (linked) | 60+ ecosystems | OSS (Apache 2.0) | | Snyk | Free tier limited; $52/dev/mo for Team | Slack / email / Jira / webhook | Sometimes | npm, pip, ruby, go, maven, php, .net, etc. | Mixed (CLI is OSS) | | OSV-Scanner | Free | None (CLI only) | Yes (in CLI output) | npm, pypi, gem, go, cargo, maven, nuget, composer, etc. | OSS (Apache 2.0) | | Netwarden Apps | Free 1 project; $9/mo for 3 | Email / push / webhook | Yes (copy-paste line) | npm, pypi, gem, go, cargo, maven, nuget, composer | Self-hosted is OSS-licensed; SaaS is closed |

The Snyk row is fair and pricing-cited. The OSV-Scanner row is reflecting that the CLI itself doesn't do delivery — you can wrap it in your own cron, but that's your problem to ship.

What I actually want from this category

If I were specifying the ideal tool from scratch, the requirements would be:

1. Channel matches urgency. A CVE in next with a published fix is a same-day signal. PR queue is the wrong inbox. Email or push is right.
2. Alert contains the action. "Upgrade lodash to 4.17.21" is the alert. Not "see https://nvd.nist.gov/long-link for details."
3. Daily re-check. Not "scan on push." Vulnerabilities are published on the upstream's clock, not yours.
4. Multi-ecosystem. A team with one Next.js frontend, a Python data pipeline, and a Go backend should not be running three different tools.
5. Pricing that doesn't punish solo devs. The buyer most likely to be vulnerable is the solo dev with one un-funded weekend project. Pricing models that exclude them are bad for the open-source ecosystem.

Netwarden Apps was built around those five requirements. Not because the others are bad — Renovate and OSV-Scanner are excellent at what they do — but because the channel and the action-in-alert are the two things I think matter most, and they're the two things most consistently missing.

If you've been ignoring Dependabot PRs for months and the thing you actually wanted was a push notification when a real CVE drops, the Apps features page shows the alert-channel side of how this works in production. The migration guide from Sentry covers the SDK install if you also want error tracking on the same SDK init. Pricing's at /pricing — free first project, $9/month after.

If you're already running Renovate and just need it to page you on the security findings, a webhook from Renovate's vulnerabilityAlerts into a service that handles delivery is a reasonable middle path. We're not going to talk you out of a setup that works for you.

But if the bot-PR inbox has trained you to swipe-archive your own security alerts — that's a fixable problem, and the fix is "use the channel that matches the urgency." That's the category I want to see in 2026.

Keep reading

• Announcing Netwarden Apps — the launch post for the product, including the OSV pipeline architecture.
• Sentry alternatives without per-event bills — same SDK, also fixes Sentry's pricing.
• How Netwarden's security wedge works — the host-side equivalent: CVE alerts for installed Linux packages.
• Apps features page — what's in, what isn't, with screenshots.