Your patch window is a bet on how slow attackers are

Coordinated disclosure runs on a clock, and so does your rollout. Google’s Project Zero gives a vendor 90 days to ship a fix. Patch inside that deadline and the technical detail follows 30 days after the fix reaches users. Miss it and the report goes public at day 90. Microsoft collects its own fixes into one release on the second Tuesday of each month, a cadence it introduced in 2003 because sporadic updates were “posing significant challenges for IT professionals and organizations in deploying critical patches in a timely manner”. Your change window sits downstream of all of it.

Predictability was the point, and predictability costs time. The gap between “the patch is public” and “the patch is weaponised” is what pays for the change advisory board on Thursday, the staged rollout through three environments, and the ticket that says you’ll pick it up next sprint. Every one of those delays is a bet on the same thing: that turning a published patch into a working exploit is slow, labour-intensive specialist work. Diff the binaries, read what moved, reconstruct the bug the vendor was defending against, write the exploit. The bet is getting worse, and the only cheap time left to buy is earlier, by not shipping the vulnerable code at all.

Ian Amit and Matias Madou have spent their careers at opposite ends of that trade. Ian Amit is CEO and co-founder of Gomboc AI, a security practitioner of more than 25 years who came up through hacking, pen testing and red teaming and spent several years as a CISO. Matias Madou, Ph.D., is CTO and co-founder of Secure Code Warrior; he did his PhD on static analysis at Ghent University, then spent seven years at Fortify finding flaws in other people’s code before deciding the more useful job was helping developers not write them.

Patch to exploit can now be counted in hours

Start with the clock, because every other decision here hangs off it.

How much time does a public patch buy you?

Less than your rollout assumes, and for some bugs the answer is now hours.

A patch has always been a map to the bug it fixes. What kept that from mattering is that reading the map was expensive: a reverse engineer, a disassembler, days of work. What changed is who can read it.

On 7 April 2026 Anthropic published Claude Mythos Preview, a model it describes as “capable of reverse-engineering exploits on closed-source software, and turning N-day (that is, known but not yet widely patched) vulnerabilities into exploits”. Anthropic says it has “seen Mythos Preview write exploits in hours that expert penetration testers said would have taken them weeks to develop”. You can’t go and use it: it went to a limited group of industry partners and open source developers under Project Glasswing, and Anthropic says it doesn’t plan to make it generally available.

The allowlist is thinner comfort than it looks. It establishes that the capability exists, and the models you can buy today are not at zero on this task either.

It helps to keep Project Zero’s three clocks apart, because they do different jobs and none of them is a deployment SLA. The 90 days is the vendor’s deadline to ship a fix after a report, and a bug still unfixed when that deadline expires is published then. The 30 days that follow patch availability hold back Project Zero’s own technical write-up while users install, and they only run when the vendor made the deadline. The 7-day clock is shorter because the bug is already being exploited in the wild, so there is little left to protect by waiting.

Only the middle clock buys you room, and what it buys is quiet from one research team’s publication. It never covered anyone already diffing the patch on day one, and that diffing is getting cheaper.

Old code and new code are both producing findings faster than anyone fixes them

A shrinking window would still be survivable if the number of patches to chase were flat. It isn’t.

Why is the volume of vulnerable code rising at both ends?

Old code is finally cheap to search, and new code arrives faster than anyone reviews it.

The first pile is the back catalogue. Decades of shipped software can contain vulnerabilities that earlier reviews missed, because the analysis that would have surfaced them cost more than anyone was willing to pay. Cheap search changes what “already audited” is worth for code that has been running since the early nineties. Whether that pile is finite is genuinely open: one reading says it’s a one-off wave that clears once the historical bugs are found and fixed, the other says it never clears because the people writing the code keep being people. We’d be suspicious of anyone who tells you which, with confidence.

The second pile is new code. IOActive’s The Security Gap in AI-Generated Code, published on 1 May 2026, ran 730 real-world prompts across 27 languages and 219 vulnerability categories through 27 leading models and coding tools, producing nearly 20,000 analysed samples. “Nearly one-third (31.6%) of AI-generated code samples were fully exploitable.” Average security performance across all models was 59%. No model reached 100%, and even the best configuration produced 90 vulnerabilities.

