GitHub-Projekte absichern – mit Dependabot Abhängigkeiten automatisch aktualisieren

Veraltete Abhängigkeiten? Mit Dependabot hältst du deine Abhängigkeiten in Github aktuell.

Wie im ersten Teil zu Renovate beschrieben, können veraltete Abhängigkeiten in Softwareprojekten zu Sicherheitslücken, Zeitdruck und langfristigem Schuldenaufbau führen. Automatisierte Dependency-Updates schaffen hier Abhilfe. Während Renovate vor allem durch Flexibilität und Plattformunabhängigkeit überzeugt, bietet Dependabot eine schlanke GitHub-native Lösung mit Fokus auf Sicherheit und einfacher Integration.

Dependabot erklärt: So nimmst du Sicherheits-Updates in die eigene Hand 

Dependabot ist ein direkt in GitHub-integriertes Tool, das regelmäßig prüft, ob Abhängigkeiten im Projekt aktualisiert werden können. Sobald neue Versionen verfügbar sind, erstellt es automatisch Pull Requests (PRs) mit den relevanten Änderungen. Es unterstützt dabei viele gängige Paketmanager und bietet Sicherheitswarnungen direkt in GitHub.

Diese Features machen Dependabot besonders nützlich: 

Unterstützt eine breite Auswahl an Projektmanagern: Maven, npm, Gradle, NuGet, pip, Docker etc.

Erstellt automatisch Pull Requests bei Updates

Erkennt Sicherheitslücken (CVEs) direkt im Projekt

Steuerung über .github/dependabot.yml und Github Actions.

In 5 Minuten startklar: So aktivierst du Dependabot in deinem Projekt

Dependabot wird aktiviert, indem du eine .github/dependabot.yml-Datei im Repository anlegst.

Hier ein Beispiel für ein Maven-Projekt, das ein privates Nexus-Repository nutzt und Spring-Abhängigkeiten zusammenfasst:

version: 2
registries:
my-nexus: # Definiert ein privates Repository mit Authentifizierung
type: maven-repository
url: https://nexus.example.com/repository/maven-public/
username: ${{secrets.NEXUS_USERNAME}}
password: ${{secrets.NEXUS_PASSWORD}}

updates:
– package-ecosystem: „maven“ # Der verwendete Paketmanager
directory: „/“ # Verzeichnis mit der pom.xml
registries:
– my-nexus
schedule:
interval: „weekly“ # Wie häufig nach Updates gesucht wird
open-pull-requests-limit: 5 # Maximal 5 offene PRs gleichzeitig
groups:
spring-dependencies: # Gruppiert alle Spring-Abhängigkeiten
patterns:
– „org.springframework.*“
– „org.springframework.boot.*“

So gelingt dir das sichere Auto-merge mit Dependabot

Im Gegensatz zu Renovate, wo sich Automerge-Verhalten direkt in der Konfigurationsdatei steuern lässt, ist der Weg bei Dependabot etwas komplexer. Automatisches Mergen ist zwar möglich – allerdings nur über eine Kombination aus Repository-Einstellungen, GitHub Actions und ggf. Branch Protection Rules.

Wie bereits in Teil 1 erwähnt: Auch hier gilt – für sicheres automatisches Mergen ist eine gute Testabdeckung unerlässlich.

So funktioniert Automerge mit Dependabot:

Auto-Merge in den Repository-Einstellungen aktivieren

GitHub Action erstellen, die den Auto-Merge auf PR-Ebene aktiviert

Optional: Branch Protection Rules festlegen, damit nur stabile Änderungen übernommen werden (z.B. erfolgreiche Builds oder Tests). 

Beispielkonfiguration für die GitHub Action:

name: Dependabot Auto-Merge

on: pull_request # Wird bei jedem Pull Request getriggert
permissions:
contents: write
pull-requests: write

jobs:
automerge:
runs-on: ubuntu-latest
if: ${{ github.actor == ‚dependabot[bot]‘ }} # Nur für PRs von Dependabot

steps:
– name: Fetch Dependabot metadata
id: metadata
uses: dependabot/fetch-metadata@v2 # Liefert Metainformationen über den PR
with:
github-token: ${{ secrets.GITHUB_TOKEN }}

