AI Speeds Up Security. The Last Mile Is Yours.

What a machine found in code nobody thought to check

In April, Anthropic pointed an unreleased model at a big slice of the open-source software the internet runs on. Eleven partners came along, mostly the security and infrastructure names you would expect. They called it Project Glasswing.

It found a sixteen-year-old flaw in FFmpeg, which is the software running underneath nearly every video player and streaming service you have ever used. That one had survived more than 5 million automated tests without anybody catching it. It found another in OpenBSD that had been there twenty-seven years. By late May, participants across the whole effort had turned up roughly 10,000 critical and high severity flaws in their own products, and the model found 6,202 more in the open-source projects it scanned.

Twenty-seven years is the part I cannot get past. That is a project whose whole reputation is built on people auditing the code, and the flaw just sat there the whole time.

I do not think that means the machine is smarter than the people who wrote the code. I think it means the machine never gets tired, never gets bored, and never decides it has looked at this file enough. Hunting vulnerabilities rewards stamina more than brilliance. That is good news. Better found than left sitting there.

Finding is not fixing

Then came the part that got everybody's attention. Anthropic keeps a public ledger of what it has disclosed and what has actually been fixed, and back in May it showed 1,596 findings handed to maintainers across 281 projects, with 97 of them patched.

Six percent. Finding had outrun fixing by a mile.

It is worth being clear about whose backlog that actually is, because the number invites the wrong conclusion. Those are upstream maintainers fixing their own code, in projects most of your clients have never heard of and every one of them depends on. It is not anybody's managed client environment.

Then I pulled the same ledger again before writing this. As of its August 26 update, disclosures were up to 2,300 and patched was up to 421. Six percent had become eighteen.

Part of that is a wider net. Anthropic was scanning with one model in May and several by August, so some of the jump is simply more looking.

But that does not explain the shape of it. Findings went up by less than half. Fixes went up more than four times over. That is the fixing side gaining ground.

So the easy version of this story, the one where AI got good at finding and nobody got better at fixing, is already out of date. OpenAI put its own tools on the other end of the problem in June, working with outside security firms on projects like cURL, Go, and Python. Those are running inside your clients' environments right now whether anybody has ever mentioned them to you or not.

The pileup is real. It just moved.

The last mile is somebody's building

In between a maintainer merging a fix and a mid-sized company actually running it, there is a pile of work nobody has automated, and probably nobody will.

An asset list that is never quite accurate. Change windows. A patch that takes the accounting system down at two in the morning. A client who will not accept downtime anywhere near quarter close. A compliance officer who needs the whole thing documented afterward. That work happens inside thousands of individual buildings, one at a time, and no frontier lab can reach into those buildings to do it.

Which is where you already are, if you run an MSP or an MSSP. It is also the one step that gets harder as everything around it gets faster. Finding got faster. Fixing upstream is getting faster. Installing did not, and it has more to carry every quarter.

Two alliances, four months apart

Which brings me back to Chris's post.

In July, NVIDIA launched the Open Secure AI Alliance. Same broad problem, opposite architecture: open weights and open tools, the kind a defender can download, inspect, and run themselves. Five weeks later it was past 120 member companies.

The interesting part was not that the industry split into camps. It was that the serious defenders refused to pick one. Cisco, CrowdStrike, Microsoft, Amazon, Palo Alto Networks, and the Linux Foundation all show up in both efforts, about four months apart, on opposite architectures.

I take that as need rather than indecision, and to be clear, that is my read and not something any of them has said. The closed frontier models are the ones that can find a twenty-seven-year-old flaw. Open weights are how anything like that gets near data that is not allowed to leave a building. Defend a large enterprise and you have both problems at once, so you sit in both rooms.

One more thing is worth saying out loud, since anybody who checks the roster will notice it anyway. On the roster I read on August 30, OpenAI, Anthropic, Google, and Meta were all absent from the alliance. I am not going to guess at anybody's reasons, and it may not stay true for long. What filled it up instead is the crowd that actually buys and installs this stuff: security vendors, infrastructure providers, and a long tail of smaller model labs.

Finding can happen anywhere. Running the model has to happen where the data is.

Why any of this reaches your clients

A lot of the data your clients most need analyzed is not allowed to go anywhere.

Protected health information. Credit card data. Criminal justice records under CJIS. Anything covered by a defense contract. Anything a cyber insurance policy says has to stay put. And log data, which if it ever leaked would hand somebody a map of the client's entire network.

For that data, “we will run it through a model” is not an architecture decision. It is a contract question, and the answer is often no.

For anyone who wants it one level down: a hosted frontier model lives behind an API, which means the data crosses your client's boundary to get processed, and your control ends at that boundary no matter what the vendor's retention policy says. Open weights turn that around. You download the model itself, run it on hardware inside the environment, and the data never moves. You give up some raw capability. In exchange you get inspection, tuning, containment, the ability to run offline, and a straight answer for the auditor.

That tradeoff is the actual decision, and there is nothing ideological about it. Vendors who make it sound ideological are usually selling one side of it.

What I would do if I ran an MSP right now

Four moves, in order.

1. Write down where each client's data is allowed to go, before you evaluate a single model. Their contracts, insurance riders, and compliance frameworks already answer this. Most teams find the constraint halfway through a deployment, which is the expensive way to learn it.
2. Split discovery and remediation in how you sell. Discovery is getting cheaper and more plentiful every quarter, and it will end up bundled into tools your clients already pay for. Remediation capacity is the thing nobody can conjure out of nowhere. Sell the scarce one.
3. Price remediation as standing capacity, and keep per-finding records anyway. Every patch that clears upstream lands in somebody's queue eventually, and the volume upstream keeps climbing. That makes this ongoing work rather than a series of projects, which is to say it is a retainer. Keep the item-level trail regardless, because the frameworks your regulated clients live under tend to want a dated record for each item, and a capacity retainer with no evidence underneath it will not survive that conversation.
4. Decide where your models are allowed to run, on purpose, and put that decision in writing. Most of you do not host models at all. You resell tools whose architecture the vendor controls, so start there: ask every security vendor where their inference runs and what leaves the client's boundary, and write the answers down. That document is the deliverable. Say it before a client's auditor asks, because I would not want to be drafting that answer under deadline.

Not one of those is a technology decision. They are positioning, pricing, and message decisions, which is exactly why they tend to sit unmade while everybody evaluates tools. Getting them made is where a Fractional CMTO seat earns its keep.

The line I keep coming back to

Chris and I were talking about model architecture. What we were actually talking about was who gets to help.

AI found the work. It is going to keep finding it, faster every quarter, in code nobody has read closely since 1999, and it is learning to write the fixes too. What it cannot do is walk into your client's building on a Tuesday night and install the fix, inside a change window somebody had to negotiate, on systems holding data that was never going to leave.

That is a good place to be standing if you sell managed services. The work is arriving where you already are.

The model has to come to the data. That is already true. Build for it.

All signal. No noise.