Schalten wir Dependabot ab

• Es wird kritisiert, dass die übermäßigen Benachrichtigungen von Dependabot Entwicklern mehr Zeit rauben, als sie bei der Behebung realer Sicherheitsprobleme helfen
• Wie ein Fall im Go-Ökosystem zeigt, werden tausende PRs und Warnungen selbst für nicht betroffene Repositories erzeugt, was für Verwirrung sorgt
• Mit einer auf govulncheck basierenden GitHub Action lässt sich nur tatsächlich verwundbarer Code erkennen und unnötige Warnungen lassen sich entfernen
• Abhängigkeits-Updates lassen sich sicherer und effizienter über regelmäßige Tests und die Prüfung aktueller Versionen verwalten als über automatisierte PRs
• Dieser Ansatz ist wichtig, um Warnmüdigkeit (alert fatigue) zu verringern und die Belastung von Open-Source-Maintainern zu reduzieren

---

Probleme mit Dependabot

• Dependabot erzeugt große Mengen an Sicherheitswarnungen und automatischen PRs, wodurch es für Entwickler schwer wird, wirklich wichtige Probleme zu erkennen
  • Schon eine kleine Änderung am Go-Paket filippo.io/edwards25519 führte zu tausenden PRs
  • Selbst nicht betroffene Repositories (wie Wycheproof) erhielten fehlerhafte Sicherheitswarnungen
• Die Warnungen enthalten irreführende CVSS-Werte und niedrige Kompatibilitätsindikatoren, was unnötige Verunsicherung erzeugt
• Diese Benachrichtigungsflut wird als Ursache dafür gesehen, dass Vertrauen und Effizienz bei der Sicherheitsreaktion sinken

Eine Alternative mit govulncheck

• Die Go Vulnerability Database bietet feingranulare Metadaten auf Versions-, Paket- und Symbol-Ebene
  • Beispielsweise betrifft die Schwachstelle GO-2026-4503 nur das Symbol Point.MultiScalarMult
• govulncheck erkennt per statischer Analyse nur tatsächlich aufrufbaren verwundbaren Code
  • In Kombination mit go mod why lässt sich genau bestimmen, ob indirekte Abhängigkeiten tatsächlich relevant sind
  • Selbst wenn eine Schwachstelle existiert, wird keine Warnung ausgegeben, wenn der Code das betreffende Symbol nicht aufruft
• Die Integration ist über die CLI (govulncheck -json) oder die Go-API (golang.org/x/vuln/scan) einfach möglich

Ersatz durch GitHub Actions

• Statt Dependabot kann eine govulncheck GitHub Action eingerichtet werden, die täglich automatische Scans ausführt
  • Benachrichtigungen werden nur versendet, wenn echte Schwachstellen gefunden werden
  • Da keine automatischen PRs erzeugt werden, können sich Entwickler auf wichtige Sicherheitsprobleme konzentrieren
• Weniger Fehlwarnungen helfen, Warnmüdigkeit bei Sicherheitsmeldungen (alert fatigue) zu reduzieren und die Qualität der Reaktion zu verbessern
• Auch das Problem unnötiger PRs an Open-Source-Maintainer entfällt

Verwaltung von Abhängigkeits-Updates

• Abhängigkeiten sollten gesammelt entsprechend dem Entwicklungszyklus jedes Projekts verwaltet werden
  • Tägliche Tests gegen die neuesten Versionen sind sinnvoll, tatsächliche Updates sollten jedoch nur bei Bedarf erfolgen
  • In Go kann mit go get -u -t ./..., bei npm mit npm update gegen die neuesten Versionen getestet werden
• Dieser Ansatz stellt sowohl schnelle Reaktion auf Sicherheitslücken als auch Stabilität sicher
  • Durch Tests mit aktuellen Versionen lassen sich Kompatibilitätsprobleme früh erkennen
  • Gleichzeitig wird verhindert, dass Abhängigkeiten mit Schadcode sofort ausgerollt werden
• Mit geomys/sandboxed-step lässt sich die Ausführung in CI-Umgebungen über gVisor isolieren

Fazit und Hintergrund der Unterstützung

• Die Automatisierung von Dependabot erzeugt oft eher Lärm (noise) als Sicherheit
• Ein auf govulncheck und regelmäßigen Tests basierender Ansatz ist eine präzisere und nachhaltigere Methode für Sicherheitsmanagement
• Die Open-Source-Wartung des Autors wird über die Organisation Geomys durch Sponsoring von Ava Labs, Teleport, Tailscale, Sentry und anderen getragen
• Dieses Modell trägt zu einer stabilen Pflege des Open-Source-Ökosystems und einer höheren Sicherheitsqualität bei