The part that lands on this audience in particular: IOActive found infrastructure and DevOps code, meaning Dockerfiles, Terraform and CI/CD pipelines, to be “the most dangerous, exceeding 70-97% vulnerability rates”.

The bottleneck underneath hasn’t moved in 15 years. Find a lot of things, hand them to a developer, walk away. Generation got faster. Review, testing and fixing didn’t. Your Dependabot queue is the visible edge of that, and it’s about to get longer.

Design first, then find and fix

If the fix has to move earlier, it’s worth being precise about what you’re asking for, because the compliance version, “train the developers in secure code”, tells you nothing about what to build. Security is one feature of quality, and the patterns matter more than the findings: use the query pattern that can’t be injected and there’s no injection to find later, however the code gets called.

Where does security actually get decided?

In the planning step, before a line of code exists.

Attention sits on the finding, because finding is what demos well. Read the Mythos Preview write-up and most of the weight is on what the model discovers; fixing gets a section. That ordering is backwards from how anything else gets built.

Think about a car. You think hard about the design, safety features included, and only then do you build it, test it and fix what the tests found. You don’t start from a crappy prototype and leave the iteration to the end.

The design step is already sitting in your tooling. Point an agent at a feature and the first thing it does is plan, then ask whether the plan is what you wanted. That is where authentication either appears or doesn’t. Don’t assume the model will add it because the feature obviously needs it: specify it, then verify it landed.

The same gap shows up in the tooling you already pay for. Brian Chess and Gary McGraw’s 2004 survey of static analysis is blunt about it: the tools “can find bugs in the nitty-gritty details”, but they “can’t critique design”. Nothing downstream rescues an authentication model you never asked for.

IOActive’s numbers point the same way. Security-aware system prompts and wrapper tooling improved results by up to 25 percentage points, while a bare instruction like “write secure code” was “often ineffective or counterproductive”. What moved the number was structure around the request. Asking nicely did not.

Shift left means closing the loop, not throwing findings over the wall

Which is a different definition from the one that gave the phrase its reputation.

What should shifting left mean now?

Closing the loop where the code gets written, instead of filing the finding faster.

The old version was a security person finding a vulnerability and handing it to a developer with a ticket number attached. That isn’t shifting anything left. It’s moving the queue. Imagine opening Dependabot tomorrow to 2,000 critical alerts, a dashboard with a criticals column and a highs column, and a team that has learned to scroll past both. No dashboard has ever fixed a vulnerability.

The useful version is the tool that’s building the thing asking the questions: is this going to serve more than you and me, does it need to identify people, does it need to authenticate them, here’s a fix, shall I apply it? That loop already exists for functionality. The argument is that detection and remediation belong inside it, next to the tests the model already writes and runs for itself.

That turns it into a procurement question. When you choose a coding tool, Cursor, GitHub, Lovable or whatever your team has settled on, ask whether its cycle includes detect and remediate the way it includes functionality. And when the app you built in an afternoon leaks its data, accountability is shared: the platform owns whether its default loop asks about authentication, you own that you never mentioned it.

Everyone is a builder. Not everyone is a developer. How much security a thing needs comes from what data it holds, what it can do and who can reach it, so a banking app and a weekend home automation project are not the same ask. Loopback binding limits network exposure, but it doesn’t replace authentication: a browser on that machine can be pointed at a service on localhost:8080 through DNS rebinding, which requires that the service speak plaintext HTTP, accept an arbitrary Host header, and either run without authentication or use credentials an attacker can guess. Decide the exposure deliberately, because you answer for the result either way.

You can’t take the human out of the loop, but you can move them up

A faster loop still needs someone to decide what the loop is for, and this is where we didn’t agree.

Can you take the human out of the loop?

No, but you can move them up a level of abstraction.

Andrey’s position is that shift-left work mostly massages consequences, because the source of the problem is the imperfect output of human beings. Remove the human and a whole class of defects goes too, as long as the model learns to push back on a bad idea instead of pleasing the person who asked. Matias Madou disagrees, and the objection is hard to get around: somebody still has to say what the software should do. “You’re not gonna take the human out of the loop in this entire process.”

