Múlt kedden az egyik Go szolgáltatásom egy nap alatt 14 Dependabot PR-t kapott.

Ugyanahhoz az egy CVE-hez tartoztak, de a mi futó kódunkat valójában nem érintették. Ettől még végig kellett nézni az alertet, reviewzni a PR-eket, megvárni a CI-t, majd mergelni. Itt döntöttem el, hogy ebben a folyamatban nálunk ennyi volt a Dependabot.

Mi volt az utolsó csepp

A konkrét eset a CVE-2026-26958 volt a filippo.io/edwards25519 modulban.

A sebezhetőség a (*Point).MultiScalarMult metódust érintette, amit a legtöbb projekt nem hív. A javítás is pici volt. Ennek ellenére a Dependabot rengeteg PR-t nyitott Go repókban, még olyanokban is, ahol csak a modul más részeit használták.

Ez a gond a gyakorlatban: ijesztő alert, sürgős hangnem, sok admin munka, kevés valódi biztonsági nyereség.

Miért történik ez

A Dependabot modul szinten gondolkodik. Ha a modulban valahol van sebezhető szimbólum, minden függő repóra riasztást küld.

Két fontos kérdést nem tesz fel:

  1. Importálod egyáltalán az érintett csomagot?
  2. Meghívod az érintett függvényt?

Ha ezek kimaradnak, pillanatok alatt zaj lesz a rendszerből.

Mit használok most

A Dependabotot két egyszerű dologra cseréltem:

  1. govulncheck a CI-ban, hogy a Go kód valódi kockázatait lássam.
  2. Egy ütemezett függőségfrissítő és tesztelő workflow.

1) govulncheck a CI-ban

A govulncheck szimbólum szinten elemez. Követi a hívási gráfot, és azt jelzi, ami tényleg elérhető a kódodból.

name: Vulnerability Check
on:
  schedule:
    - cron: '0 8 * * 1-5'  # Hétköznapokon reggel 8-kor
  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 ./...

Ha talál valós problémát, konkrét hívási pontokat kapsz, nem csak egy általános figyelmeztetést.

2) Heti teszt a legfrissebb függőségekkel

Ez a workflow frissíti a függőségeket, futtatja a teszteket, és megmutatja, hol csúszik szét valami:

name: Dependency Freshness
on:
  schedule:
    - cron: '0 6 * * 1'  # Hétfő reggel

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 "A tesztek elbuknak a legfrissebb függőségekkel."
          echo "Nézd meg a go.sum diffet a törő változásokhoz."
          git diff go.sum

Ha zöld, nyugodtan frissítesz. Ha piros, egy valós törést vizsgálsz, nem sok tucat bizonytalan alertet.

Mit hozott ez nálunk

Három hónap után:

  • A biztonsági alertek kb. 20/hétről 1-2/hónapra estek vissza.
  • A csapat újra komolyan veszi az alertet, mert megbízhatóbb lett a jelzés.
  • A függőségkarbantartás havi ráfordítása nagyjából 30 perc.
  • Nem maradt ki olyan valódi Go sebezhetőség, ami elérhető lett volna a kódunkból.

Ha kipróbálnád

  1. Tedd be a govulncheck lépést a CI-ba.
  2. Futtasd le kézzel, és javítsd, amit tényleg elér a kód.
  3. Add hozzá az ütemezett frissítés plusz teszt workflow-t.
  4. Kapcsold ki a Dependabotot a repo beállításaiban, vagy használd ezt:
version: 2
updates: []
  1. Küldd a hibákat és találatokat Slackre vagy Teamsre.

Zárás

A biztonsági eszköz jó esetben csökkenti a kockázatot, nem növeli a háttérzajt.

A Dependabot nem rossz eszköz, de nálunk túl sok téves riadást adott. A govulncheck és az ütemezett függőségtesztelés használhatóbb, hihetőbb jelzést ad.