[GN⁺]

Hacker-News-Kommentare

• Dependabot hat einen gewissen Wert
  Aber ein Tool, das nur Versionsnummern mit einer Schwachstellen-Datenbank vergleicht, kann nicht beurteilen, ob der konkrete Code dieser Schwachstelle tatsächlich ausgesetzt ist, und erzeugt daher viel Rauschen
  Ein Tool, das mich zuletzt beeindruckt hat, ist CodeQL. Es lässt sich in GitHub Advanced Security ausführen und verfolgt den tatsächlichen Codefluss, wobei der gesamte Pfad visuell dargestellt wird, über den Eingabewerte zu einer riskanten Verwendung führen
  Dadurch bekommt man Informationen, mit denen sich echte Korrekturen vornehmen lassen, und es gibt weniger False Positives. Natürlich kann es gerade in dynamischen Sprachen wie Python Code geben, der der Erkennung entgeht, aber in den meisten Fällen ist es ausreichend nützlich
  • Früher hat CodeQL dem Projekt geholfen, aber zuletzt war es so nervig, dass wir es im Team abgeschaltet haben
    Es entstanden Kommentare in der Art, nutzlose Zwischenvariablen hinzuzufügen, nur um CodeQL-Warnungen zu umgehen. Es fühlt sich wie ein auf die Daten überangepasstes Tool an
  • Der Aussage „Es gibt fast keine False Positives“ kann ich schwer zustimmen. Nach dem Satz von Rice ist eine derart perfekte Analyse unmöglich
  • Meiner Erfahrung nach produziert CodeQL viele False Positives, und weil es sich lokal nicht einfach ausführen lässt, entsteht Vendor Lock-in
  • Nur weil man eine Abhängigkeitsversion anhebt, ist die Sicherheit nicht automatisch besser. Eine neue Version kann auch neue Schwachstellen mitbringen
• Bei NPM-Paketen tauchen viel zu viele ReDoS-Warnungen auf. Meistens betreffen sie Pakete, die nur im Client-Code verwendet werden, aber es kommen zu viele Warnungen, die mit dem Backend nichts zu tun haben. Client-seitiges ReDoS ist für uns bedeutungslos
  • Eigentlich halte ich DoS nicht für eine Sicherheitslücke, sondern für ein Verfügbarkeitsproblem. Es ist zwar eines der CIA-Ziele der Sicherheit, aber praktisch ist es eher ein Betriebsproblem. DoS als Sicherheitsproblem einzuordnen, ist nur ein historisches Relikt
  • Ich pflege das Paket debug, und es gibt viel zu viele unsinnige ReDoS-Meldungen. Manchmal wird dafür sogar eine CVE registriert, sodass ich am liebsten ganz aus dem JS-Ökosystem aussteigen würde
  • Bei AI-Code-Review-Tools habe ich ein ähnliches Problem. Obwohl das Tool lokal mit Benutzerrechten läuft, fordert es einen auf, Eingaben unnötig zu sanitizen. Am Ende ist das nur Zeitverschwendung
  • Wir haben dasselbe Problem. Vor allem ReDoS-Warnungen aus Dev-Dependencies erzeugen unnötig viel Lärm
  • ReDoS ist ein Bug der Regex-Engine, und Engines wie V8 liefern noch immer keine sichere Regex-Engine als Standard mit
• Govulncheck ist eines der besten Features im Go-Ökosystem
  Wir verwenden eine GitHub Action, die benachrichtigt, wenn in einem PR ein verwundbarer Aufruf hinzugefügt wird.
  Zusammen mit dem automatischen Mergen von Dependabot ist das auch für die Pflege von JS-Codebasen eine brauchbare Kombination
  • Auch Govulncheck ist nicht perfekt. Es gibt False Positives, und es gibt keine Möglichkeit, bestimmte Schwachstellen per CVE-Nummer auszuschließen
• Dependabot ist nützlich, erinnert einen aber gleichzeitig jeden Tag daran, wie wichtig es ist, Abhängigkeiten zu minimieren
  • Bei mir beginnt der Tag auch oft damit, morgens Dependabot-PRs abzuarbeiten.
    Wenn die Tests gut genug sind, entdeckt man in neuen Versionen auch mal Bugs, aber dabei entstehen manchmal auch Open-Source-Beiträge. Es ist lästig, schafft aber gute Gewohnheiten
  • Stimme ich zu. Ich habe nicht viele Projekte, aber Dependabot ist ziemlich brauchbar
