Brace for the patch tsunami: AI is unearthing decades of buried code debt Britain's cyber agency is warning that AI-fuelled bug hunting is about to flush out years of buried flaws, leaving defenders scrambling to keep up. In a blog post on Friday, Ollie Whitehouse, CTO of the UK's National Cyber Security Center, said organizations should brace for a looming "patch wave," driven by a backlog of …
Hence why most bugs are simpler than people like to imagine and more numerous than PHBs want to admit. That would require them being honest about how much code was cranked out by underpaid junior devs and never thoroughly QAed.
The technical debt here is real and so is the problem of fixing them. There aren't enough senior devs and experienced QA pros to find and fix them before we all face a tsunami of new exploits.
The skilled humans will need to be fixing bugs and hunting complex bugs. I'm not sure there's a realistic alternative to using AI to find and flag the stupidly simple, template-like bugs, just on account of time limitations.
Think things like the recent monster cPanel root access bug (CVSS 9.8), which resulted from a failure to sanitize attacker-provided input. A value was used while in a state of taint. AI assistants should be able to go through a codebase and find potentially problematic variables, essentially as a form of automatic taint checking pre-runtime (most languages don't support this).
> The skilled humans will need to be fixing bugs and hunting complex bugs.
Come on, there is no profit in fixing bugs, it's a pointless expenditure: Nobody ever got a bonus for wasting money. They'll just hope client damage stays under the radar, and if it does get noticed, they'll resort to the trusted "our client's security/well-being is very important to us" and promise that they'll do better next time.
Fixing bugs, and investing time and money to create a reasonable system archtecture in the first place, is like paying for fire insurance.
You can choose to not buy your business fire insurance (keeping the premiums money as bonuses), and you usually can get away with it.
Oh, look ... there goes Mrs. O'Leary with her cow and lantern.
The Great Chicago Fire is coming.
>Come on, there is no profit in fixing bugs
There is no prestige in fixing bugs either. I've worked on systems where we were allocated a certain amount of time to chase bugs down and patch them. In addition to regular system enhancements. We always flew pretty much under everyone's radar. On the other hand, I've seen applications lie in states of disrepair until one manager rounds up enough funds to re-engineer, rewrite and re-host. Guess which one cost the company more. Guess who got the big promotion, stock options and adoration (particularly from the vendors involved).
Guess who left for greener pastures before statistics on the new systems infant mortality could be collected.
On one level the spooks who've been using some of these flaws for years won't be pleased that all these flaws are going to be exposed and fixed as they won't be able to exploit them any more... That is assuming there is the skill to fix them all all, I see the Linux kernel doesn't have the resources to fix the recent tranche of defects and will simply delete the code at risk...
Given the shoddy code I see daily inside SAP systems, you do wonder how some systems even work at all... You don't need AI to scan most ABAP code in a SAP system, you just open the code in the editor and look, it's usually dreadful, and SAP's own code is often the worst...
The well-funded spooks will be okay. This is not going to address the truly strategic-level logic vulnerabilities. At best it's exposing everything that isn't memory safe, catching common authentication issues, and a handful of other gotchas. Mostly stuff that could have been fixed a decade or two ago by using appropriate tools to create networked systems with, ones that just avoid long-known vulnerable patterns in the first place.
Code in general remains provably unanalysable at a theoretic level, and programmers will continue to leverage that fact to create more and more interesting bugs. LLMs themselves already give us confidence in that prediction.
I suspect (and in truth, hope) those in the most offensive roles will relish the challenge a little bit more.
«I see the Linux kernel doesn't have the resources to fix the recent tranche of defects and will simply delete the code at risk...»
Well, not exactly true. That code is/will still (be) supported in a myriad of LTS and CIP Kernels for close to a decade. Specifically, on Kernel 6.12 this will be supported by G.K-H until ~2028 and by the Linux CIP until ~2036 (i.e. Long after the patch tsunami has passed), and that Kernel includes the offending drivers, and those drivers will stay there, and if needed be, patched until that time...So, the patches for that code are being developed as-we-speak.
I see this move more as a signal for house clean-up. Just like Windows hoards deprecated API calls without removing them* (but has no qualms dumping old driver models or architectures) , Linux hoards old driver & architecture code for ages. Is just the phylosophy of the OS. This serves as a signal/excuse to dump this code going forward without much opposition.
I wish each OS would be a tad more proactive in dumping old stuff.
* Microsoft clearly states that something marked as deprecated in version N, should be removed in N+2. But very few calls actually meet that fate, and actually is the other way around, most examples are of this rule being violated.
I see the Linux kernel doesn't have the resources to fix the recent tranche of defects and will simply delete the code at risk
Linux has long been removing drivers for obsolete hardware. You're reading something false into what you've apparently read about recently, because it has been going on for a long time.
Besides, eliminating drivers doesn't affect security at all. If there was a known root exploit in an ISDN driver that won't help you break into my system, because I don't have ISDN hardware so that driver isn't loaded.
The do this because when are no longer maintainers interested in continuing to support drivers for old hardware. One of the most important things required of a maintainer is having actual hardware to test again (and ideally, use in production) which isn't realistic for ancient hardware. Older kernels don't stop working though, and there are "long term support" kernels that will get all the upcoming security fixes for years that still support this hardware.
In many cases these will be mature, well-understood systems that have been ticking away for years supporting their operators' money making businesses. Suggesting the business be disrupted to replace them - at maybe considerable expense - by a new, unknown can of worms will not go down well.
Mature and well-understood might not be a realistic characterisation of all of them but it will be how they will be perceived.
Oddly enough, where I work we have a proactive programme of identifying such obsolescent old warhorses and developing modern equivalents /before/ they break. So when they get too expensive to support or impossible to fix, we have a drop-in replacement ready. Starved of resources of course, but we do work it as best we can. A rising problem is perfectly good kit, but with supplier-maintained OS that is no longer supported and the license is no longer renewable, causing the thing to brick itself - at the worst possible moment, natch.
Imagine code bug bounties being generated in record time and numbers. Soon HFT bug hunting will fill the existing code base with more bug filled fixes as the fixes will need more fixes. All Vibe coded of course! And Vibe tested in the field. And more AI bug hunting and more fixes! It boggles the mind! The economies of circular programming! Waterfall model? Rapid Prototyping model? Pah humbug ! AI overlords for the win!
I suspect that is one those "of the three, choose two" dilemmas.†
Probably a very good to retire before this tsunami of accumulated shit inundates one's career and pension plans.
† ok there are three choices but being caught on the horns of a trilemma sounds rather rude.
The greater concern regarding this ability of 'AI' to find these vulnerabilities that have previously been missed, is that the ease with which it appears to find them means that criminals will be able to use similar 'AI' tools to find them quickly too. Prior to this new ability to find the bugs, they had stayed undiscovered by bug hunters and criminals alike for years and had not become a real world threat.
Now, almost overnight, they are all vulnerabilities that the criminals can easily discover very quickly and they all become a major threat at the same time.
If 'AI' is making the finding of vulnerabilities this easy, and judging how long it will take to come up with workable patches, I am not convinced that in the short to medium term, up-to-date versions of software are necessarily going to be any more secure than those which are out of support.
Apparently it took a single operator at Xint 1 hour using AI to discover the Copy Fail vulnerability in the Linux kernel. A very simple exploit to root that has been lying there for 9 years and possibly probably quietly exploited.
The genie is out of the bottle.
Or in another universe, this never happened because linux is open source and anyone can inspect the code so it's more secure.....
Not really too much of a concern…
” Models like Anthropic's Claude Mythos and OpenAI's GPT-5.5-Cyber promise to find and fix bugs before attackers do”
The only way this can happen is for developers to run the models BEFORE they release their product. Ie. Move away from treating customers/users as alpha and beta testers…
>” I am not convinced that in the short to medium term, up-to-date versions of software are necessarily going to be any more secure than those which are out of support.”
With the move to 64bit windows some years back, I suspect your 32bit Windows might actually be slightly more secure now than it was in its final years of mainstream support, because no one is actively creating new exploits for it…
The internet is the threat. Disconnect stuff from the net, entirely: No SaaS, no cloud, no AI, no updates. It is now secure from attack. An entire intranet of Windows95 PCs that is not connected to the internet is safer than a single W11 PC that is fully updated, but which is connected to the net.
Then use simple internet facing systems that do not retain data and do not connect to internal systems - dumb terminals, chromebooks, whatever. Air gap with people.
In one scheme, a fraudster took the blank, Magnetic Ink Character Recognition ("MICR")-encoded deposit slips out of the back of his checkbook, and placed them at the top of a stack his bank's trays of "blank deposit slips". The bank's blanks had ink-based, yet not MICR-based, printed dummy routing and account numbers at the bottom.
You can visually-tell the difference if you are looking, or simply have a mind which notices such things.
Many people unknowingly deposited their funds into the crook's account, and nobody noticed the deposit slip switch until people started complaining and the bank investigated.
The more sophisticated version, used the banks slips or cheques but used different MICR coding, so on a visual inspection the slips/cheques looked no different.
The “joys” of cheque printing and payments fraud, something a circa 2006 project delved into…
> "All organizations have 'technical debt'; a backlog of technical issues – that is both expensive and time-consuming – as a result of prioritising short-term gains over building resilient products,"
Do remind me, who is notorious for refusing to be rushed and will only release code "when it's ready"? Begins with a D? Not MS, Google or Apple, o-o-oh, who else is there...?
Celebrate, software engineers!
We'll have work for decades to come, fixing technical debt, because it's such a fulfilling use of time - who wants nice new greenfield projects? /s
They say that each revolution threatening to put people out of work eventually ends up generating as many jobs.
Now we know that AI is no exception.
AI can detect the technical debt and us humans can prompt it to fix the technical debt.
We get to spend our time reviewing AI generated code, rather than coding ...
... because, you know, we didn't get into this software game because we enjoyed the art of coding, did we? /s
I see your sarcasm, but there are actually plenty of coders who get a bigger kick out fixing bugs and refactoring code to make it better, rather than the unwinnable task of creating really great brand new code on first pass.
Abtruse logic, spagetti code, non-existing documentation - all ensure eternal job security of coders in overstaffed tech companies, which is to say, almost all tech companies going by the Old Silicon Valley Jungle Saying "A well run tech company is 2X overstaffed; a badly run tech company is 4X overstaffed". No wonder there's so much technical debt in software in the first place. More power to AI to flesh it out and refactor the code so that tech companies are finally able to cut their deadwood and take their MSV accomplishments to the next level.
Sensible advice from the NCSC, but it also underlines a harder reality.
As AI accelerates exploitation, patches are increasingly arriving after attacks have already happened.
In that world, patching is still essential, but it is remediation rather than prevention.
We need to complement patching with defenses that reduce risk even when vulnerabilities are unknown or unpatched, such as enforcing the expected behaviour of software at runtime, otherwise the patch race will always be lost.
The NCSC is right that AI is accelerating discovery of existing debt, but there's a second-order problem nobody's talking about: teams are now using AI to write the patches themselves. That code ships fast. What doesn't happen fast is proving that the fix actually behaves the way it's supposed to and doesn't break anything it touched.
Patching velocity is only useful if the patch is correct. The verification gap between "AI wrote it" and "we can prove it works" is where the next wave of incidents is going to come from. Curious how many teams here have a formal answer to that question before code hits production.
The relationship between code, AI, and bugs is completely different than that expectation, if you take what Microsoft has been doing recently into consideration...
I think it would work if every code had very verbose comments of what it is trying to do attached to it, allowing either human or AI to review it. Given we are talking about... x many gigabytes of code, then it would have a fair chance to work as intended...
But as it is these days, nope. Not a snowball chance in hell.
