LinkedIn’s CISO, Lea Kissner, published a post on 30 October about how LinkedIn has been tightening its security fundamentals this year, and one line in it has stuck with me since: “Increasingly, that work needs to have happened already.” Her argument is that AI is narrowing the gap between a vulnerability being discovered and it being exploited, so the preparation you do before an incident matters far more than how fast you can improvise during one.

The timing was hard to miss. The week before, on 21 October, PHP shipped fixes for two critical vulnerabilities (both rated 9.2) that allowed unauthenticated remote code execution, the kind of thing that sends every ops team scrambling. The NSA advised organisations that couldn’t patch straight away to take affected systems offline. And here’s the bit that caught my eye: OpenAI said one of the flaws was found by a firm called Calif using one of its models, while Wiz found and reported both independently. (Kissner’s post doesn’t name the vulnerabilities, by the way, so I’m not suggesting the two are connected; it’s just the week everyone was having.)

So AI is finding the bugs now. Which, needless to say, means it’s finding them for the attackers too.

The Patch Window Is Shrinking

For most of my career, the unwritten deal with security patches went something like this: a CVE comes out, it gets triaged, somebody raises a ticket, it goes into next sprint (or the one after), it gets tested, and it’s in production in a couple of weeks if you’re good, a couple of months if you’re not. That was never great, but it was survivable, because turning a CVE into a working exploit took skill and time.

If a model can find the flaw, a model can quite likely help write the exploit as well. That doesn’t mean every script kiddie now has a zero-day factory, but it does mean the window you used to have between “disclosed” and “being exploited in the wild” is getting shorter, and I’d venture to say it’ll keep getting shorter. A patch process that needs a meeting, a ticket and a sprint is a process designed for a world that’s going away.

Kissner’s five fundamentals are worth reading in full, and none of them is glamorous: know what you own, keep things current, reduce what you don’t need, practise before an emergency, and treat AI agents as actors you remain accountable for. LinkedIn archived “thousands of unused and unclaimed repositories” as part of it, which made me smile, because just about every company I’ve seen has its own graveyard of repos nobody would admit to owning 🙂

What This Looks Like in a Small Shop

You don’t need a security org the size of LinkedIn’s to apply this. In Calendrz we’re a tiny team, so the only way to keep things current is to make it automatic and boring. Dependabot opens grouped pull requests for the backend and frontend dependencies every Monday (minor and patch updates bundled together, so it’s one review instead of fifteen), and security updates come in through Dependabot as well. Last week’s batch alone bumped the Anthropic Java SDK, Vite and a handful of npm packages, and nobody had to remember to do it.

The other piece is knowing who’s knocking on the door. We run a nightly job that goes through the production logs, spots automated scanners probing for things that don’t exist, and adds them to a shared bot-probe list, which the app then uses to keep its logs readable. A couple of weeks ago we noticed that one of those probes, a false_<random digits>.txt file, kept coming back: the job had dutifully added each exact path to the list, and none of them ever matched again because the scanner changed the number on every run. The fix was to match the stable prefix instead of the exact name. Small thing, but it’s a nice reminder that automation which only remembers yesterday’s attack is not much use against tomorrow’s.

So What Now?

If I were a CTO looking at my own setup this week, I’d ask three questions. How long does it take us, today, from a critical CVE being published to the fix being in production, and is that measured in hours or in sprints? Do we actually know every service, repo and dependency we’re running (including the ones from that project two years ago)? And for the agents we’ve let loose on our code and infrastructure, who’s accountable for what they do?

That last one matters more than it seems. I’m a big believer that AI’s real gift is velocity, and patching is one of the places where that velocity really pays off: an agent can read the advisory, bump the version, run the tests and open the pull request before a human has finished their coffee. But it only pays off if the organisation around it can say yes quickly. If the fix then sits in a change advisory board for four days waiting for a committee to sign it off, the attackers won’t be waiting with you.

Bottom line: the work needs to have happened already. Make updating boring, make it automatic, and make sure somebody owns every box on the diagram.