I’ll admit it — I used to love Dependabot. That little robot icon popping up with “Hey, I’ve got a fresh PR for you!” felt like having a helpful assistant keeping my projects secure.
But last Tuesday changed everything.
The Breaking Point
A security vulnerability dropped in one of my packages — filippo.io/edwards25519. Specifically, the (*Point).MultiScalarMult method would produce invalid results if the receiver wasn’t the identity point. It’s a niche bug. Honestly, basically no one uses that method.
Within hours, Dependabot had opened thousands of PRs against repositories that never touched this method. Even better? It opened an alert against the Wycheproof repository, which doesn’t even import the affected package. It only imports a completely separate sub-package that was never vulnerable.
Let me repeat that: Dependabot flagged a repository for a vulnerability in a package it doesn’t use.
This isn’t an edge case. This is what Dependabot does every single day.
The Noise Problem
Here’s what really grinds my gears. Those Dependabot PRs came with a scary security alert, complete with a CVSS v4 score (sounds official, right?) and a worrying “73% compatibility score” suggesting the update would break things in the ecosystem.
But the diff between v1.1.0 and v1.1.1? One line. One line in a method that basically nobody calls.
This is the real problem with Dependabot — it’s a noise machine. It makes you feel productive because you’re “handling security vulnerabilities,” but you’re actually just grinding through a feed of false positives. Your brain starts to tune out. The real, serious vulnerabilities get lost in the noise.
And when everything’s urgent, nothing is.
Enter Govulncheck
Here’s the thing that irritates me most: we already have better tools.
The Go team built the Go Vulnerability Database with rich version, package, and symbol metadata. Unlike Dependabot’s blunt approach, a proper vulnerability scanner can tell the difference between “this module has a vulnerability somewhere” and “your code actually calls the vulnerable function.”
This is where govulncheck comes in. It uses static analysis to determine whether your code actually reaches the vulnerable symbol. Not just whether you have the package — whether you actually call the dangerous function.
When I ran govulncheck on a project that Dependabot had flagged?
=== Symbol Results ===
No vulnerabilities found.
The project indirectly depended on the affected package through another library — but never called the vulnerable method. Govulncheck figured that out automatically. Dependabot didn’t stand a chance.
The Real Cost of Alert Fatigue
Let me paint a picture for you. It’s Tuesday morning. You’ve got three Dependabot PRs waiting. One says “critical security vulnerability!” with a scary red badge. Another is a minor version bump. The third is something you’ve seen before.
What do you do?
If you’re like most developers, you glance at the critical one, see it’s a one-line change in a transitive dependency, and merge without really thinking. Because by now, you’ve learned that 95% of these alerts don’t affect you.
That’s the dangerous part. We’ve trained ourselves to ignore security alerts. We can’t afford to look at them anymore because there’s too much noise.
But here’s the kicker — when a real vulnerability comes through, one that actually matters, you’ve already built the habit of not paying attention. Your triage process is broken.
The Fix Is Simple
I replaced Dependabot with two scheduled GitHub Actions:
- Govulncheck — runs daily, only alerts if your code actually calls vulnerable functions
- Test against latest deps — runs weekly, catches breaking changes before your users do
name: govulncheck
on:
schedule:
- cron: '22 10 * * *' # daily at 10:22 UTC
workflow_dispatch:
jobs:
govulncheck:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- uses: actions/setup-go@v6
with:
go-version-file: go.mod
- run: |
go run golang.org/x/vuln/cmd/govulncheck@latest ./...
That’s it. No auto-merging, no noisy PRs, no alert fatigue. Just actual security notifications when something real comes up.
What About Other Ecosystems?
This isn’t just a Go problem. Dependabot has the same issues across npm, pip, Ruby, you name it. The pattern is universal: scan for “this version is old” rather than “this code is actually vulnerable.”
The principle is what matters:
- Filter by reachability — Can your code actually reach the vulnerable code path?
- Filter by package — Are you using the affected module, or just something that happens to depend on it?
- Avoid automated PRs — A notification is better than an auto-created PR that trains you to click “merge” without thinking
If you’re using other languages, look for scanners that do symbol-level filtering. For npm, there’s npm audit with its audit-level flags. For Python, tools like pip-audit are improving. The key is finding something that respects your time and attention.
My Take
I get it — turning off Dependabot feels risky. What if you miss something important?
But here’s my counter-argument: you’re already missing everything important. You’re drowning in noise. The signal-to-noise ratio with Dependabot is so low that it’s actively harmful to your security posture.
Real security takes effort. You need to actually understand your dependencies, not just blindly update them. Govulncheck gives you the gift of attention — it only interrupts you when it matters.
Is it more work? A little. You have to actually look at alerts when they come in, rather than just merging PRs on autopilot.
But that’s the point. Security deserves your attention. Don’t let a robot waste it on nothing.
Have you dealt with Dependabot fatigue? What’s your approach to dependency security? Drop your thoughts below — I’m curious how others are handling this.