Last Tuesday, one of my Go services got 14 Dependabot PRs in a single day.

All of them came from one CVE, and none of them affected the way our code actually runs in production. We still had to read the alerts, review the PRs, wait for CI, and merge changes. That was the moment I decided to stop using Dependabot for this workflow.

What finally broke it for me

The issue was CVE-2026-26958 in filippo.io/edwards25519.

The vulnerable method was (*Point).MultiScalarMult, which most projects never call. The fix was tiny. Still, Dependabot opened a huge number of PRs across Go repositories, including repos that only used unrelated parts of the module.

That pattern is what hurts: scary alerts, urgent tone, lots of mechanical work, and little to no practical security impact.

Why this happens

Dependabot evaluates risk at the module level. If a vulnerable symbol exists somewhere in that module, it flags everyone who depends on it.

It does not ask two key questions:

  1. Do you import the vulnerable package?
  2. Do you call the vulnerable function?

When those questions are ignored, teams get flooded with alerts that do not apply.

What I use now

I replaced Dependabot with two simple pieces:

  1. govulncheck in CI for real vulnerability detection in Go code.
  2. A scheduled dependency freshness job that updates and tests everything.

1) govulncheck in CI

govulncheck performs symbol-level analysis. It follows your call graph and reports vulnerabilities that are reachable from your code.

name: Vulnerability Check
on:
  schedule:
    - cron: '0 8 * * 1-5'  # Weekdays at 8 AM
  push:
    branches: [main]

jobs:
  vulncheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: stable
      - name: Install govulncheck
        run: go install golang.org/x/vuln/cmd/govulncheck@latest
      - name: Run govulncheck
        run: govulncheck ./...

When it finds a real issue, you get concrete call-site information instead of a generic dependency warning.

2) Weekly test run on latest deps

This job updates dependencies, runs tests, and shows drift when something breaks:

name: Dependency Freshness
on:
  schedule:
    - cron: '0 6 * * 1'  # Monday mornings

jobs:
  test-latest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: stable
      - name: Update all dependencies
        run: |
          go get -u ./...
          go mod tidy          
      - name: Run tests
        run: go test ./...
      - name: Report drift
        if: failure()
        run: |
          echo "Tests fail with latest dependencies."
          echo "Review go.sum diff for breaking changes."
          git diff go.sum

If tests pass, you can update with confidence. If tests fail, you investigate one real break instead of reacting to dozens of speculative alerts.

What changed for my team

After three months:

  • Security alerts dropped from around 20 per week to 1-2 per month.
  • Engineers stopped ignoring alerts because alerts became trustworthy.
  • Dependency maintenance time dropped to about 30 minutes per month.
  • We did not miss any real Go vulnerabilities that affected reachable code paths.

If you want to try this

  1. Add govulncheck to CI.
  2. Run it once manually and fix anything reachable.
  3. Add the scheduled update-and-test workflow.
  4. Disable Dependabot in repo settings, or use:
version: 2
updates: []
  1. Send failures and vuln findings to Slack or Teams.

Final thought

Security tooling should reduce risk, not generate background noise.

Dependabot is not useless, but in many Go repos it created too many false alarms for us. govulncheck plus scheduled dependency testing gave us a signal we can trust.