– name: Auto-merge patch and minor (except quarkus)
if: |
steps.metadata.outputs.update-type != ‚version-update:semver-major‘ &&
!contains(steps.metadata.outputs.dependency-names, ‚quarkus‘)
run: gh pr merge –auto –merge „$PR_URL“ # Aktiviere Auto-Merge für den PR per GitHub CLI
env:
PR_URL: ${{ github.event.pull_request.html_url }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Diese Action steuert – wie in Teil 1 bei Renovate bereits gezeigt – das automatische Mergen für Patch- und Minor-Updates, mit Ausnahme von Quarkus.

Renovate oder Dependabot? Diese Unterschiede solltest du kennen

Renovate und Dependabot verfolgen das gleiche Ziel – die Automatisierung von Dependency-Updates –, unterscheiden sich aber in Plattformunterstützung und Konfigurierbarkeit.

Plattformunterstützung

Renovate läuft auf GitHub, GitLab, Bitbucket und Azure DevOps.

Dependabot ist GitHub-nativ. Für andere Plattformen gibt es nur das manuell betreibbare dependabot-core: (https://github.com/dependabot/dependabot-core). Vorteil für GitHub-User: Sicherheitslücken werden automatisch erkannt und verwaltet – ohne zusätzliche Tools.

Konfigurierbarkeit

Renovate erkennt verwendete Ökosysteme automatisch und erstellt bei Bedarf eine initiale Konfiguration. Zudem lassen sich komplexe Regeln wie Automerge-Verhalten, Paket-Ausschlüsse oder SemVer-Grenzen direkt in der Konfigurationsdatei festlegen.

Dependabot bietet nur eingeschränkte Möglichkeiten zur Steuerung über die dependabot.yml. Außerdem müssen alle Paketmanager und die dazugehörige Verortung im Repository manuell gepflegt werden. 

Bei Dependabot hingegen lassen sich solche Regeln nicht in der YAML-Datei abbilden. Stattdessen müssen sie über GitHub Actions und Repository-Einstellungen ergänzt werden.

Eine ausführliche Vergleichstabelle findet sich unter: https://docs.renovatebot.com/bot-comparison/

Blick in die Praxis: So hat Dependabot unser Java-Projekt modernisiert

In einem Projekt mit einigen veralteten Java-Abhängigkeiten haben wir Dependabot eingeführt, um das System schrittweise zu modernisieren. Drei Dinge haben sich besonders bewährt:

Limitierung der gleichzeitigen PRs
Dank der open-pull-requests-limit-Einstellung wurden wir nicht mit Updates überflutet, sondern konnten sie kontrolliert abarbeiten.

Automatisch generierte Changelogs
Jede PR enthielt den Changelog zur neuen Version – das hat die Bewertung und das Testing enorm vereinfacht.

Dependabot Alerts für Sicherheitsprobleme
Sicherheitslücken in Bibliotheken wurden direkt im GitHub UI angezeigt – zusammen mit einem passenden Fix-PR von Dependabot.

Da wir eine geringe Testabdeckung hatten, verzichteten wir bewusst auf Auto-Merge und prüften die PRs manuell.

Fazit: Der manuelle Mehraufwand hat sich gelohnt– der Überblick und die Sicherheit im Projekt nahmen deutlich zu.

Fazit: Wann lohnt sich Dependabot wirklich – und wann nicht?

Dependabot ist ideal für alle GitHub-Projekte, bei denen Sicherheit und klare Automatisierung im Vordergrund stehen. Besonders für kleinere Projekte oder Teams ohne komplexe CI/CD-Setups kannst du damit schnell strukturierte Updates und CVE-Monitoring integrieren – ganz ohne zusätzliche Tools.

Wenn du allerdings mehr Kontrolle brauchst – z. B. fein abgestimmte Automerge-Regeln, mehrere Plattformen oder intelligente Gruppierungen – bietet Renovate deutlich mehr Flexibilität.

Der Beitrag GitHub-Projekte absichern – mit Dependabot Abhängigkeiten automatisch aktualisieren erschien zuerst auf Business -Software- und IT-Blog – Wir gestalten digitale Wertschöpfung.