Anthropic recently launched Claude Code Security. Using its most advanced model, Claude Opus 4.6, the tool found over 500 high-severity vulnerabilities in production open-source codebases. These are bugs with security implications that had survived decades of expert review, continuous fuzzing, and multiple layers of automated scanning. The cybersecurity market reacted badly: roughly $15 billion in market cap was wiped out in a single day. CrowdStrike fell 8%. JFrog dropped nearly 25%.
The panic was understandable. The conclusion was wrong.
This is a watershed moment for AppSec, and it raises a question every CTO should be asking: If AI can now write, scan, and fix code before it reaches production, does that reduce the need for runtime security?
The answer is the opposite, and I’ll explain exactly why.
What Claude Code Security Actually Does and Doesn’t Do
Let’s give Anthropic credit where it’s due. Claude Code Security isn’t just another SAST tool. Traditional static analysis works by pattern-matching against known vulnerability signatures. Claude reasons through code, tracing how data flows between components, reading commit histories, constructing proof-of-concept exploits and identifying logic flaws that no rule set has ever described. In internal testing, it walked through GhostScript’s commit history and found a bounds-checking error that was patched in one file. It then inferred that every other call to the same function without that patch was still vulnerable and built a crash reproducer. That’s not a scanner. That’s a junior security researcher working at machine speed.
That capability is going to become table stakes. Every major development platform will embed reasoning-based code analysis. The pre-deployment side of the pipeline is being automated, commoditized, and increasingly handed to AI.
But while Claude Code Security reads source code, it does not understand how the code will operate inside the application, in two very important ways.
Runtime Behavior is Predictable from Code
The limitations of static code analysis have been known for years. It cannot send requests through an API stack. It cannot test how authentication middleware chains together in a real deployment. It cannot observe a container’s runtime behavior: the processes it spawns, the network connections it makes, the files it touches or the privilege escalations that only happen under specific workload conditions. That boundary between pre-deployment analysis and production protection is not a limitation that will be patched in a future release. It is architectural.
Add to that the second limitation: applications are not just written; they are assembled.
The Rest of the Stack AI Code Security Doesn’t See
Here’s the part that gets lost in the market reaction: your application isn’t just your code.
Think of a container as three concentric layers. At the center is your application logic, the code your developers write, the code that AI tools can scan and fix. Around that are your frameworks: the Java runtimes, Node environments, Python libraries, and third-party dependencies that make your application function. Around all that is the container operating system: the base image, system utilities, and built-in packages that the whole thing depends on.
AI code security can dramatically improve the security of that innermost layer. The problem is that attackers routinely target the layers around it, where known CVEs accumulate, dependencies drift, and misconfigurations persist. And here’s the critical point: AI can identify vulnerabilities in third-party, open-source frameworks and dependencies, but it cannot fix them. Those packages aren’t yours. You can’t patch them unilaterally. The window between discovery and an available upstream fix is exactly where attackers focus, and they do it in production.
When AI accelerates development velocity, more code reaches production faster. More dependencies shift. More configuration changes occur between build and deployment. The entire attack surface expands faster and in less predictable ways.
The Shift-Left Paradox
Our industry has invested heavily in shift-left for over a decade. The premise was sound: find and fix vulnerabilities earlier, and fewer will reach production. AI-powered code scanning is the ultimate expression of that philosophy.
And yet, as we’ve argued plainly: despite years of shift-left investment, pristine software remains an aspiration. Vulnerabilities still escape into production or are brought in via open-source dependencies. Remediation is still expensive. Security teams still operate reactively.
Claude Code Security sharpens that paradox rather than resolving it. By making pre-deployment code scanning dramatically more effective, it will reduce the volume of code vulnerability classes reaching production. But the vulnerabilities that do get through will be harder to find, more context-dependent, and more dangerous. They will be the ones that only manifest at runtime, like broken access controls that result from deployment misconfigurations, cryptographic weaknesses that surface only under specific workload conditions, or behavioral anomalies that no amount of source code analysis could predict. All these are in addition to known vulnerabilities in dependencies, and the countless vulnerabilities yet to be exposed when attackers use AI.
Anthropic acknowledged this directly: the same reasoning capability that finds vulnerabilities can also help attackers exploit them. If adversaries are now using AI to discover zero-days at scale, which Anthropic’s own research shows is possible, then the attacks that reach your runtime will be increasingly novel and sophisticated.
AI-powered code scanning makes the left side of the pipeline dramatically smarter. But it fundamentally cannot see what happens after kubectl apply. The vulnerabilities that appear in incident reports, the ones that actually cause breaches, are overwhelmingly runtime events: misconfigured containers that escalate privileges, supply chain dependencies that phone home to unexpected endpoints, workloads that drift from their approved image in ways no code scanner could predict. As AI-generated code accelerates deployment velocity, the runtime security layer doesn’t become less necessary, it becomes mission critical.
What Runtime Security Actually Delivers
This is where the argument comes together, and where Aqua’s runtime solution becomes directly relevant.
First: Context that tells you what actually matters. Every security team is drowning in vulnerability data. The question is never “how many CVEs do we have?” It is “which of these CVEs are actually exploitable in this production environment, right now?” That question is answered only by understanding what is actually executing in a live workload at runtime: which processes are running, what network connections are active, and which code paths are reachable. Aqua can validate which vulnerabilities represent real exposure versus theoretical noise. Scanners can flag vulnerabilities in your codebase dependencies. Runtime context tells you whether an attacker can actually reach it.
Second: Depth that only comes from living in runtime for over a decade. Aqua was built from day one around containers and cloud native production environments. We hold patents in runtime container protection. We have spent eleven years understanding how workloads behave under real-world conditions, how drift manifests, how supply chain attacks propagate at runtime, how privilege escalation paths open up under specific deployment configurations that no pre-deployment scanner could anticipate. That depth is not something that can be acquired quickly. It is the foundation that makes runtime protection reliable at enterprise scale.
Third: Rich data output that drives action. Behavioral telemetry from production is not just a security signal. It is operational intelligence. Knowing the exact processes a container spawns, the precise network connections it makes, the files it modifies, and how that behavior drifts from baseline over time gives security and engineering teams something that no amount of pre-deployment scanning can provide: ground truth about what is happening right now. That data feeds smarter prioritization, faster remediation decisions, and compensating controls that work because they are grounded in actual production context, not assumptions.
AI Validates the Runtime Thesis; It Doesn’t Replace It
The center of gravity of cloud security is shifting decisively toward runtime. Not because static analysis lost its value, it hasn’t, but because AI made it clear that the pre-deployment side of the pipeline will be increasingly automated and commoditized by general-purpose AI platforms.
The differentiation, the part that requires deep domain expertise, operational discipline, and a decade of understanding how containers behave in production, lives at runtime.
We founded Aqua on the belief that protecting cloud native applications in production would define the future of cloud security. AI doesn’t invalidate that belief. It makes it urgent.
As AI writes more code, ships it faster, and fixes more of it pre-deployment, the volume and velocity of production changes will continue to grow. Monitoring alone won’t do the job. Shift-left alone won’t do the job. You need a safety net in production that understands the full stack, not just the layer that an AI code reviewer can see.
