Ryan McGeehan

A return to shallow bugs

What is the "Vuln Apocalypse"?

The cybersecurity community is realizing that AI can find security vulnerabilities in software at a scale we might not be prepared for. “A return to shallow bugs” is the framing I like most. It gives us permission to do practical things now instead of arguing over the exact size, shape, and sulfur content of the apocalypse.

How does this impact a security program?

Compressed disclosure cycles

If you can find a bug cheaply, others can too. We should expect more valid vulnerability disclosures from outside researchers, customers and partners, and security companies.

Internal vulnerability discovery will accelerate as well. We will eventually have access to the same powerful AI tools that could be used against us. Expect your own AI assistants to audit your OSS dependencies and hand you someone else’s vulnerability.

Dependency Patching Accelerates

Compressed disclosure cycles will lead to more frequent open source patches than we're used to. Upstream projects are likely to face broad AI-assisted vulnerability hunts, and even a modest increase in findings will cause unplanned patches.

Organizations that publish open source code or binaries will be most impacted.

Early security hires are more viable

A capable CLI harness at a codebase with the right prompting and workflow will make an early hire very impactful. However, humans will still need to verify vulnerability findings. We're not yet able to trust an AI product that claims they've verified an exploit end to end. We need in-house resourcing to take AI vulnerability finding end to end.

Build the walls

Shallow bugs are best targeted with broad mitigations that handle large vulnerability classes. Attackers with powerful AI models are going to be shaking out bugs, but we should be building out robust mitigations.

For example:

AI is really good at identifying these opportunities in a codebase if you have someone available to drive them.

Patch and Release

Patch and release must be at comparable speed to vibecoding. If the volume of bugs increases, then the PR volume will increase. A breakdown will occur when vuln fixing is not viewed as the standard development workflow. Security teams need to be prepared to generate code as quickly as their peers, and own it with the same standards and guardrails that peer engineering organizations are enforcing.

Putting the "Vuln Apocalypse" into perspective.

I want to frame this around some formative memories of mine. I keenly remember discovering vulnerabilities in the early oughts immediately after learning about a type of attack. For example, I discovered an AOL Instant Messenger vulnerability in 2004 very shortly after learning what a buffer overflow was. When I found the XSS cheat sheet by rsnake, I remember finding valid XSS in nearly every website I tested. Similar for CSRF, which I learned about in 2004. Effectively all websites were vulnerable to this for years.

In that same time period it was fairly common to expect a mass worm, followed by a mass botnet when RCE vulnerabilities were found. Widespread browser exploitation happened on a near monthly basis.

My early vulnerability research was low sophistication, but still impactful. In those days, bugs were shallow. That was just normal. The internet suffered a long grind of framework level mitigations to get where we are. It has been a long time since those days. Now, I think the last ten years or so have been relatively difficult for those looking to jump right into vulnerability research and easily find live bugs.

I think that the "Vulnpocalypse" is a return to shallow bugs, but we're not unprepared to handle the future. Adversaries are far more capable of taking advantage of vulnerabilities, but I also think the constructs we have to respond to internet wide events are much better than they used to be. Overall, we will be judged on mitigation coverage and response speed more than novelty in our security programs.