Will My AI-Generated Code Ship A CVE?

The AI-CVE Supply Rate Is The Load-Bearing Number

BrassCoders treats the AI-generated-code CVE rate as the central evidence for the entire category. The literature converges on a clear answer: yes, at a structural rate. The resources below are the canonical evidence — every entry is something a builder citing AI-code risk to a CTO, an AppSec lead, or a SOC 2 auditor can lean on without further vetting.

📊 Veracode — State of Software Security 2025

Veracode, Feb 2025 · veracode.com

BrassCoders treats this as the canonical long-run baseline for how much of the industry's code carries known-vulnerability classes even without AI in the picture. The report tracks OWASP Top 10 pass rates over five years — 32% of applications passing in 2020, up to 52% by 2025 — and finds flaw-fix speed the widest gap between leading and lagging organizations. This is the pre-AI baseline; pair it with Veracode's separate GenAI Code Security Report (below) for the AI-specific failure rate.

What it's good for: the industry-wide OWASP-pass-rate trend independent of AI-generated code. Where BrassCoders draws from it: background baseline for the AI Blind Spots pillar's AI-vs-baseline framing.

📊 Cloud Security Alliance — AI-Generated Code Vulnerability Surge 2026

Cloud Security Alliance Labs, 2026 · labs.cloudsecurityalliance.org

BrassCoders treats this as the canonical evidence for the AI-CVE growth curve. The source's own trajectory number is a near-sixfold jump within one quarter — 6 AI-attributed CVEs in January 2026, 15 in February, 35 in March — not a year-over-year figure. Builders sizing the urgency of their detection-layer investment should anchor on that two-month acceleration.

What it's good for: demonstrating the curve is accelerating, not flattening. Where BrassCoders draws from it: the central thesis of the Q1 2026 AI-Code CVE Reckoning post.

📊 Veracode — GenAI Code Security Report 2025

Veracode, July 2025 · veracode.com

BrassCoders treats this as the canonical controlled benchmark on AI-generated code security. The study tested 100+ LLMs across 80 programming tasks and found 45% of generated code samples fail security tests — Java at 72% failure, cross-site scripting at 86%. Critically, larger and newer models showed no meaningful improvement over smaller ones. Builders evaluating which AI assistant to trust on security-sensitive code should read this before assuming a more recent model is safer.

What it's good for: controlled LLM-vs-LLM comparison on security failure rates by language and vulnerability class. Where BrassCoders draws from it: the per-model failure-rate argument in the AI Coding Tool Security Risk for Engineering Leaders post; the 45% figure anchors the quarterly AI Code Defect Rates: Q3 2026 data report.

📊 Checkmarx — Future of Application Security 2025

Checkmarx, August 2025 (report updated by Checkmarx since; current figures below) · checkmarx.com

BrassCoders treats this as the canonical evidence for the AI code governance gap. Checkmarx's Future of Application Security survey — 2,350 security and development leaders across 14 countries as the report currently stands — found 93% had experienced a breach from vulnerable code, and 75% admitted to knowingly shipping code they knew carried a vulnerability. Builders citing this should pull the governance-policy percentage directly from the live report rather than a fixed number here, since Checkmarx has updated the underlying dataset since first publication.

What it's good for: sizing the governance gap — organizations shipping AI-generated code without a defined review policy. Where BrassCoders draws from it: the governance-gap argument in the AI Coding Tool Security Risk for Engineering Leaders post.

📄 Amro & Alalfi 2025 — Can AI Spot Security Flaws Before You Commit?

Amena Amro, Manar H. Alalfi, arXiv 2509.13650, Sept 2025 · arxiv.org/abs/2509.13650

BrassCoders treats this as the canonical evidence that LLM-based PR review systematically misses critical vulnerabilities. The paper documents Copilot's code review feature "frequently fails to detect critical vulnerabilities including SQL injection, cross-site scripting (XSS), and insecure deserialization," and finds its feedback concentrates instead on low-severity style and formatting issues. Builders relying on Copilot's PR review as their only review layer should treat this as the reason to add deterministic detection underneath.

What it's good for: ending the "but Copilot reviews PRs for us" objection. Where BrassCoders draws from it: Blind Spot 1 (cross-file taint) in the pillar and the lead argument in the cross-file bugs post.

📄 OWASP Top 10 for LLM Applications

