What is the Vibe Security Radar project and what has it found?

Georgia Tech's Systems Software and Security Lab launched the Vibe Security Radar in May 2025 to track CVEs traceable to AI-generated code. Using AI agents to audit CVE fixing commits across CVE.org, NVD, and GitHub Advisory Database, the project found 35 CVEs in March 2026 alone attributable to AI coding tools, more than all of 2025 combined. Researchers estimate the true number across the open-source ecosystem is five to ten times higher.

Are AI coding tools introducing more vulnerabilities than human developers?

The data suggests they introduce different risks at higher rates for specific categories. Veracode tested over 100 LLMs on security-sensitive tasks and found 45% of AI-generated code samples contained OWASP Top 10 vulnerabilities. AI-assisted commits also expose secrets at more than twice the rate of human-only commits, 3.2% versus 1.5%. The pattern is consistent: AI tools accelerate development but do not apply the security awareness that experienced developers bring to sensitive code paths.

What should security teams do about AI-generated code in their environments?

The Cloud Security Alliance recommends organizations establish explicit SDLC policies covering AI coding tool use before adoption, not after. Specific controls include mandatory secret scanning in CI pipelines (catching the 2x secret exposure rate), SAST on AI-generated pull requests before merge, and code review requirements that do not allow AI-generated code to bypass human review. Dependency analysis is also worth expanding since AI models frequently suggest outdated or vulnerable library versions.

Vibe Coding's Security Debt: Georgia Tech Tracks CVEs From AI-Written Code

The conversation about AI and security has mostly focused on AI as a defender or an attacker. Rarely do people talk about AI as the developer who left the door unlocked. That is changing. A research project at Georgia Tech is building a systematic record of software vulnerabilities that exist because an AI coding tool wrote the insecure code.

The numbers are climbing fast.

Georgia Tech’s Vibe Security Radar

In May 2025, the Systems Software and Security Lab at Georgia Tech launched what they called the Vibe Security Radar: a system to track how many publicly filed CVEs can be traced back to AI-generated code. The methodology is deliberate and traceable. The project pulls from CVE.org, the National Vulnerability Database, the GitHub Advisory Database, and OSV, then uses AI agents to audit each CVE’s fixing commit and trace it back through Git history to determine whether AI coding tools contributed the vulnerable code.

The findings across the first year are stark. CVEs attributable to AI-generated code climbed from 6 in January 2026 to 15 in February, then to 35 in March. That March figure alone exceeded all of 2025. Researcher Hanqing Zhao, who runs the tracker, notes this is almost certainly an undercount. The attribution methodology requires that the original code contribution be visible in public repositories with traceable authorship. Private repositories, obfuscated history, and the general difficulty of proving a human did not write a given function all push the real number higher. The research team estimates the true ecosystem-wide count is five to ten times what the tracker records.

What AI Code Actually Gets Wrong

The category breakdown from the tracker aligns with findings from other research. Veracode tested over 100 large language models on security-sensitive coding tasks and found that 45% of AI-generated code samples introduce OWASP Top 10 vulnerabilities. The failure modes are consistent: improper input validation, hardcoded credentials, SQL injection, and insecure direct object references appear disproportionately in AI-generated code because the models lack the security intuition that makes experienced developers pause before writing certain patterns.

Secrets exposure is a separate, concrete problem. AI-assisted commits expose credentials, API keys, and tokens at more than twice the rate of human-only commits. The figures are 3.2% versus 1.5%. That rate difference compounds across a large organisation’s output. If your engineering team is shipping 500 pull requests a week and half of them use AI assistance, you are exposing secrets at a rate that human developer behaviour alone would not produce.

The Georgia Tech team published the “Bad Vibes” research note in April 2026, drawing coverage from Infosecurity Magazine and the Georgia Tech Research News Center. The research is ongoing and the tracker is updated monthly.

The Cloud Security Alliance’s Documentation

The Cloud Security Alliance has published three research notes on this topic since early 2026, framing it explicitly as a security debt problem. The first, “Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt,” documented how AI coding tools create credential exposure at scale and argued that most organisations adopting these tools had not updated their SDLC policies to account for the changed risk profile.

The second note focused on the broader vulnerability introduction pattern. The third, “The Vibe Coding Governance Gap,” published June 2, 2026, made the governance argument: most engineering organisations have adopted AI coding tools far ahead of the security policies and review processes that would catch their failure modes. Developers are using Cursor, GitHub Copilot, Claude Code, and similar tools without any organisational policy governing what AI-generated code requires before it merges.

This matters because AI coding tools are moving faster into production pipelines than security teams are moving into the AI coding tool conversation.

A Different Story Than AI Finding Bugs

Worth separating this from the AI vulnerability discovery story. An earlier article on this site covered how AI systems are finding vulnerabilities faster than ever, driving the record CVE volumes that FIRST.org now projects will hit 66,000 for 2026. That is AI as an accelerant for the security research process. The Georgia Tech research is about the other side: AI as an accelerant for vulnerability introduction.

Both can be true simultaneously. AI bug-hunting tools are reducing the window between vulnerability introduction and discovery. AI coding tools are widening the vulnerability introduction rate. The net security effect depends on which side moves faster.

The data so far suggests the introduction rate is outpacing the discovery rate in production codebases. The tracker’s 35-CVE March count is the count that made it into public databases with clear AI attribution. The actual introduction rate in private and proprietary software is invisible.

Practical Implications

Three controls address the specific failure modes Georgia Tech and CSA have documented.

Mandatory secret scanning in CI pipelines. The 2x secret exposure rate in AI-assisted commits is catchable before it reaches a repository. Tools like Gitleaks, TruffleHog, and GitHub’s native secret scanning flag credentials in pull requests before merge. If your CI pipeline does not run secret scanning today, the AI coding tool adoption in your organisation is generating undetected credentials in your codebase right now.

SAST on AI-generated pull requests. Static analysis catches the class of vulnerabilities that AI tools introduce most consistently: input validation gaps, injection flaws, and insecure API usage. Requiring SAST as part of the pull request pipeline for AI-assisted code adds a verification layer that partly compensates for the models’ lack of security intuition.

Dependency version verification. AI coding tools frequently recommend or import outdated library versions. The model’s training data is historical, and the library version that was current when the training data was assembled may have known CVEs by the time the model recommends it. A dependency checker in CI catches this class of issue.

None of these controls are new. The argument for adding them is: AI coding tools changed the risk profile of your development process. The controls your SDLC had before those tools were adopted may not cover the new failure modes.