AI hackbots found another hundred vulnerabilities. Who fixes them?

8x the code, same number of people to fix it

I was on the Builders & Breakers podcast with STÖK and Kugg last week. The conversation started with a stat from Anthropic: developers are producing 8x the output they were at the start of the year. Good for shipping. Bad for everyone holding the security backlog.

If your competitors ship faster, you ship faster. Every appsec person I talk to has the same problem: they have never had too few bugs in their tracker. The pile was already unmanageable. Now code is coming in at 8x and the fix rate has not moved.

Fixing is harder than finding

You can point an AI at a codebase and it will find vulnerabilities all day. The patch is the hard part. Does it fit with the rest of the code? Does it break something else? A lot of software still has no proper test coverage. You touch one function and you have no idea what you broke three modules away.

I had a first-hand look at this the other day. Someone sent a massive pull request to one of my open-source tools. It was AI-generated, changed parts of the architecture I didn't ask for, and tried to fix ten things at once. As an open-source maintainer you can't merge that. You don't know what it broke, and reviewing it costs more time than writing the fix yourself.

If you play whack-a-mole with individual bugs at the same rate you produce code, you're standing still and burning tokens. The smarter move is root cause analysis. If a whole class of bugs exists because you left a framework setting open or picked a bad default, fix that. One configuration change kills a hundred future findings.

"Use security best practices" leaves things to chance

Models train on all the code on the internet. God knows there's a lot of bad code on the internet. Some of my own repos have deliberate vulnerabilities in them. If you tell an agent "use security best practices," which practices does it pick? The 2024 recommendation? Something it found from 2012?

I've seen agents pick SHA-256 without a salt for password hashing. I had one invent its own authentication token: Base64-encoded timestamp plus user ID. No signature, no expiry logic, nothing. It looked confident doing it, too.

The fix is to stop being vague. We've written secure coding guidelines for companies for years, and developers ignored most of them because the documents were too long. Agents don't care about document length. They'll read the whole thing. So turn your guidelines into skills. Tell the agent: this is how we do authentication here. This is how we talk to the database. This is how you verify you did it right. OWASP ASVS already has checklists for most of this. Pair those with linting rules, and you get agents that write secure code in the first pass instead of fixing their own mistakes in a loop.

One important detail: split your skills by concern. Authentication in one, database access in another, input validation in a third. One giant skill and the agent loses focus. Small, specific, verifiable.

Agents that cheat on tests

I ran into a case where I asked an agent to add a feature and it modified the existing tests to make them pass instead of writing the feature correctly. The old functionality broke. The test suite went green. That's the worst kind of failure because it looks like success.

Newer models do this less. But it tells you something about what we need: better test coverage, yes, but also tests that the agent can't silently rewrite. Linting enforces deterministic rules. Integration tests catch things unit tests miss. You need several layers, and you need to watch the diffs on your test files as carefully as you watch the diffs on your source.

Local models and poisoning

Teams are moving to local and open models to save on token costs, but how much do you know about the training data in the model you downloaded? What if someone plants a pattern that makes it introduce insecure code when it sees a specific library name? You won't find that by inspecting weights.

At the same time, the patch window is closing fast. AI can reverse-engineer a Microsoft patch and identify the underlying vulnerability in hours instead of weeks. So you need to patch faster. But you're also told to hold off on installing new dependencies because they might be compromised. Those two pressures squeeze from both sides and there's no clean answer.

Your application should detect its own attacks

We talked on the podcast about something I care about a lot: detection at the application layer. OWASP had a project called AppSensor that did this. You place sensors inside your application that score anomalous behavior. A user tries to access another org's data? That's a signal. Stack enough signals and you terminate the session, block the IP, or alert the team.

I built this into a system a few years back. It worked. The only real complaint was that pentesters kept tripping the sensors and locking themselves out, which is a good problem to have. We're going to need this kind of defense more, not less. The number of known bugs in running software will grow faster than anyone can patch them. If your application can spot someone attacking the application, that buys you time.

Give open-source maintainers free tokens

I ended the podcast with a request to the big AI companies: give open-source maintainers free tokens. Not for fun. For reviewing the flood of AI-generated pull requests that are already arriving. Maintainers need to verify that a patch does what it claims and doesn't slip in a backdoor. That takes AI to fight AI, and volunteers shouldn't have to pay for it out of pocket. The world runs on open source. And open source needs help.