In March 2025, Y Combinator's head of product Jared Friedman told a room of founders that roughly a quarter of the accelerator's Winter 2025 batch had codebases that were 95% AI-generated. That statistic reframes the question security teams have been circling since GitHub Copilot's technical preview in June 2021: not whether AI writes code, but whether the code it writes can be trusted to ship. The answer, based on peer-reviewed research and vendor testing published between 2021 and 2025, is uneven. Large language models write functional code fast, but they also reproduce the insecure patterns buried in their training data, invent dependencies that don't exist, and skip the input validation a careful engineer adds by habit. This post walks through what the data actually shows about AI-generated code security, which vulnerability classes recur most often, and how to audit AI output before it reaches a production branch.
What is a secure code, and how do you analyze it?
"Secure code" is source code written to resist the specific ways an attacker will try to abuse it — validating and sanitizing every untrusted input, using parameterized queries instead of string-concatenated ones, avoiding hardcoded secrets, and choosing current cryptographic primitives instead of deprecated ones. Secure code analysis is the process of checking whether code actually meets that bar, whether through manual review, static analysis tooling, or the automated checks discussed below that are built specifically to catch the failure patterns large language models reproduce. The research that follows matters because AI-generated code frequently looks correct at a glance while failing exactly this kind of analysis.
Is AI-generated code less secure than human-written code?
Yes, on average, though the gap is narrower and more task-dependent than headlines suggest. The foundational study here is Pearce et al.'s "Asleep at the Keyboard?" (IEEE S&P, 2021), which ran GitHub Copilot against 89 security-relevant scenarios covering MITRE's top CWE list and found that roughly 40% of the 1,689 resulting programs contained an exploitable vulnerability. Four years and several model generations later, Veracode's 2025 GenAI Code Security Report tested over 100 LLMs against 80 CWE categories and found that 45% of generated code samples failed security tests when a secure implementation pattern was available. Java fared worst, failing at over 70%. The pattern is consistent across both studies: models default to the most statistically common code pattern in their training corpus, not the most secure one, and the "most common" pattern in public repositories is frequently outdated or insecure.
What vulnerability classes show up most often in AI-generated code?
Injection flaws, hardcoded credentials, and missing input sanitization dominate, with cross-site scripting and log-injection failures exceeding 85% in Veracode's 2025 testing across the languages sampled. SQL and command injection (CWE-89, CWE-78) also recur heavily because models tend to generate string-concatenated queries unless the prompt explicitly asks for parameterization. Hardcoded secrets (CWE-798) show up when a model completes a config block or connection string with a plausible-looking placeholder API key that a developer forgets to swap out before commit. Weak or outdated cryptographic choices (CWE-327) appear when a model reaches for MD5 or a fixed IV because those are the most frequent examples in older training data, not because they're current best practice. None of these require a sophisticated attacker to exploit — they're the same OWASP Top 10 categories security teams have fought for over a decade, just reintroduced at the speed of autocomplete.
Can AI coding assistants invent dependencies that don't exist?
Yes — this is called package hallucination, and it has already been weaponized under the name "slopsquatting," a term Python Software Foundation developer Seth Larson coined in April 2025. A USENIX Security 2024 study, "We Have a Package for You!", tested 16 code-generating LLMs across 576,000 code samples and found that commercial models hallucinated non-existent package names in about 5.2% of generated code, while open-source models hallucinated at nearly 21.7%. The risk isn't theoretical: because the same hallucinated package name tends to recur across repeated prompts to the same model, attackers can pre-register that exact name on npm or PyPI, load it with malware, and wait for the next developer whose AI assistant suggests import or require for a library that sounds plausible but was never real. A dependency introduced this way won't show up in a code review focused on logic — it looks like an ordinary import statement until someone checks whether the package actually exists.
Do code review tools catch these flaws before they reach production?
Not reliably, because most linters and traditional SAST tools were tuned to catch syntax and style problems, not the specific failure modes LLMs produce at volume. GitHub's own 2024 data showed Copilot-assisted suggestions account for a growing share of accepted code in active repositories, which means the volume of AI-authored diffs hitting review queues has outpaced the rate at which most teams updated their review checklists. Static analysis tools that flag every string concatenation near a database call generate enough false positives that reviewers start ignoring the queue — a well-documented "alert fatigue" problem that predates AI coding tools but gets worse as generation volume rises. The missing piece in most pipelines is exploitability context: knowing whether a flagged function is actually reachable from an internet-facing endpoint, versus dead code that will never execute, is what separates a signal a reviewer will act on from one they'll dismiss. That reachability step is what turns generic secure code analysis into something a reviewer can actually act on under time pressure.
How much AI-generated code is already shipping today?
A large and fast-growing share, based on the vendor data available in 2025. Beyond the YC statistic above, GitHub has reported that Copilot users accept a meaningful fraction of inline suggestions without edits, and enterprises with Copilot Business or Enterprise seats report AI-assisted code making up a growing percentage of new commits in actively developed repositories. Snyk's 2023 AI code security survey of over 500 developers found that 56% of respondents were bypassing organizational security checks on AI-suggested code specifically because it "felt too slow to review." That combination — rising generation volume plus a documented tendency to skip review under time pressure — is the actual supply chain risk. It's not that AI writes worse code than a junior developer would on a bad day; it's that AI writes at a volume and speed that outpaces the manual review capacity most security teams built their processes around in 2015–2020.
How Safeguard Helps
Answering what is a secure code in practice, for any given pull request, requires more than a style checklist — Safeguard treats AI-generated code the same way it treats any untrusted third-party contribution: verify before it merges, not after it ships. Griffin AI reviews AI-authored pull requests for the exact patterns covered above — injection flaws, hardcoded secrets, hallucinated or newly-published dependencies — and cross-references findings against Safeguard's reachability analysis engine to tell you whether a flagged function is actually callable from an exposed entry point, cutting through the false-positive noise that causes teams to ignore SAST output. Every AI-suggested dependency is checked against Safeguard's SBOM generation and ingest pipeline before it lands in a manifest, so a hallucinated or slopsquatted package name gets caught at the PR stage instead of at runtime. Where a fix pattern is well-understood, such as swapping string concatenation for parameterized queries, Safeguard opens an auto-fix PR directly, so the volume advantage AI gives developers doesn't come at the cost of a growing, unreviewed vulnerability backlog.