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.