Your patching has to run without you

Last week three security advisories landed inside a few days. PHP, then Node.js, with a critical one in Next.js alongside it. Each meant the same thing for us. Find everything we run that is affected, patch it, and prove the patch is live.

We did it by hand. A colleague checked an old server. I had Claude write a script to sweep every hostname we own, and it found PHP still answering on three of them, on a machine we thought had nothing public left. The next morning I emailed the team a list of projects and we split them up. Three days later I was still writing upgrade instructions for a system that runs in a customer’s cloud account, to be applied by their contractor in a quiet half hour.

That is what patching looks like in a small team, and it is the part of security nobody sells. Vulnerabilities now arrive faster than people can patch them. The answer is not a product. It is a pipeline.

The advisories are getting faster

The PHP bug shows the new timing. The maintainers pre-announced a critical fix on 20 October. The fix shipped on the 21st at two in the afternoon. Exploitation in the wild was reported at half past seven that same morning, six and a half hours before the patch existed. A team that reads security news on its own schedule has already lost that window.

The attackers are already automated. Every rate-limit alarm our Studio product raised in October, eight of them, turned out to be a vulnerability scanner. Not a user, not a bug, a bot probing for something to exploit.

In April I wrote that security by obscurity was dead, because models like Claude Mythos had made finding old bugs cheap. I also admitted that our own security scanning was a manual gate before deployment, and that closing the gap was the next step. Six months on, last week is what the gap looks like. We had the discipline. We did not have the speed.

We chose this problem

Here is the part that cuts against us. In the past year we replaced WeTransfer, DocuSign, Freshdesk, our pen testing and the Joomla site that used to carry our marketing with software we built ourselves. Agentic engineering made each one a few days’ work. The running cost is somewhere between a tenth and a fifth of the subscriptions they replaced.

The saving is a bonus. The real benefit is that the software fits the business exactly, and when the business changes we change the software the same week. The tools adapt to us rather than the other way round. I have argued on this blog that this is where software is going, more bespoke and less packaged, and I still think so.

But every one of those systems is now ours to patch. Five more services, plus the products we sell, plus the systems we have built and delivered to customers. When the Node advisory landed, that was the list. A SaaS vendor would have patched our file transfers for us, on their schedule, and told us afterwards if they told us at all.

So the obvious objection is that we created this burden and should buy our way out of it. That gets the lesson backwards. The burden is real, and the answer is to automate it, because a pipeline we own patches faster than a vendor we are waiting on, and we can see every step. Building more software means owning more security. That is the deal, and it is a good one, provided the patching never depends on a person reading the news.

Dependabot is not enough

A colleague’s first suggestion was the one everyone makes. Turn on Dependabot. We already had, on every repository. It is good at what it does, and it is nowhere near the whole job.

It only sees library versions in a lockfile. The PHP bug was a runtime. So was the Node one. Base images, operating-system packages and the third-party apps we host ourselves never appear in a Dependabot PR.

It only fires once GitHub’s advisory database lists the flaw. Last week that was hours behind the vendor announcements, and there is no way to make it run early.

It opens the PR and stops. Nothing checks that the PR was reviewed, merged, deployed and verified. A PR that sits for a week is a vulnerability that sits for a week.

It cannot see what is actually running. Most of our images used floating tags rather than pinned digests. A patched base only reaches production when the service is rebuilt, so a deployed image can be weeks behind the repository it came from.

We learned that last one on Friday. Our website ran on AWS App Runner, which supplies its own Node runtime, and AWS had stopped updating it. It was about a year behind on security fixes. The site now builds its own Node 24 image on every push, with every action pinned to a commit. The same day a Studio hotfix revealed that its Dockerfile had been resolving dependencies afresh on every build, so production was a full major version ahead of the lockfile on five packages, and the pip bundled in the base image carried six open advisories. Both were invisible to every tool we had switched on.

Buy a defender, or fix the pipeline

The market’s answer to AI-speed attacks is to buy AI-speed defence. There is a line of thinking that the labs created this problem and are now selling the protection. I do not think that holds. The holes were there for years. The OpenBSD bug Mythos found was twenty-seven years old. What the labs did was make finding them cheap, and most are working hard to put the finding tools in defenders’ hands first. Anthropic’s Cyber Verification Program gives inmydata Defense Access to Mythos, Opus and Sonnet for securing the systems we own. That is the entry tier, open to any team defending its own software, and it was granted in days. In April I described Mythos access as a handful of vetted companies. Six months later it is a small firm in Scotland.

For most companies the exposure is not a lack of AI defence. It is a fleet of small services patched by hand. The fix lives in the build pipeline, not the security budget.

So we are building an agent that watches security bulletins and does the patching work for us. It is a design, not a running system, and we expect to have it in shadow mode within weeks. This is what it does.

It knows what we run. Every night it reads each repository’s lockfiles, Dockerfiles and infrastructure code, then adds what is actually deployed in AWS, image digests, task definitions and Lambda runtimes. A hand-kept file covers what is not in code, including customer installs.

It polls every fifteen minutes. OSV, the GitHub advisory database, CISA’s known-exploited list, the NVD, and the vendor channels for Python, Node, .NET, Postgres and the apps we host. Structured feeds are matched on version ranges exactly, with no model involved. For vendor posts and news, Claude extracts product, affected versions, fix and exploitation status as JSON, and the same deterministic match runs on the result. The model never raises an alert on its own judgement.

It tells us within the hour, and only about real matches. No digest of everything published. An alert names the repository, the file, the version and the fix. Severity comes from rules, not the model, so the same bulletin always lands at the same level. A pre-announcement of a critical release is its own alert type, so we are ready before the patch exists.

It carries the fix to production. If Dependabot opens a PR, the agent links it. If none appears within thirty minutes, or the fix is one Dependabot never raises, a runtime, a base image, a rebuild to pick up a patched tag, the agent opens the PR itself. Patch-level bumps with green CI can merge automatically where a repository opts in. Everything else goes to an owner with a review request. The agent then checks the deployed version and closes the incident only when the fix is live.

The acceptance test is the week we just had. Replay the PHP timeline against an inventory that contains PHP, and the agent must raise a watch alert within fifteen minutes of the pre-announcement and a critical alert within fifteen minutes of the fix.

The slowest link is the one you do not control

The honest limit is the software we have delivered into customers’ own accounts. We cannot push to their production, and we should not. Customer-hosted installs are the slowest link in any patching process, because the fix needs someone else’s hands.

Our answer is to make those hands do as little as possible. Patched builds will push to the customer’s staging environment through GitHub Actions, so production becomes a button press rather than a six-step upgrade. The watcher runs in two modes for the same reason. We can host it and watch customer repositories we have access to, or install it in the customer’s own account as part of every build we deliver, so their software is watched from the first deploy.

Measure how long a fix takes to go live

If you run software in production, count the services your team patches by hand. Not the ones with Dependabot switched on. The ones where a person has to notice, decide, rebuild and deploy.

Then measure one number. The time from a credible advisory to the fix being live on every affected service. Last week ours was measured in days, and for a small team with a growing estate it will only get longer.

The bugs were always there. What changed is that finding them now costs an API call, and the people exploiting them are already running agents. Your patching has to run at that speed too, which means it has to run without you.