• Es wäre gut, wenn Dependabot statt per E-Mail als Tab im Repository verwaltet würde.
  E-Mail-Benachrichtigungen nerven, und ich mag es auch nicht, wenn sich PRs stapeln. Ich würde das lieber gezielt in bestimmten Zeitfenstern erledigen
  • Mit der Konfiguration in dependabot.yml lassen sich Ausführungsintervall und Anzahl der PRs steuern
    Siehe die offizielle Dokumentation
  • Man kann automatische PRs auch abschalten und sie nur bei Bedarf manuell erstellen.
    Man kann die Probleme auch direkt selbst beheben und so die Zahl der Issues verringern
  • Mit der Refined-GitHub-Erweiterung wird die Standardansicht etwas aufgeräumter.
    Persönlich empfehle ich Renovate. Es unterstützt mehr Sprachen und Optionen für automatisches Mergen
• Der govulncheck-Ansatz von Go, also das Verfolgen tatsächlicher Aufrufpfade, sollte in jedem Ökosystem Standard sein
  Das Grundproblem bei Dependabot ist, dass Abhängigkeitsmanagement mit einem Sicherheitsproblem verwechselt wird.
  Schwachstellen in Funktionen, die nie aufgerufen werden, sind kein Sicherheitsproblem, sondern Rauschen
  In Python wirkt pip-audit --desc auf mich besser als Dependabot.
  Bis es perfekte statische Analyse gibt, könnten vierteljährliche manuelle Prüfungen sogar sicherer sein
  • Aber wenn Kunden den Code mit solchen Tools scannen, glauben sie die Antwort „Diese Funktion wird nicht verwendet“ nicht.
    Genau hier entsteht die Kluft zwischen tatsächlicher Sicherheit und Sicherheitspraktiken
  • Auch die Frage „Wenn ihr sie nicht nutzt, warum ist die Funktion dann überhaupt noch im Code?“ ist berechtigt
• Ich verstehe nicht, warum die Branche solche oberflächlichen Security-Scanner akzeptiert hat
  Die meisten CVEs haben in der Praxis keine Auswirkungen, trotzdem versuchen Unternehmen krampfhaft, die Zahl der Schwachstellen in Container-Images auf 0 zu bringen
  Dazu kommt, dass mit aktualisierten Abhängigkeiten oft auch neue CVEs dazukommen. Die meiste Software bekommt schließlich keine Backport-Patches
  • Ich verstehe nicht ganz, wie der Teil mit den „fehlenden Backports“ mit dem vorigen Satz zusammenhängt
• Der Vorteil von Dependabot oder Renovate ist, dass sie sprachunabhängig funktionieren
  Je mehr Repositories man hat und je vielfältiger die verwendeten Sprachen sind, desto unrealistischer ist es, überall einen perfekten CI-Workflow einzubauen
  Es ist nicht perfekt, aber meiner Meinung nach immer noch viel besser, als gar nichts zu tun
• Ich frage mich, woher der CVSS-Score bei Dependabot kommt.
  Werden CVEs automatisch erzeugt?
  • CVSS ist ein Worst-Case-Score und spiegelt das tatsächliche Risiko nicht wider.
    GitHubs Schwachstellen-Datenbank konzentriert sich eher auf Quantität als auf Qualität, und Dependabot arbeitet wie ein unintelligenter Spam-Benachrichtiger
  • Man kann sich sogar fragen, ob der Bug überhaupt eine echte Schwachstelle ist.
    Wenn das Problem nur auftritt, wenn man eine Funktion falsch aufruft, hat der Code wahrscheinlich ohnehin schon nicht korrekt funktioniert
• Auch unser Unternehmen hat ein ähnliches Problem.
  Das Scannen von GCP-Container-Images überschüttet Vanta mit einer Flut von CVE-Warnungen, aber die meisten davon lassen sich nicht beheben oder betreffen Pfade, die in Wirklichkeit gar nicht genutzt werden
  Ich frage mich, ob es Tools gibt, die so eine kontextbasierte Filterung leisten
  • Wir verwenden im Unternehmen Aikido Code. Es versucht mithilfe von AI, die tatsächlichen Auswirkungen von Schwachstellen herauszufiltern.
    Die Ergebnisse sind insgesamt positiv, aber bei einer großen Codebasis mit vielen Abhängigkeiten ist es weiterhin schwierig, die Zahl der CVEs zu senken