Dependabot und Renovate öffnen dir automatisch Pull Requests, wenn eine neue Version einer Abhängigkeit verfügbar ist. Das war Thema in einem früheren Artikel dieser Reihe. Was diese beiden Tools nicht tun: verhindern, dass ein Pull Request mit einer neuen, verwundbaren Abhängigkeit gemerged wird, egal ob der PR von einem Bot oder einem Menschen kommt. Genau dafür gibt es GitHubs dependency-review-action. Sie sitzt als eigener Check im PR und blockiert den Merge, wenn eine eingeführte oder aktualisierte Abhängigkeit eine bekannte Schwachstelle oberhalb einer von dir gesetzten Schwelle mitbringt.

Was die Action tatsächlich prüft

Die Action vergleicht bei jedem pull_request-Event den Dependency-Graph des Base-Branch mit dem des Head-Branch. Aus der Differenz, also den neu hinzugekommenen oder geänderten Paketen, gleicht sie jede Abhängigkeit gegen die GitHub Advisory Database ab. Findet sie eine Schwachstelle mit einem Schweregrad, der die konfigurierte Schwelle erreicht oder überschreitet, schlägt der Check fehl und der PR bleibt blockiert, sofern du das als Required Check in den Branch-Protection-Regeln hinterlegt hast.

Das unterscheidet die Action von Dependabot Alerts, die dir Schwachstellen in bereits gemergtem Code melden. Hier greift die Prüfung vor dem Merge, am Punkt, an dem eine Änderung noch zurückgewiesen werden kann, ohne dass vorher etwas in den Main-Branch gelangt ist. Verwechsle das auch nicht mit manuellen Freigabe-Gates auf Environment-Ebene, wie sie in Pipelines für Produktionsdeployments üblich sind: Dort genehmigt ein Mensch einen Rollout. Hier entscheidet ein automatisierter Abgleich gegen eine Schwachstellendatenbank, ganz ohne manuellen Klick.

Den Workflow einrichten

Ein minimaler Workflow sieht so aus:

name: 'Dependency Review'
on: [pull_request]
permissions:
  contents: read
jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/dependency-review-action@v5

Ohne weitere Konfiguration greift der Default: Die Action prüft Schwachstellen ab dem Schweregrad low und schlägt entsprechend häufig fehl, weil auch niedrig eingestufte Advisories den Check triggern. Für die meisten Teams ist das zu aggressiv als Dauerzustand, deshalb lohnt sich ein expliziter Schwellenwert.

Schwelle und Ausnahmen setzen

      - uses: actions/dependency-review-action@v5
        with:
          fail-on-severity: moderate
          allow-ghsas: GHSA-xxxx-xxxx-xxxx
          fail-on-scopes: runtime

Für wiederkehrende Einstellungen über mehrere Repositories hinweg gibt es die Auslagerung in eine eigene Datei:

      - uses: actions/dependency-review-action@v5
        with:
          config-file: './.github/dependency-review-config.yml'

Lizenzen als zweite Prüfdimension

Neben Schwachstellen prüft die Action standardmäßig auch Lizenzen (license-check: true). Über allow-licenses und deny-licenses legst du mit SPDX-Bezeichnern fest, welche Lizenzen ein neu eingeführtes Paket haben darf oder explizit nicht haben darf, etwa um copyleft-lastige Lizenzen aus einem kommerziellen Produkt fernzuhalten. Wer nur den Schwachstellen-Check will, schaltet das mit license-check: false ab. Das ist ein eigenes Thema für sich, hier nur der Hinweis, dass beide Prüfungen im selben Schritt laufen und getrennt konfigurierbar sind.

Voraussetzungen und Grenzen

Für öffentliche Repositories läuft die Action ohne Zusatzlizenz. Für private Repositories brauchst du GitHub Advanced Security, auf Enterprise Server zusätzlich GitHub Connect. Das ist keine Fußnote, sondern der Grund, warum der Check in privaten Repos ohne die passende Lizenz gar nicht erst grün oder rot wird, sondern schlicht nicht läuft.

Die Prüfung deckt außerdem nur die von GitHub unterstützten Ökosysteme im Dependency-Graph ab und arbeitet auf Basis der Manifest- beziehungsweise Lockfile-Änderungen im Diff. Transitive Abhängigkeiten, die sich ohne sichtbare Änderung an einer Manifestdatei verschieben, etwa durch einen Lockfile ohne Versionspins, fallen je nach Paket-Ökosystem unterschiedlich zuverlässig in den Vergleich. Für ein verlässliches Ergebnis brauchst du also ein Lockfile, das tatsächlich commitet wird, nicht nur ein lose formuliertes Manifest.

Einordnung

Dependabot und Renovate sorgen dafür, dass Updates überhaupt als PR entstehen. Die Dependency Review Action sorgt dafür, dass ein PR mit einer riskanten Abhängigkeit nicht durchrutscht, egal wer ihn geöffnet hat. Beide Mechanismen ergänzen sich, ersetzen sich aber nicht: Ohne Update-Automatisierung bleiben veraltete Abhängigkeiten liegen, ohne PR-Gate kann trotzdem jede neu hinzugefügte Abhängigkeit mit bekannter Schwachstelle den Weg in den Main-Branch finden. Wie sich das in eine vollständige Build-Pipeline mit weiteren Kontrollpunkten einfügt, ist eine Prozessfrage, die auf digital-business.blog aus einer anderen Perspektive beleuchtet wird.