Stackwatch and Dependabot: what’s the difference?

The short version

Dependabot is free, built into GitHub and good at keeping the packages in your lockfiles up to date. It does not alert on vulnerabilities in the runtime itself, meaning the PHP interpreter, Node.js or Python, because GitHub’s dependency graph does not parse Dockerfiles. Stackwatch closes exactly that gap and does not replace Dependabot.

What Dependabot checks

Dependabot has three features that are often lumped together:

• Dependabot alerts report known vulnerabilities in dependencies. They are based on the dependency graph, meaning manifests and lockfiles such as composer.lock, package-lock.json, requirements.txt or poetry.lock.
• Security updates open pull requests that raise a vulnerable dependency to a fixed version.
• Version updates keep dependencies current in general, including Docker images in Dockerfile and docker-compose.yml.

The catch is in the details: version updates for Docker bump image tags but have nothing to do with vulnerabilities. According to GitHub’s docs, security updates are not supported for Docker, and the dependency graph does not know Dockerfiles. On top of that, security alerts only exist for GitHub-reviewed advisories for package ecosystems such as Composer, npm and pip, plus GitHub Actions (and optional malware alerts). A vulnerability in the PHP source itself is not a Composer package.

The PHP2Shell example

On 21 October 2026, PHP2Shell (CVE-2026-109618) was published, a critical remote code execution in the PHP core. A typical repo looked like this:

FROM php:8.3.35-fpm

Dependabot alerts: none, because the affected component is not a package in composer.lock but the PHP version in the image. A version update to php:8.3.36-fpm arrives at some point as a regular pull request, with no hint that it closes a critical vulnerability.

Stackwatch reads the same Dockerfile, detects PHP 8.3.35 with evidence (Dockerfile:1) and matches new advisories against that version. On a match you get an alert with the fixed version, the concrete change for this repo and a workaround in case you cannot patch right away. How this works in detail is described in how it works.

The comparison

As of 24 October 2026. Stackwatch details refer to the beta.

When Dependabot alone is enough

If you do not run your own runtimes, for example because your application runs entirely on a platform that patches PHP or Node.js for you, Dependabot covers the most important part: your packages. Then the main thing is not to let alerts go stale. Auto-triage rules (custom rules on private repos need GitHub Code Security) and clear ownership help more than another tool.

When you need more

• Your repos contain Dockerfiles, .php-version, .nvmrc or CI configs with pinned runtime versions. Which versions still get security updates is shown in the end-of-life overview for PHP, Node.js and Python.
• You need to prove in an audit when you knew about a vulnerability and how you responded (ISO 27001, NIS2). More in the article vulnerability management under NIS2 and ISO 27001.
• You want more than “affected”: the concrete fix for each repo.

How they work together

Let Dependabot maintain your packages and open its pull requests. Stackwatch reads runtime and packages from your repos, reports matches with evidence and tells you what to do. Duplicate alerts are not the goal: Stackwatch should warn you where there would otherwise be silence. We compare more tools in the overview Dependabot alternatives in 2026.

Sources

• 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