Dependabot watches my dependencies so I do not have to

Dependabot is GitHub's built-in robot that watches every package I depend on, warns me the moment one turns out to be vulnerable, and opens the pull request to fix it.

I run it on this garden because I cannot track dependency vulnerabilities by hand, and on a private repo it costs nothing. Here is what it is, why it matters, and the exact job it does here.

What Dependabot is

Dependabot is dependency automation baked into GitHub. It does two jobs. Security updates open a pull request when a package I use has a known vulnerability. Version updates open a PR to move a dependency to a newer release even when nothing is wrong with it, just to stop drift. Both build on Dependabot alerts, which fire when "a new vulnerability is added to the GitHub Advisory Database" or when my "dependency graph changes" after a bump. The vulnerability data comes from the GitHub Advisory Database, GitHub's reviewed catalogue of disclosed CVEs.

Why I need it

Dependencies rot on their own. New vulnerabilities get disclosed every week, and a package that was clean when I installed it can be flagged months later without me touching a line. Watching that by hand across a full lock file does not scale. Dependabot inverts the work: instead of me polling for bad news, it tells me, with a pull request already written. It is also free on every GitHub plan, private repos included, so there is no reason to leave it off.

How it earns its slot here

dependabot.yml runs weekly version updates for two ecosystems, npm and github-actions, so both my app dependencies and my workflow action pins stay current. That is the boring, useful half.

I also gave the npm updates a 7-day cooldown, so Dependabot holds a fresh release for a week before it writes the PR. The reason is supply chain attacks. In March 2026 someone shipped backdoored LiteLLM packages to PyPI, a cascade that began with a compromised Trivy scanner and reached machines through unpinned transitive dependencies, running at Python startup before anyone even imported the library. A week of daylight gives a poisoned version time to get caught before it lands in my lock file. Security updates ignore the cooldown, so a genuine CVE fix still ships the same day. (Cooldown is npm-only here; the github-actions ecosystem does not support it.)

The sharper half is that its alerts cover a gap I could not close another way. I wanted Why I run Snyk on the garden results in GitHub's Security tab, but that upload needs GitHub Advanced Security, which a private personal repo does not get. Dependabot alerts land in that same tab for free, so they fill the role Snyk could not. See Three autonomous layers that guard the repo without me for the whole three-layer setup.

The honest limit

Automation is not a free lunch. A version bump can break the build, which is exactly why CI still gates every PR before I merge one. Alerts detect but do not fix by themselves unless I let security updates raise the PR, and even then someone reviews it. There is also a wiring quirk: Dependabot's own PRs run with a read-only token and Dependabot's secrets, not the repo's Actions secrets, so my SNYK_TOKEN is empty on them. The Snyk job is set to skip Dependabot PRs rather than fail on every one.

The bottom line

Dependabot turns dependency security from a thing I remember to check into a thing that shows up as a pull request. On a private repo it is free, it covers the Security tab that paid scanning would have, and it pairs with CI, which catches the bumps that break. Turn it on, keep the gate, review the PRs.