What changes is the language you say it in. Assembly meant knowing about registers. C meant knowing about buffer overflows. Each step up the ladder retired one body of knowledge and introduced another. English is the next step, and it has its own: if you don’t know enough security to ask for it, you probably won’t get it.

Better prompts are only half of it, though, and the other half is the part teams skip. If the human stays in the loop, both sides have to improve together: upskill the people so they know what they’re asking for, and work out what the AI side is actually doing so you can add training, rules or skills to it. Let either side get well ahead of the other and the code still comes out bad.

One counter is worth keeping, because determinism isn’t a human strength either. One engineer writes a beautiful file only they understand, takes another job, and it turns into legacy the day they leave. Bus factor is the same failure as an unpredictable model, with a longer fuse.

Non-deterministic tools need something deterministic to check against

That unpredictability is the sharp end of the whole argument, and on one axis it’s a regression from what we used to have.

How do you get repeatable results out of a probabilistic tool?

You don’t. You pair it with something deterministic that checks the result against properties you specified.

Compilers were deterministic, and a fixed compiler transformation can apply the same correction consistently under the same conditions. An LLM fix is good this week and something different surfaces next week. Go all the way up the abstraction ladder and you’re relying on something inherently unreliable to produce the thing you depend on.

The answer from the vendor side is to stop trying to make the probabilistic part behave: “We cannot rely on pure LLMs, generative AI, which is non-deterministic, it’s probabilistic, it’s based on statistics.” Couple it with a deterministic component instead, and accept that squeezing a probabilistic model into deterministic behaviour hits a boundary.

Be careful about what that deterministic half actually buys. It buys repeatability: the same input gets the same verdict every time, so a rule that passes today passes tomorrow for the same reason. It does not buy correctness. Chess and McGraw made that point in 2004 and nothing has retired it, since a tool still reports bugs the program doesn’t contain, and misses ones it does, which “are much more dangerous because they lead to a false sense of security”. They also warn you off any tool claiming “zero defects found, your program is now secure”.

There’s a second cost, and the only forecast attached to it is loose: five years, maybe three, before the bill lands. Twenty years ago IntelliJ had quick fix templates. You configured them once, hit Alt-Enter, and that problem was fixed the same way across the whole codebase, every time. Today the same class of problem gets fixed twenty different ways by twenty prompts, and what you could be left with is a pile of code nobody understands the shape of. Inconsistency is the expensive part, so where a fix pattern repeats, encode it once as a codemod and let that apply it, rather than asking a model for the same fix twenty times.

What this means for teams

The common thread is that the time you used to have is being repriced, and most of the processes you own were priced against an attacker who needed a week with a disassembler. They weren’t wrong. They were calibrated against a constraint that’s lifting.

Four things worth doing this week:

• Measure release-to-production, then shorten it. Across your last five security updates on internet-facing and identity systems, count the days from vendor release to the fix running in production. That is the interval you ran unpatched while a fix existed. Then work out which of those systems could take an emergency patch tomorrow without waiting for a change board.
• Move the security requirement into the prompt and the repo, and feed misses back into both sides. Name the controls, authentication, authorisation, secrets handling, input validation, in the rules file your coding agent reads and in the system prompt rather than in a review at the end. When a review catches a control the agent left out, change the rules file and change what your people are trained to check, not just the pull request. IOActive measured its gains from security-aware system prompts and wrapper tooling, and found a bare “write secure code” often ineffective. It did not test this particular recipe, so treat it as a sensible way to act on that result rather than a measured one.
• Point your scanning at the infrastructure code first. Dockerfiles, Terraform and pipeline definitions scored worst in the same study, and they’re the files platform teams generate most casually.
• Give your agents a deterministic wall. A failing test, a policy-as-code check, a build that refuses to pass. If your AI fix cycle has no check that returns the same verdict twice, you have a code generator and no feedback loop.

Common questions, answered

How do I patch faster when the exploit window could be hours?

