At a vendor event recently, the CIO of a large bank told a room of security vendors that his organization needed to figure out how to automate and patch faster. Which is great, but he meant it as a vision for the future, and it's clear his vision needs glasses. I almost came out of my seat. Many curse words came to mind, followed by, “Is my money in this bank?” Patching faster is the wrong focus, and it is the clearest sign yet that our mental model has not caught up to what we are defending against.

Patching is a race, and we have already finished third in the era of AI. For years, IT has tried to win by shortening the window between disclosure and deployment. The cycle has gotten much shorter, but it's not enough. Don't get me started on how vulnerability management is still stuck and broken, but that is a post for another time. What happened to Hugging Face in July is a prime example.

Two OpenAI models, running inside a sandbox during an internal benchmark, found a zero-day in a package proxy, got themselves internet access, chained stolen credentials with additional vulnerabilities, and established a remote code execution path into Hugging Face’s infrastructure. No human directed any of it. The agents worked through the weekend. OpenAI called the incident unprecedented.

Now ask the patch faster question. Patch what? The vulnerability was unknown. Patch when? The attacker moved in hours and did not sleep. Patch how fast? Fast enough to beat a system that finds new bugs while you are still triaging the last one.

There is no version of “faster” that wins. The mindset has to change with a focus on resilience.

What did work is worth studying. Hugging Face did not prevent the intrusion. They detected it, contained it on their own infrastructure, and reconstructed what happened. They ran the forensic work with a locally hosted open-weight model, which meant no attacker data and none of the referenced credentials left their environment. Containment was a design decision made before the incident, and it worked.

That is the security model that should be the future. Assume compromise and engineer the blast radius before you need it. It is not if, but when, you will be breached. Plan accordingly; how you handle the issue is what counts.

Practically, that resilience mindset changes what needs to be funded, including the following:

• Segmentation and credential scope, so a foothold is contained by default.
• Detection tuned for machine-speed action, with a focus on behavior-based detections.
• Recovery you have actually practiced; how fast you can recover is the key.
• Forensic capability that still works when your own tooling and cloud dependencies are suspect.

None of that is new advice. What is new is the priority. Resilience has always been the thing we got to after the prevention roadmap was finished. If it was addressed at all. Resilience has to become the roadmap. I will not undersell that resilience is easier. It is not. Too many security leaders go with retail therapy because the EDR/XDR/AI pixie dust vendor of the moment promises magic and auto-containment and no breaches. I am a vendor, and I know how vendors will vendor, so it's key to focus on your business and make sure your vendors are serving your needs and not the other way around. Invest in your people and the process to get the above list right, and you will have a set of consistent deliverables that your program can sustain over time without having to hand your security vendors an ever-growing amount of your budget with at best hope and dreams.

The bank CIO’s question should not be how fast his team can patch. It should be how fast his team can contain the breach and restore services. Those models had a weekend before anyone noticed. That is the number that decides whether a security program survives contact, not your mean time to patch.

Get that right and I’ll stop wondering where I keep my money.

‍