Georgia Tech's Vibe Security Radar: 35 CVEs From AI-Generated Code in March Alone. Across 5,600 Apps—2,000+ Vulnerabilities, 400+ Exposed Secrets. Is Product Velocity Creating a Security Body Count?

General
1

I’ve been tracking Georgia Tech’s Vibe Security Radar project since they launched it, and the March numbers stopped me cold.

The Acceleration Is Alarming

Their SSLab team tracks CVEs that are directly attributable to AI-generated code—not theoretical risks, but bugs that made it into production and got assigned real CVE numbers:

  • January 2026: 6 CVEs
  • February 2026: 15 CVEs
  • March 2026: 35 CVEs

That’s nearly 6x growth in two months. Across all 74 confirmed cases, Claude Code is responsible for 27, GitHub Copilot for 4, Devin for 2. And the researchers estimate the true number is 5-10x higher—roughly 400-700 CVEs across the open-source ecosystem that simply haven’t been traced back to AI tooling yet.

The Moltbook Case Study

For those who missed it: Moltbook, a viral social network, exposed 1.5 million API tokens and 35,000 email addresses within days of launch. The founder famously “didn’t write a single line of code.” Security researchers found the exposed Supabase API key within minutes—the platform was missing Row Level Security, which is essentially Database Security 101.

This isn’t a story about a bad developer. It’s a story about what happens when the person shipping code has no mental model for what security even means.

Palo Alto’s Unit 42 Findings

Unit 42 isn’t being subtle about this. They’re calling vibe coding a “powerful force multiplier” that’s failing to enforce critical security controls in production. Their real-world incident data includes a sales lead application that was breached because the AI agent “neglected to incorporate key security controls such as authentication and rate limiting.”

They also found that most organizations allow employees to use vibe coding tools, but very few have visibility into their use or monitor for security issues. That’s the scariest part to me—it’s not just startups shipping insecure code. It’s happening inside enterprises where nobody’s watching.

The Product Leader’s Dilemma

Here’s where I’m genuinely conflicted. As a product leader, I’m responsible for shipping velocity AND for the product’s security posture. Those two things were always in tension, but AI coding tools have turned it into a crisis:

Before AI tools: A feature takes 2 weeks. Security review catches issues in week 3. Ship in week 4. Slow, but the process works.

With AI tools: A feature takes 2 days. PRs pile up faster than security can review. The backlog grows. Someone says “we’ll do a security sweep later.” Later never comes.

The velocity gain isn’t free—it’s borrowed from your security budget in ways that don’t show up until a breach.

What I’m Thinking About

  1. Should security review be a hard gate on AI-generated code? Not just a recommendation—a literal CI/CD blocker.
  2. Do product teams need security literacy? Not just engineers—PMs, designers, anyone who prompts an AI to generate code.
  3. Is the SHIELD framework (Palo Alto’s governance model) practical for startups? Or is it enterprise-only?
  4. How do you measure the security cost of velocity? Like, actually put a number on it for a board deck?

I’d love to hear from people who are actually navigating this. Are you blocking AI-generated code from certain surfaces? Have you implemented security gates? Or are you just hoping your pentest catches everything?

The Georgia Tech dashboard is updating in real-time. The trend line is going up. At some point we need to talk about this as a product risk, not just an engineering problem.

2

Okay I need to talk about this because I am literally the person this post is describing.

Last month I was building a side project—an accessibility audit tool—and I used Cursor to scaffold the whole backend. Prompts like “create an Express API that stores audit results in Postgres” and “add user authentication with JWT.” It worked. It ran. I shipped a beta to 15 people.

Then a friend who does security consulting offered to take a look. Twenty minutes later she sent me a screenshot of my .env file contents. Not from my machine—from the deployed application. The AI had helpfully included a debug endpoint that dumped environment variables, and I never thought to check because the app worked.

That’s the Moltbook problem at a smaller scale. The code was functional. The tests passed. The app ran. Nothing in my workflow flagged that a debug endpoint was exposed because I didn’t know to look for it. I have decent HTML/CSS skills, I can read React, but I have no mental model for “what does a secure API look like.”

The Vibe Security Radar numbers don’t surprise me at all. What surprises me is that it took this long for someone to start counting.

Here’s my concern for the design community specifically: the no-code/low-code movement already trained people to ship without understanding infrastructure. AI coding tools are the next evolution of that. We’re about to have a generation of product builders who can create genuinely useful things but have zero intuition for security boundaries. And the tools themselves don’t teach you—they just do what you ask.

I’ve since added a security checklist to my side project workflow (thanks to that friend), but I had to seek that out. Nothing in the AI tooling suggested I should.

@product_david your question about “do product teams need security literacy” is the right one, but I’d push it further: do we need security literacy to be a prerequisite for using AI coding tools? Not a gate—more like a required tutorial before your first deployment. The way Figma teaches you about export formats before you can publish.

3

This thread hits on something I’ve been escalating internally for months.

We’re a 120-person engineering org running on a mix of Cursor, Claude Code, and Copilot. I ran an internal audit in February: 43% of our commits in Q4 2025 had significant AI-generated content, but only 12% of those went through our security review pipeline. The other 88% went through standard code review, where the reviewer is checking for logic and style—not for exposed secrets or missing auth boundaries.

The math is straightforward: we quadrupled our code output while keeping security review capacity flat. That’s not a gap—it’s a canyon.

Here’s what we’ve implemented since:

