CVEs Tied to AI-Generated Code Jumped from 6 in January to 35 in March. Here's the Case for Building Governance from Day One.

Here's a number that should stop any team shipping AI-written code: the Cloud Security Alliance's research note reports six CVEs tracked as attributable to AI-generated code in January 2026, 15 in February and 35 in March, drawing on Georgia Tech's Vibe Security Radar. Georgia Tech separately reports 74 total cases, including 14 critical and 25 high. That's a near-sixfold rise in two months on the note's reported chronology, and the Cloud Security Alliance note relays a researcher estimate that the true count across open source is five to ten times higher.

I've been tracking the AI security beat for months, and the pattern is uncomfortable: teams building the plane while flying it. In my observation, the tools got faster and the governance didn't. My read, and it's mine rather than any research finding, is that a big share of the coming security debt traces back to governance that was never built in the first place.

One definition up front, because it changes how you read everything after. When I say vibe coding here, I mean the agentic end of it: software that acts on its own to pursue a goal, generated from a prompt rather than a human nudging autocomplete. The studies below measure AI-generated code a bit more broadly, so I'll flag where each number lands.

Here's my bet, stated up front so you can argue with it: the projects that survive won't be the ones with the smartest model or the cleverest prompts. They'll be the ones where someone thought about guardrails before a single line of code was generated.

TL;DR

• The Cloud Security Alliance's research note reports six CVEs tracked as attributable to AI-generated code in January 2026, 15 in February and 35 in March, drawing on Georgia Tech's Vibe Security Radar; Georgia Tech separately reports 74 total cases, including 14 critical and 25 high. The Cloud Security Alliance note relays a researcher estimate that the true count across open source could be five to ten times higher.
• Veracode found 45% of AI-generated code samples failed security tests and introduced OWASP Top 10 flaws, with Java failing at a 72% rate and 86% of samples failing to defend against cross-site scripting.
• Dataiku cites roughly 25% of AI-generated code containing security vulnerabilities, and its Harris Poll survey found 54% of CIOs have discovered unsanctioned AI use.
• What actually protects you comes down to four things: governance from day one, total-cost tracking, human review on security-critical code, and a platform that bakes governance into the architecture.

How bad is the security problem?

The Cloud Security Alliance published a research note, *Vibe Coding's Security Debt: The AI-Generated CVE Surge*, that should be required reading for anyone running AI coding tools in production. The note reports CVEs tracked as attributable to AI-generated code jumping from 6 in January 2026 to 15 in February and 35 in March, a near-sixfold increase in two months. The Cloud Security Alliance note relays a researcher estimate that the true count across open source could be five to ten times higher than what's tracked as attributable.

Georgia Tech's Vibe Security Radar, the underlying project the note discusses, has separately confirmed 74 cases so far, 14 of them critical and 25 high. March 2026 alone accounted for 35, a figure Georgia Tech notes is more than all of 2025 combined. The radar works by tracing metadata like co-author tags and bot emails through a project's history, so code shipped without those markers stays invisible to it.

Dataiku's enterprise vibe coding post, published in May 2026, cites roughly 25% of AI-generated code containing security vulnerabilities. And here's the part that stuck with me: Dataiku reports that people reviewing that code apply *less* scrutiny than they do to human-written code, because AI output looks polished and confident. The surface finish suppresses the instinct to question it.

Veracode put a finer point on it in its 2025 GenAI Code Security Report, which tested over 100 models. 45% of AI-generated code samples failed security tests and introduced OWASP Top 10 vulnerabilities. Java was the riskiest language, with a 72% failure rate, and 86% of samples failed to defend against cross-site scripting. These studies document vulnerability and comprehension risks that can accumulate as AI-generated code moves into real systems.

Why do most teams skip governance?

Dataiku argues the tools don't ask them to. In Dataiku's framing, set out in its post, vibe coding tools like Claude Code, Cursor, and Replit were built to make rapid building possible, not governable. That means the governance work (the approval flow, the audit trail, the security scanning, the ownership assignment) falls on whoever is using the tool, not the tool itself.

[Dataiku's survey with The Harris Poll](https://www.dataiku.com/blog/enterprise-vibe-coding-problem) found that 54% of CIOs have already discovered unsanctioned AI use for work tasks or projects. That's vibe coding's version of shadow IT, except it moves faster. An application that used to take weeks to prototype now takes hours. In Dataiku's framing, the window for AI governance review is shrinking toward zero.

Then there's the compounding problem: AI-generated code is non-deterministic. Run the same prompt twice, get different output. Dataiku's point is that governance frameworks designed for predictable, static systems break down when the artefact changes every time it's regenerated. Dataiku also names what practitioners are calling comprehension debt, and the ghost code problem: AI agents that catch their own mistakes don't delete the old logic, they rewrite alongside it. Debugging costs compound and the application gets harder to maintain while becoming more load-bearing.

What actually protects you?

Here's my framework, and it's mine rather than any vendor's: four things I'd insist on before AI-generated code goes near production.

One: governance from day one. Every project gets an owner at creation and documents what data it touches and which models it calls. This isn't a review step; it's built into how the project is constructed. What you're after is a platform where the guardrails are baked in from the start, not a governance team that audits projects after the fact.

Two: cost tracking that measures the whole picture. Token pricing is easy to measure. Maintenance debt, security remediation, the engineer you hired to unpick the codebase six months in, that's what actually costs money. Track total cost of ownership from the start.

Three: human-in-the-loop review for anything touching production. Not every AI-generated line needs human eyes, but security-critical code does. Authentication flows, database queries, credential handling, anything touching customer data. These get a human review before they go near production. Define these checkpoints deliberately, not reactively.

Four: pick a platform where governance is structural, not something you bolt on after. Raw AI code generation tools are extraordinary at producing code. What they're not built for is governing what happens after the code is written. In Dataiku's framing, the governance burden falls on the builder rather than the tool. If you're going to lean on AI-generated code at any scale, the governance work still lands on you: name an owner, document what data it touches and which models it calls, and make review a required step before anything ships. In my view, those controls matter more than whichever model produced the code.

Is this already happening?

This isn't a far-off problem. Budget reviews happen annually, and the projects accumulating comprehension debt, unpatched vulnerabilities, and invisible maintenance costs right now are the ones most likely to get cut in the next cycle.

Here's my read, and I'm labelling it as mine rather than any research finding. When you stack the security data together (45% of AI-generated samples failing security tests, a near-sixfold rise in AI-generated CVEs from January to March, 54% unsanctioned AI use already flagged by CIOs), the picture is a category of software that's shipping faster than it's being reviewed. That's analysis, not a sourced statistic.

The question isn't whether your AI-built projects will face scrutiny. It's whether they'll have answers when they do. Who owns each one? What data does it access? When was it last reviewed? If the answer is "I'd have to check," you've already found your first problem.

The takeaway

The security data above tells you what can go wrong. My argument on top of it is that the evidence makes guardrails, an owner, and an audit trail worth prioritising now. That's my read, not a research finding.

So before you build the next one, ask three questions you should be able to answer in a sentence: who owns it, what data does it touch, and when was it last reviewed. If any answer is "I'd have to check," you've already found your first problem.