Time to Shift Right Again: Why AI-Speed Development Demands Runtime Security

Here's a controversial take that might upset a decade of security doctrine: It's time to shift right again.

For years, we've evangelized "shift left" — move security earlier into development. But AI-assisted development has created a new reality that demands we reconsider. When code ships faster than humans can review it, when dependencies update by the hour, and when AI helps write code at machine speed, we need to accept an uncomfortable truth:

Traditional security can't keep up with AI-speed development. The only defense that scales is behavioral detection at runtime — everywhere.

The Velocity Problem No One Wants to Admit

Let's be honest about what's happening in modern enterprises:

• High-performing teams deploy 10-50+ times daily
• AI assists in generating significant portions of code
• Applications pull in ~200 direct dependencies, ~1,500 transitive ones [1]
• Each dependency review takes 15-30 minutes
• Updates arrive weekly, sometimes daily

When you have dozens of applications with hundreds of dependencies updating constantly, the math becomes impossible. Teams face hundreds of hours of review work weekly. Even with automation and AI assistance, human review capacity is now the bottleneck.

This isn't a tooling problem. It's a fundamental mismatch between development velocity and security review capacity.

Why Runtime Security Is Finally Viable

For years, runtime security meant choosing between protection and performance. Traditional agent-based solutions consumed 10-100%+ CPU, made troubleshooting harder, and broke applications. Security teams couldn't justify the trade-offs.

But modern runtime security has solved these problems:

• 1-5% typical overhead using eBPF kernel technology (vs 10-100%+ for traditional agents) [3][6]
• Zero application changes required
• Behavioral detection that catches novel threats
• Automated blocking without human intervention

We finally have runtime security that's both effective and practical for production use.

The AI Development Reality Check

AI isn't just accelerating development — it's fundamentally changing risk patterns:

Traditional security approaches assume humans can review what they deploy. That assumption no longer holds.

SAST finds known patterns — SQL injection, hardcoded secrets — but it's blind to intent. When curl downloads dependencies, SAST can't tell if it's fetching from npm or exfiltrating to attackers. The code looks identical. Only runtime behavior reveals the threat.

AI-speed development amplifies this blindness. Every AI-suggested package widens the gap between "syntactically correct" and "behaviorally safe." Runtime security closes this gap by watching what code does, not what it looks like. It's the difference between reading a recipe and tasting the soup.

What "Shift Right" Really Means: Runtime Security Everywhere

Let's be clear: this isn't about abandoning the pipeline for production. It's about recognizing that traditional "shift left" tools have a fundamental limitation — they only detect known vulnerabilities through signatures and patterns.

Traditional shift-left limitations:

• SAST (Static Analysis) only finds known code patterns and can't see runtime behavior
• SCA (Software Composition Analysis) only flags known CVEs in dependencies
• Code review can't scale to AI-generation speeds or catch novel attack patterns

"Shift right" means deploying runtime behavioral monitoring across your entire software lifecycle — in CI/CD pipelines, test environments, AND production. This approach catches:

• Zero-day exploits through anomalous behavior, not signatures
• Supply chain attacks as they execute, even from "trusted" dependencies
• Time-delayed threats that activate only under specific conditions

Runtime security in your pipeline means detecting malicious behaviors during builds and tests — not just known bad packages. When a dependency tries to exfiltrate data or mine cryptocurrency during your CI/CD run, runtime monitoring catches it immediately, while traditional tools see nothing wrong.

Runtime Security in Action: Pipeline to Production

During the CI/CD build, runtime monitoring detects the hidden malicious behavior:

• The package making unexpected network connections during npm install
• Attempting to read environment variables containing secrets
• Spawning hidden processes to establish persistence

This is a zero-day supply chain attack that every traditional tool missed. Only runtime behavioral analysis caught it — before it reached production. For a real-world example, see how Garnet blocked malicious NPM network calls from the ngsma-commons package, which attempted data exfiltration to OAST domains during both build and runtime.

Runtime security in action: Garnet automatically blocked this exfiltration attempt to a suspicious OAST domain. The connection was identified as malicious and stopped before any data could leave the system — something static analysis would never catch.

Modern runtime security monitors these behavioral invariants across all environments:

# Example: Crypto miner detection patterns (works in CI/CD and production)
- File access: /tmp/.minerd, /var/tmp/kworker
- Process patterns: High CPU + specific syscall sequences
- Network: Stratum protocol to mining pools (TCP 3333, 8333)
- Resource anomalies: CPU/GPU spike without corresponding app load

The industry average breach detection time is 204 days [7]. With runtime security, that drops to minutes for active threats.

The Strategic Imperative

Organizations face a choice:

1. Maintain the status quo: Keep believing pre-deployment security can catch everything while AI-speed development overwhelms your defenses
2. Embrace the shift right: Deploy runtime security that operates at machine speed to match your AI-accelerated development

This isn't about admitting defeat. It's about adapting security strategy to match development reality.

Of course, deploying runtime security everywhere creates a new challenge. When you're monitoring behavioral patterns at scale, you hit a fundamental problem: the difference between malware and legitimate software isn't what they do — it's intent. The same API call, the same file access, the same network connection can be perfectly legitimate or deeply malicious depending on context. Traditional rules and signatures can't determine intent, which is why security tools drown teams in false positives when they try to scale.

Running application security at one of Canada's largest banks taught me that humans can instantly recognize malicious intent — but can't watch kernel events at 50,000 per second. Until now, "scaling security" just meant hiring more SOC analysts. But we've cracked the intent problem. In my next article, I'll show you how we determine intent at machine speed with human accuracy. It's shipping in production today, and it changes everything.

References

[1] Endor Labs (2024) - "State of Dependency Management Report." Analysis of enterprise application dependency complexity.

[2] FireEye/Mandiant - "Sunburst Backdoor Analysis." Technical breakdown of SolarWinds attack timeline and activation delays.

[3] OpenTelemetry eBPF Profiler (2023) - CNCF project documentation reporting "1% CPU… are our upper limits in testing and the agent typically stays way below that."

[4] Netflix (2024) - "Continuous Load Testing with Netflix.Dispatch." Netflix TechBlog demonstrating eBPF instrumentation with "less than 600 nanoseconds" overhead per scheduler hook.

[5] Lim et al. (2024) - "SafeBPF: Hardware-assisted Defense-in-depth for eBPF Kernel Extensions." CCSW 2024, showing at most "4% performance overhead on macrobenchmarks."

[6] Groundcover (2023) - "eBPF vs Traditional Observability Agent Performance Benchmark." Comparative study showing eBPF agent at ~9% CPU overhead vs 249% for traditional agents.

[7] IBM Security (2024) - "Cost of a Data Breach Report." Mean time to identify and contain breaches.