OWASP, 2024-2025 · owasp.org

BrassCoders treats this as the canonical taxonomy for LLM-specific risks (prompt injection, training data poisoning, model denial of service). The list is distinct from the classic OWASP Top 10 for application security; both apply to AI-augmented codebases for different reasons. Builders working on systems that embed LLM calls should cross-reference both.

What it's good for: framing AI-specific risks the application-layer OWASP Top 10 misses. Where BrassCoders draws from it: referenced in policy and compliance content; complements the application-layer OWASP categories BrassCoders detects.

🔧 Bandit

PyCQA · Python · widely-used · github.com/PyCQA/bandit

BrassCoders bundles Bandit as the primary Python security linter inside the OSS core. Builders running Python who want a single-tool starting point for security pattern detection should install Bandit directly; builders who want Bandit plus eleven other scanners with unified output should run BrassCoders. The tool is canonical for its niche and has been maintained by PyCQA for years.

What it's good for: Python-specific security patterns (hardcoded SQL, weak crypto, subprocess shell injection, unsafe deserialization). Where BrassCoders draws from it: direct integration as one of the 12 bundled scanners.

🔧 Semgrep

Semgrep · multi-language · widely-used · semgrep.dev

BrassCoders bundles Semgrep as the multi-language pattern-matching engine in the OSS core. Builders who need cross-language SAST coverage (Python, JavaScript, TypeScript, Go, Ruby, Java, and more) and want to write custom rules in a YAML-based pattern language should learn Semgrep directly. The OSS rules registry is extensive; the commercial product layers ranking and triage on top.

What it's good for: multi-language pattern matching with a custom rule language; AI-pattern detection rules. Where BrassCoders draws from it: the JavaScript/TypeScript and multi-language pattern coverage in BrassCoders runs on Semgrep with curated rule sets.

🔧 detect-secrets

Yelp · multi-language · widely-used · github.com/Yelp/detect-secrets

BrassCoders bundles detect-secrets as the entropy-based secret detector in the OSS core, layered with seven custom format patterns BrassCoders adds on top. Builders who want a single-purpose secret scanner with a baseline file for false-positive management should run detect-secrets directly. The entropy engine catches credential formats the pattern list does not.

What it's good for: entropy + pattern secret scanning, baseline-driven CI integration. Where BrassCoders draws from it: the secret-detection layer; foundation for the Secrets Your AI Might Leak post.

🧪 PyGoat

Independently maintained · Python · benchmark · github.com/adeyosemanputra/pygoat

BrassCoders treats PyGoat as a reference Python codebase for testing static-analysis coverage. The repo — independently maintained, not an official OWASP project, despite the "OWASP-style" naming convention that circulates — is intentionally vulnerable across the OWASP Top 10 categories, organized so builders can step through each vulnerability class. BrassCoders runs its own benchmarks against PyGoat among nine open-source codebases; the scan output is reproducible and tied to a pinned commit.

What it's good for: validating Python SAST tools against a known ground truth. Where BrassCoders draws from it: one of the nine codebases in the BrassCoders benchmarks.

🧪 OWASP NodeGoat

OWASP · Node.js / JavaScript · benchmark · github.com/OWASP/NodeGoat

BrassCoders treats NodeGoat as the reference Node.js codebase for testing JavaScript SAST coverage. The same OWASP-organized intentional-vulnerability shape as PyGoat, in a Node.js stack. Builders shipping Express, Fastify, or NestJS services should use NodeGoat to sanity-check whatever SAST layer they have in place.

What it's good for: validating JavaScript SAST tools against ground truth. Where BrassCoders draws from it: reference codebase in BrassCoders benchmarks; tests the Semgrep-based JavaScript layer.

🧪 Snyk Goof

Snyk · Node.js · benchmark · github.com/snyk-labs/nodejs-goof

BrassCoders treats Goof as a secondary Node.js benchmark with a different vulnerability distribution from NodeGoat. The repo is maintained by Snyk Labs and tracks newer vulnerability classes (dependency confusion, prototype pollution, recent-CVE patterns). Builders comparing JavaScript SAST tools should run both NodeGoat and Goof.

What it's good for: testing newer JavaScript vulnerability classes; dependency-related issues. Where BrassCoders draws from it: reference codebase in BrassCoders benchmarks.