Detection is the moat

Vulnerabilities used to be somewhat democratic. We had similar software, similar tools and the same 24 hours. This gave balance to offense and defence for a while, but AI is not democratic. The release of Mythos shows that there is an advantage to those with more capital and access, it is undemocratic.

The cost of finding vulnerabilities is between 3 to 6 figures; however, it’s a small price relative to its accomplishments. The issue is that the tokens spent by software companies to find vulnerabilities will be minimal compared to nation states and threat actors. Adversaries will hoard these capabilities and vulnerabilities for exploitation, meaning it will be up to the disadvantaged with weaker AI models and less capital to find exploits and, if they choose to do so, disclose and patch them.

This is problematic because our critical infrastructure and organisations cannot patch the unknown. Models like Mythos were handed to organisations such as banks but this is irrelevant as they do not make all software in house and they are constrained in terms of capital spent on AI source code review. There’s simply too much software to test, and it’s close to impossible to patch the unknown.

More CVEs, more problems

We have seen an uptick in CVEs published annually. There are more CVEs published in 2026 than in 2025, NIST has tracked a 263% rise in CVE submissions since 2020. It’s clear that with more vibe-coded applications and AI models there is an increase in vulnerabilities coded and an increase in model vulnerability detection, we’re seeing more CVEs published. Whilst CVE counts poorly capture severity and exploitability we know capabilities will only improve, especially with Reinforcement Learning.

That’s only the published half of the picture, though. The other half, undisclosed zero-day exploitation happening in the wild, is what should actually worry us. It’s the half we can’t accurately measure.

CVEs published per year

Detection is the moat

Patching will remain important, and vibe-coded software needs to shift further left: tighter patch cycles, more automation, more verification. I’m confident that part gets easier over time. What doesn’t get easier is the unknown.

That’s because patching and detection don’t share the same economics. Patching requires knowing what’s broken first. It scales with how much code you can review and how fast you can fix it, which is exactly where the capital gap between defenders and well-funded adversaries bites hardest. Detection doesn’t require knowing the specific vulnerability in advance; it relies on recognising behaviour that looks wrong, regardless of which exploit produced it. That’s a cost defenders can sustain without matching an adversary’s offensive budget, because one set of behavioural signals can catch many different unknown exploits, where one patch fixes exactly one.

That’s why assumed breach is the right posture going forward. Organisations need to emphasise detection in practice, not just accumulate detection rules. The best way to do that is red/purple teaming: testing how effective controls actually are, and repeating that process continuously rather than periodically.

Companies like CrowdStrike have good detection products, but they don’t go far enough. Monitoring software behaviour will be essential, and so will anti-tampering.

What’s next?

There’s an argument that blue teams will catch up. At the time of writing, I disagree. LLMs are strongest at coding and will naturally improve at vulnerability detection simply because a vulnerability is a bug with consequences. To my knowledge there has been minimal growth in defensive products that leverage AI. Whoever has the better model and more capital wins, and software companies simply don’t have the capital to compete with nation-states.

Cyber capabilities will keep growing. More companies are paying for training data, and Anthropic is hiring for cyber-focused RL, though these capabilities will likely stay restricted to a handful of organisations. It’s reasonable to assume other countries are pursuing the same path so as not to fall behind. Once again this does not make us more secure if the model is limited to select partners.

We will see specialised models tasked with finding vulnerabilities and exploitation

We may not even be able to track these capabilities properly. The public can’t benchmark them, governments may want to hide how well their models perform, and open-source models likely won’t get cyber-specific RL. So it’s genuinely hard to know how much stronger this gets, and how fast.

AppSec is a minimum

Whilst this is not specific to nation states, the infinite software crisis also creates the infinite vulnerability crisis. AI has decoupled software output from engineering headcount, non-engineers can now ship functional code without comprehension.

As a result I believe AppSec Engineers will become more important and should be adjust pipelines and guardrails so that AI coding agents can run pipelines and create an automatic feedback loop where code is tested for vulnerabilities and fixed.

Blue teams will need to ensure that there is appropriate coverage on all machines and tooling needs to be better before these capabilities become stronger. Assumed breach is the best way forward in the AI world.

To conclude, I believe blue teaming will need to grow to not only defend against unpatched software. Detection currently is okay but it’s not enough, applications and their behaviour will need to monitored more closely to detect anomalies. Red teaming is vital to ensure that defences are good in practice.