A Security Incident, an Idea and Four Hours with Claude Code

On 21 October I was dialling into a workshop in London with the BMT team who were in-person. The day was meant to be security briefings, a few show-and-tell sessions on what people had been building with AI and some games. Later in the afternoon, the team were alerted to a new PHP vulnerability, and the room turned into an incident response.

The PHP project had released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities that allowed unauthenticated remote code execution, and the advisory was clear that there were no complete mitigations and updating was the only safe fix. A lot of BMT’s systems run on PHP, so this was not a hypothetical. It was serious enough to make the national news, with the flaw reported to affect millions of websites and organisations around the world taking sites offline as a precaution. The team immediately sprang into action working out which systems were affected, what needed shutting down, what could be patched in place and how to tell customers. I worked with support staff to ensure users were kept informed through our support system, while the developers and our security lead handled the technical response.

While the developers were patching, I went back to look at when the issue had first become public. The PHP team had published an advance warning the evening before the releases, saying a critical security release was coming. It went out on PHP’s announcement mailing list and on php.net, both of which anyone can subscribe to. The warning existed, it was public but we were not watching the feed and found out the following day.

The alert had still reached us in good time and the team had responded well, but I wanted a proper security monitoring tool that watches the official sources directly. I raised it in Slack, suggested a pipeline that monitors the feeds for the products we use and offered to build a prototype that evening. The security lead agreed it fitted into our ISMS work and I was given the go-ahead. A colleague also pointed us at the NCSC Early Warning service, which covers signs of compromise on an organisation’s own IP addresses. That is complementary rather than the same thing, so registering for it went on the list too.

Thirty-seven minutes to a working prototype

I started the way I usually do, by talking the idea through with ChatGPT and then taking the plan to Claude Code to build. We went over the requirements and the approach and it came back with three streams to watch, a preference for official feeds over scraping and an estimate of around two working days for a narrow first version. Its most useful conclusion was that the real investment should go into a trustworthy inventory of what we actually run and into getting alerts to the right people, with AI kept to optional summaries rather than anything load-bearing.

I pasted that plan into Claude Code at 17:25, told it this was a one-off internal tool for BMT and nothing to do with Product Scope and said I wanted to use GitHub and Cloudflare. The first code was committed at 17:51 and I deployed the first working version at 18:02. That is thirty-seven minutes from handing over the requirements to a prototype running in the cloud. I had spent the whole day on a live security incident and by early evening I was already building the thing that might stop us being caught out by the next one, and the speed of it genuinely surprised me.

I should be clear about what my part in that was. I was not writing code. I was defining the requirements, directing Claude, reviewing what it produced, making the product decisions, testing what came back and running every deploy myself, because Claude’s connectors could create the database but could not ship the Worker.

It was quick but it was not effortless, and the interesting parts were the corrections. The very first scheduled run read php.net’s whole post archive and turned 85 old announcements into 85 live incidents, which I had to spot and have it clean up before the dashboard was any use. Authentication was a longer fight. I set up Cloudflare’s own access control, then found that BAFTA’s email security opens one-time sign-in links before the person does, which uses them up, so the login simply did not work. After a couple of attempts I changed approach and had it build a straightforward email-and-password sign-in instead, which is the sort of dead end you only find by actually trying to use the thing.

I thought about adding a step that used a ChatGPT module in Make to filter which alerts were worth sending and after discussing with Claude we rejected it, because a model could quietly drop a genuinely critical alert and it would mean sending details of our exposure to a third party. All of the classification is done with fixed rules instead. Where the tool cannot tell whether we are affected, because a version is only recorded in documentation and not checked on the live server, it marks the item as needing investigation rather than treating it as safe. For a security tool I would rather it was occasionally noisy than quietly wrong.

To get the design right I ran three design agents in competition, each producing a complete design, reviewed what came back and chose the direction I wanted, taking one of them and keeping the sign-in screen from another because it read more clearly. At the end of the evening I asked for independent code reviews, with every area covered by at least two reviewers. They came back with 61 code-quality and logic findings, mostly around alert timing, matching edge cases and sign-in hardening. Each one was fixed with its own automated test.

During the build I also added overnight quiet hours. Alerts that arrive overnight are held and posted at 7am, which is when the developers come online and can act on them right away, rather than waking someone for something that cannot be dealt with until they are at their desks anyway.

The tool currently watches 15 official sources, matching against an inventory of 30 BMT systems and 254 components that an agent had drafted from our documentation, and it was covered by 132 automated tests including replays of the real PHP events. It is a live prototype, the inventory versions still need confirming against the live servers, the notification and sign-in email problems are still open and the developers need to review it properly before we rely on it.

By the time I finished that evening, I had gone from an idea raised during a security incident to a working monitoring service that was already picking up real alerts. I was genuinely surprised by how far I had managed to take it in a few hours.

There is still work to do. The developers need to review it, we need to confirm the systems inventory and we will only know how useful it really is once the team has been using it for a while. But I enjoyed building it more than anything I have made in a while, and I am already thinking about where else we could apply the same approach.