1. Tiered Security Gates
Not all AI-generated code is equal risk. We categorize by surface area:

  • Tier 1 (external-facing, auth, payments): Mandatory automated SAST + manual security review. Hard CI/CD block.
  • Tier 2 (internal APIs, data processing): Automated SAST only, with sampling for manual review.
  • Tier 3 (tests, internal tools, documentation): Standard review process.

This lets us focus security capacity where the blast radius is highest.

2. AI Security Linting
We added custom rules to our linting pipeline specifically targeting AI-generated patterns: hardcoded credentials, overly permissive CORS, missing rate limiting, debug endpoints, and exposed environment variables. These are the patterns Georgia Tech’s data shows up most frequently.

3. Quarterly Security Sprints
Every quarter, we dedicate one sprint entirely to security debt. Not new features—just reviewing what shipped in the prior quarter for security issues. It’s painful in terms of velocity, but it’s caught 3 significant issues in the last cycle alone.

To your question about SHIELD, @product_david—the framework is sound in principle but heavy in practice. We adapted it rather than adopted it wholesale. The key pieces: Separation of Duties (the person who prompts shouldn’t approve their own security review) and Human in the Loop (no AI-generated code touching auth or payments without human sign-off). The other components are aspirational for most organizations under 500 engineers.

The Georgia Tech acceleration curve concerns me because it tracks almost exactly with AI coding tool adoption curves. More people using these tools → more CVEs. And adoption isn’t slowing down.

4

Great breakdown, David. This is one of those topics where the data finally matches what we’ve been feeling on the ground.

I manage 40+ engineers at a Fortune 500 financial services company. Financial services. Regulated industry. And even here, the vibe coding creep is real.

Our situation: we explicitly approved Copilot for internal use in mid-2025. We set up governance guardrails. We did the training. We thought we were ahead of the curve. Then in January we discovered that three different teams had independently started using Claude Code through personal accounts because it was better for complex tasks. None of that code went through our approved pipeline. One team had been doing it for four months.

This is the Unit 42 finding in practice—“most organizations allow employees to use vibe coding tools, but very few have visibility into their use.” We didn’t even allow it. They just did it anyway because the productivity gain was too compelling to ignore.

Here’s what worries me about the Georgia Tech numbers from a team management perspective:

The review problem is a people problem. You can build all the CI/CD gates you want, but security review requires humans who understand both the code and the threat model. Those people are expensive and scarce. When your team’s code output doubles or triples overnight thanks to AI, you don’t magically get more security reviewers. You get the same three people now responsible for 3x the code surface.

At our scale, we’ve responded by:

  • Making security review a rotation, not a dedicated role. Every senior engineer spends one sprint per quarter as the security reviewer for their team. This builds security intuition across the team rather than concentrating it.
  • Investing in automated scanning specifically tuned for AI patterns. Our AppSec team maintains a custom ruleset that catches the most common AI-generated vulnerabilities. It doesn’t catch everything, but it catches the obvious ones—and the obvious ones account for 70-80% of the Georgia Tech CVEs.
  • Tracking AI-generated code as a metric. We can now see what percentage of each PR is AI-generated, which teams are generating the most, and which teams have the highest security finding rates. The correlation isn’t subtle.

@cto_michelle your tiered approach is smart. We’re implementing something similar. My addition: the tier should be determined automatically based on what files are touched, not by the developer self-reporting. Developers will always classify their own code as lower risk.

5

This conversation is surfacing something I’ve been thinking about from the organizational design side.

We’re scaling from 25 to 80+ engineers right now. Every candidate I interview has AI coding tools in their workflow. Most of them are honest about it—they use Cursor or Claude Code for 40-60% of their daily output. That’s fine. Expected, even.

But here’s what’s changed in interviews: I now explicitly test for security intuition, and the results are concerning. I’ll describe a scenario—“you’re building a user registration endpoint”—and ask what security considerations they’d think about before shipping. Two years ago, even junior candidates would mention input validation, password hashing, rate limiting. Now? A significant number say something like “the AI handles that” or “I’d prompt for a secure implementation.”

They’re not wrong that the AI handles it sometimes. But they’ve lost—or never developed—the ability to evaluate whether it was handled correctly. The Moltbook founder didn’t know to check for Row Level Security because the concept wasn’t in their vocabulary. That’s becoming a wider pattern.

From an org design perspective, this creates a few challenges:

Hiring: Do we filter for security knowledge as a hard requirement now, even for frontend roles? That shrinks an already tight talent pool. Or do we accept the gap and invest in training?

Team structure: @cto_michelle’s tiered approach assumes you have enough people with security expertise to staff Tier 1 reviews. At our scale (25 engineers today), that’s maybe 2-3 people. If they’re reviewing every external-facing PR, they become a bottleneck that erases the velocity gain from AI tools.

Career development: If junior engineers never develop security intuition because AI handles it, what happens when they become senior engineers responsible for architecture decisions? We’re building a generation of senior engineers who can ship fast but can’t assess risk.

What I’m actually doing about it:

  1. Security modules in our onboarding. Every new engineer, regardless of level, completes a 2-day security fundamentals course that specifically covers AI-generated code vulnerabilities. We use real examples from the Vibe Security Radar.
  2. “Break your own code” exercises. Monthly, engineers pair up and try to find security issues in each other’s recent PRs. Gamified, low-stakes, but it builds the muscle.
  3. Security champions program. One engineer per team gets additional security training and serves as the first-pass reviewer for security-sensitive changes. This distributes the knowledge without creating a bottleneck.

The Georgia Tech data is a gift, honestly. It gives us concrete evidence to justify security investments that would otherwise get deprioritized for feature work. I’m using those charts in my next board presentation.