The Next Era of AppSec: Why AI-Generated Code Needs Offensive Dynamic Testing

My colleague Manoj Nair recently wrote about the growing gap between what AI builds and what security teams actually test. He made the case that the speed of AI-driven development has fundamentally outpaced validation, and that the response can't be to slow down, but to change what testing means. I agree with every word.

What I want to do here is go one level deeper. I've spent the better part of a decade building Dynamic Security Testing engines. First at Probely, which I co-founded, and now at Snyk, where our technology powers Snyk API & Web. So, when I say that everything about how this industry thinks about Dynamic Security Testing is about to change, I'm not making a market prediction, I'm describing what I see happening in the architectures we test every day.

Code analysis got dramatically smarter. It's still not enough.

Let's start by giving credit where it's due: static analysis has made enormous leaps.

For years, the category was stuck in an era of rigid, noisy pattern matching, with rules-based engines that generated volumes of findings but very little signal.

Then came a first wave of machine learning and symbolic AI that could trace deeper data flows across codebases: engines like Snyk Code, powered by DeepCode AI, which brought real semantic understanding to static analysis.

And now, we're seeing a genuinely different capability emerge: agentic tools that use semantic reasoning to understand the actual intent of the code, not just its syntax. These models can flag complex business logic flaws and authorization issues directly from source code in ways that would have been unthinkable five years ago.

This is a real and meaningful advance. It has grown so much, in fact, that it's an open question whether the industry will keep calling this "SAST" or coin a new term for it entirely.

But here's the thing: even the most advanced code analysis engine has a limit: it cannot test what it cannot run.

Modern applications are not monoliths; they are heavily distributed, composed, multi-tiered environments: single-page applications communicating with dozens of backend microservices, each with their own authentication context, data access patterns, and deployment lifecycle. A sophisticated code scanner might successfully flag an authorization flaw within one microservice's codebase. But what if the vulnerability only manifests when multiple components interact?

Consider a real scenario: an authorization issue that only surfaces because of how a frontend application handles a token, combined with how an API gateway routes the request, combined with how a secondary backend service interprets the user's role. No single codebase contains the vulnerability. It emerges from the interaction. Static analysis, no matter how intelligent it may be, struggles with inter-component state across codebases, because it fundamentally cannot observe the system as a whole.

That's exactly what Dynamic Security Testing can do. It can validate whether an attacker can actually exploit a system when all those disparate components are stitched together in a live environment.

This execution blind spot extends directly to the frontier that Manoj described: AI agents calling APIs autonomously, at scale, in ways their builders never anticipated. Risks like prompt injection, goal hijacking, and context poisoning don't exist in the source code. They are emergent behaviors that only happen at runtime. Just like those complex microservice interactions, these threats can only be validated by dynamically interacting with the live system.

The convergence nobody is naming

Something else is happening in the market that I think deserves more direct attention.

Over the past year, a new label has emerged: the "AI Pentester". And the label captures something real, as these tools represent a genuine shift in approach. Instead of a rigid scanner that throws static payloads at every input it finds, this new breed of tool can reason about the application's state and decide on its next steps based on context, much like a human security researcher would.

But here's what I've observed, and what I think the market is getting wrong: these approaches are fundamentally complementary, not competitive.

We recently tested a deliberately vulnerable application using both a traditional Dynamic Security Testing engine and a standalone AI-driven pentesting approach, and let me tell you: the results were telling.

The Dynamic Security Testing engine found vulnerabilities the AI-driven approach missed, simply because traditional engines are built for relentless, mechanical exhaustiveness, as they will methodically test every parameter, every endpoint, every edge case.

Meanwhile, the AI-driven approach found complex logic flaws the traditional engine couldn't comprehend, because it could reason about authorization chains and business logic in ways a deterministic scanner never could.

Neither alone was sufficient. Both together painted a far more complete picture.

This tells me that the industry is clearly heading toward a convergence. The future product in this category will likely blend both capabilities: an exhaustive mode for comprehensive pipeline coverage (the kind organizations need for continuous assurance), alongside a targeted, context-driven mode for deep, logic-based exploitation (the kind that finds the authorization flaws and chained vulnerabilities that AI-generated code introduces at scale).

The exact label, whether the market sticks with "DAST," pivots to "AI Pentesting," or invents something entirely new, is still somewhat unknown. But the convergence itself feels inevitable.

Where this is heading

If I had to describe the most important architectural shift on the horizon, it would be that code-level intelligence and Dynamic Security Testing are becoming deeply intertwined.

For most of its history, Dynamic Security Testing operated as a black box, with no knowledge of the source code, no understanding of the application's internal logic. It probed from the outside and reported what it found. That was both its strength (it tested reality, not theory) and its limitation (it was blind to context that could make it dramatically more effective).

That's changing. As platforms mature, the natural trajectory is toward what security researchers have always called "grey-box" testing: an approach that simultaneously interacts with the live application and understands the underlying source code. In one direction, code-level analysis can hypothesize hidden endpoints or logic flaws that Dynamic Security Testing then proves (or disproves) in the live environment. In the other direction, and this is closer to how elite human hackers actually operate, Dynamic Security Testing might observe suspicious behavior when applications or APIs are live, and then use code-level context to understand exactly how a protection is implemented, crafting the precise payload needed rather than brute-forcing.

This also starts to solve what has historically been one of the biggest friction points with Dynamic Security Testing: remediation. A dynamic tool could always prove an exploit existed by showing the malicious HTTP request and response, and evidence of exploit, but it left the developer guessing about where in the codebase the flaw actually originated. When dynamic proof and code-level context are correlated, you get something much more powerful: a finding that proves exploitability at runtime and points directly to the code that needs fixing.

That's the trajectory worth watching. Not because any single vendor has fully realized it (though we did), but because the architectural prerequisites are falling into place, and the teams that recognize this convergence earliest will build the most defensible security programs.

This builder's conviction

I'll close with something I've come to believe more strongly with every architecture we test.

The era of treating Dynamic Security Testing as a compliance checkbox, of slow, noisy scanners you run quarterly and file the results away, is fading. Not because the idea was wrong, but because the world around it has changed.

AI-generated code ships faster than any human process was designed to review, AI Agents invoke APIs faster than any inventory was designed to track. And the class of vulnerabilities these forces introduce, such as broken authorization, business logic flaws, and cross-component state failures, are precisely the class of vulnerabilities that only Dynamic Security Testing can definitively prove.

What's emerging isn't a replacement for code analysis, but the other half of the equation: code analysis tells you what might be vulnerable, but Dynamic Security Testing tells you what is exploitable. When those two signals meet, the noise drops and the signal sharpens... developers can ship with confidence, instead of anxiety.

If you're building a security program for the AI era, that confidence is the asset worth investing in.