Reclaim Wednesdays: letting a bot handle the security-update grind

As we all know only too well, Drupal security releases land on a Wednesday evening, UK time. If you look after a lot of Drupal sites, that means the same routine every week: work out which sites are affected, update them, check nothing broke, get the change reviewed and deployed, and log the work. Relatively easy repetitive work but easy to get slightly wrong at 9pm.

We've built a bot that does the repetitive part for us. It finds the affected sites, applies the update locally, tests it, and hands a developer a pull request ready to review. A person still reviews and merges every change. This post covers how it works and what we'd suggest if you want to build something similar.

What it does

Every ten minutes on a Wednesday afternoon and evening, plus once each morning, secbot checks every client site we support. For each site with a new advisory, it:

1. Runs composer audit against the site's release branch to see exactly which packages are affected.
2. Spins up the site in its own local ddev environment, using a slimmed-down copy of a developer's fully sanitised database. Nothing is pulled from production.
3. Updates only the affected packages, pinned to the version the advisory names as the fix, not simply the latest release.
4. Runs database updates and a config export, then a smoke test: the same pages fetched before and after, logged in and out, watching for errors. Plus for projects with their own specific tests we run those too.
5. Pushes a branch and opens a pull request, with notes on what changed and what a reviewer should check.
6. Opens a ticket in Redmine, our project tracker, and posts the result to a Slack channel.

A developer picks it up from there: they review the PR, merge it and deploy as normal. The bot never merges or deploys anything itself.

Each morning it also posts a short digest of anything still open: PRs waiting for review, updates it couldn't apply, and sites it couldn't check.

None of this needs special hardware. Secbot runs on an old Mac mini we had spare, wiped and reinstalled with Ubuntu Linux. The heavy lifting is done by ddev and Docker, which any reasonably modern machine can handle.

What we learned building it

Use AI only where you need judgement. Secbot uses Claude, an AI model, but only for part of the job. Checking for advisories, running the smoke tests, comparing lock files and posting to Slack are all plain scripts that behave the same way every time. The model handles the parts that need a decision: which version to pin, whether a warning matters, and how to group changes into PRs. That keeps runs predictable and cheap, at roughly a dollar a site.

Keep a person in charge of what goes live. The bot prepares changes; it doesn't ship them. Release branches are protected on GitHub, so even a mistake can't push straight to production. Review is quick because the PR already says what changed and what to check, the PR descriptions are excellent!

When something fails, stop and say so. If an update won't install or a test fails, the bot stops work on that site and reports it. It doesn't loosen version constraints or edit code to make the problem go away.

Be careful about what you install. Security updates are a tempting target for supply-chain attacks, so the bot installs only the fixed version, flags any dependency released in the last three days, and stops if a package's source has changed.

Keep the bot to its own lane. It works in its own checkouts with its own ddev projects, so it never touches a developer's working copy.

The upshot

Security releases still get the same care, but the hours of routine work now happen before anyone sits down. Our developers spend their time on review and on the updates that genuinely need a person. If you'd like help keeping your Drupal sites secure and up to date, get in touch.