Stackwatch und Dependabot: Was der Unterschied ist

Das Wichtigste in drei Sätzen

Dependabot ist kostenlos, in GitHub eingebaut und gut darin, Pakete aus deinen Lockfiles aktuell zu halten. Lücken in der Runtime selbst, also im PHP-Interpreter, in Node.js oder Python, meldet es nicht, weil der Dependency Graph von GitHub Dockerfiles nicht auswertet. Stackwatch schließt genau diese Lücke und ersetzt Dependabot nicht.

Was Dependabot prüft

Dependabot hat drei Funktionen, die oft in einen Topf geworfen werden:

• Dependabot Alerts melden bekannte Lücken in Abhängigkeiten. Grundlage ist der Dependency Graph, also Manifeste und Lockfiles wie composer.lock, package-lock.json, requirements.txt oder poetry.lock.
• Security Updates öffnen Pull Requests, die eine verwundbare Abhängigkeit auf eine gefixte Version heben.
• Version Updates halten Abhängigkeiten generell aktuell, auch Docker-Images in Dockerfile und docker-compose.yml.

Der Haken steckt im Detail: Version Updates für Docker heben Image-Tags an, haben aber nichts mit Sicherheitslücken zu tun. Security Updates für Docker sind laut GitHub-Doku nicht unterstützt, und der Dependency Graph kennt Dockerfiles nicht. Dazu kommt: Sicherheits-Alerts gibt es nur für von GitHub geprüfte Advisories zu Paket-Ökosystemen wie Composer, npm und pip sowie GitHub Actions (dazu optional Malware-Alerts). Eine Lücke im PHP-Quellcode selbst ist kein Composer-Paket.

Das Beispiel PHP2Shell

Am 21. Oktober 2026 wurde PHP2Shell (CVE-2026-109618) veröffentlicht, eine kritische Remote Code Execution im PHP-Kern. Ein typisches Repo sah so aus:

FROM php:8.3.35-fpm

Dependabot-Alerts: keine, denn betroffen ist nicht ein Paket aus der composer.lock, sondern die PHP-Version im Image. Ein Version Update auf php:8.3.36-fpm kommt irgendwann als normaler Pull Request, ohne Hinweis, dass dieser PR eine kritische Lücke schließt.

Stackwatch liest dasselbe Dockerfile, erkennt PHP 8.3.35 mit Beleg (Dockerfile:1) und gleicht neue Advisories gegen diese Version ab. Bei einem Treffer kommt ein Alert mit der gefixten Version, der konkreten Änderung für dieses Repo und einem Workaround, falls du nicht sofort patchen kannst. Wie das im Detail abläuft, steht unter So funktioniert’s.

Der Vergleich

Stand: 24. Oktober 2026. Stackwatch-Angaben beziehen sich auf die Beta.

Wann Dependabot allein reicht

Wenn du keine eigenen Runtimes betreibst, zum Beispiel weil deine Anwendung komplett auf einer Plattform läuft, die PHP oder Node.js für dich patcht, deckt Dependabot den wichtigsten Teil ab: deine Pakete. Dann lohnt sich vor allem, Alerts nicht verwaisen zu lassen. Auto-Triage-Regeln (eigene Regeln für private Repos nur mit GitHub Code Security) und eine feste Zuständigkeit helfen mehr als ein weiteres Werkzeug.

Wann du mehr brauchst

• Deine Repos enthalten Dockerfiles, .php-version, .nvmrc oder CI-Configs mit festen Runtime-Versionen. Welche Versionen noch Sicherheitsupdates bekommen, zeigt die End-of-Life-Übersicht für PHP, Node.js und Python.
• Du musst im Audit belegen, wann du von einer Lücke wusstest und wie du reagiert hast (ISO 27001, NIS2). Mehr dazu im Artikel Schwachstellenmanagement nach NIS2 und ISO 27001.
• Du willst nicht nur „betroffen“ hören, sondern den konkreten Fix für jedes Repo.

So ergänzen sich beide

Lass Dependabot die Pakete pflegen und seine Pull Requests öffnen. Stackwatch liest Runtime und Pakete aus deinen Repos, meldet Treffer mit Beleg und sagt dir, was zu tun ist. Doppelte Meldungen sind kein Ziel: Stackwatch soll dich dort warnen, wo sonst Stille herrscht. Weitere Werkzeuge vergleichen wir in der Übersicht Dependabot-Alternativen 2026.

Quellen

• GitHub Docs: Supported ecosystems and repositories (Dependabot)
• GitHub Docs: Dependency graph supported package ecosystems
• GitHub Docs: About the GitHub Advisory Database
• PHP Security Advisory GHSA-w8hw-w9fx-j79w