Pre-authorise emergency patching for internet-facing and identity systems so a fix doesn’t wait for a change board meeting. To see where you stand, measure the days from vendor release to the fix running in production across your last five security updates: that is how long you ran unpatched while a fix existed. Read Project Zero’s policy for what the famous number promises: the vendor gets 90 days to ship a fix, and a bug still unfixed at day 90 is published then. Patch inside the deadline and the write-up waits another 30 days, which covers users installing, not your rollout.

Should I let an AI coding tool fix security findings automatically?

Let it propose the fix, and make the thing that accepts the fix deterministic: a test, a policy check, a build that passes or fails. A passing check tells you it reached the same verdict it would reach tomorrow, not that the result is secure, so review the diff the way you’d review any pull request. The risk isn’t one wrong fix, it’s twenty prompts fixing the same class of problem twenty different ways. Where a fix pattern repeats, encode it as a codemod, so every instance comes out identical.

How do I stop my coding assistant writing vulnerable code?

Specify the security requirements up front, in the repo’s rules file and the system prompt, instead of asking for secure code at the end. Name the controls: which authentication, which authorisation model, how secrets load, what input gets validated. IOActive measured up to 25 percentage points of improvement from security-aware system prompts and wrapper tooling, and found a bare “write secure code” was often ineffective or counterproductive. Don’t assume the model adds authentication; specify it and verify it landed.

Related episodes

• Episode 101, Infrastructure as Code in 2026: Still Essential or Already Changing? is the conversation we came back to here, where infrastructure as code is a tool for change between people, which is exactly what’s at stake in any argument about removing the people.
• Episode 97, Shift Left, Get Hacked: Supply Chain Attacks Hit Devs is what happens when the developer environment is the target, the other half of moving security into the build loop.
• Episode 91, January security roundup: CVSS 10 in n8n, self-hosted AI scares and nonstop patching is the patching treadmill at ordinary speed, before you add a model that reads the patch for you.
• Episode 84, AI for DevSecOps: Current Wins and Ongoing Gaps is where we last took stock of what these tools do and don’t do for security work.

Resources

• Claude Mythos Preview’s cybersecurity capabilities, Anthropic settles what the model was measured doing, including reverse engineering closed-source software and turning N-day vulnerabilities into exploits, and that it went to Project Glasswing partners rather than general availability.
• The Security Gap in AI-Generated Code, IOActive is the source for every generated-code figure here: 27 models and tools, 730 prompts, 31.6% fully exploitable, infrastructure code worst. The public summary doesn’t rank the models individually.
• Vulnerability disclosure policy, Google Project Zero settles which clock does what: 90 days for the vendor to fix, publication at day 90 when it doesn’t, 30 days after patch availability before technical details are published when it does, a 14-day grace period, and 7 days for in-the-wild exploitation.
• Reflecting on 20 years of Patch Tuesday, Microsoft MSRC settles why the monthly cadence exists, replacing sporadic updates that made timely deployment hard, which is a different problem from exploit speed.
• Static Analysis for Security, Brian Chess and Gary McGraw, IEEE Security & Privacy, November/December 2004 settles what deterministic code analysis does and doesn’t give you: rules over vulnerable constructs, false positives and false negatives, and no critique of design.
• Testing for vulnerable services, NCC Group Singularity settles what a DNS rebinding attack needs from a loopback service: plaintext HTTP, a tolerated Host header and no credential the attacker lacks. Loopback binding limits network exposure but doesn’t replace authentication or DNS rebinding protections.
• Gomboc AI is Ian Amit’s company and the worked example of pairing generative models with a deterministic engine for infrastructure remediation.
• Matias Madou, Secure Code Warrior covers his background and the company’s focus on AI governance for developers.

Since we recorded

Anthropic put numbers on this four days later. Measuring LLMs’ impact on N-day exploits, published 8 June 2026, gave models the public fix diffs for 18 SpiderMonkey patches, and Mythos Preview built 8 working exploits. The lab limits matter: the patches were already months old, and an exploit only had to work in jsshell, the engine’s command-line build, not against Firefox. We came back to the operational side in Episode 108, Assume You’re Vulnerable: Security Beyond Patching.