The 45% Problem: Why Nearly Half of AI-Generated Code Is Vulnerable

Here's a number that should stop every developer shipping AI-generated code in their tracks: roughly 45%.

That's the share of AI-generated code samples that recent security research has found to contain an exploitable vulnerability, a missing guardrail, or an insecure pattern. Nearly half. Not obscure edge cases — real, known weaknesses of the kind attackers exploit every day.

If you're building with AI right now — and increasingly, who isn't — that statistic is about your code. So let's talk about why it's so high, what specifically tends to be wrong, and the practical steps that bring the risk back down.

Why nearly half?

The root cause is simple once you see it: AI models are trained to produce code that works, not code that's secure. Those are different targets. A model rewarded for generating functional code will happily reproduce the fastest path to "it runs" — and the fastest path is very often the insecure one.

It gets worse, because of what these models learned from. Their training data is the public corpus of code: tutorials that skip validation "for clarity," forum answers that hardcode a key "just to demonstrate," and real repositories that themselves cut corners. The model faithfully absorbs and reproduces those bad habits. When it writes your database query the insecure way, it's not malfunctioning — it's echoing the most common example it ever saw.

The result is code that looks right, runs right, and is quietly wrong in exactly the ways that get applications breached.

The usual offenders

The 45% isn't spread randomly. AI-generated code fails in a handful of predictable categories:

Injection flaws. The classic. AI frequently fails to separate user input from commands — gluing input straight into SQL queries (SQL injection) or rendering it directly into pages (cross-site scripting). It works in the demo; it's a wide-open door in production.

Hardcoded credentials. To make a "quick-start" example run, generative tools drop API keys, passwords, and tokens straight into the source. That code gets committed and pushed — and anything in your repository or client bundle is effectively public the moment it leaves your machine.

Missing authentication and authorization. Models are decent at "is the user logged in?" and weak at "is this user allowed to do this specific thing?" They routinely skip role-based access checks and forget rate limiting on API endpoints — so endpoints ship that anyone can hammer or that leak data across users.

Hallucinated dependencies — and "slopsquatting." This one is newer and genuinely nasty. AI sometimes suggests importing a package that doesn't exist — it hallucinated the name. Attackers have noticed. They register those hallucinated names on public registries and fill them with malicious code, so that when a developer trustingly installs the suggested package, they pull in malware. The industry has a name for it now: slopsquatting. Your dependency list is an attack surface, and AI can quietly add hostile entries to it.

The mitigation mindset: treat AI output as untrusted input

The single most useful mental shift is this: treat everything an AI writes as untrusted — the same way you'd treat input from a stranger. You wouldn't merge an unknown contributor's pull request without review, and you wouldn't trust raw user input without validation. AI-generated code deserves exactly that skepticism, because it was written to satisfy a prompt, not to pass a security review.

From that mindset, three practices bring the 45% down fast.

1. Keep a human in the loop

Never push AI-written code straight to production. A thorough, human-led review remains essential — someone who understands the security implications reading the code with intent. The problem, of course, is that reviewing AI code for security is hard and slow precisely because you didn't write it and can't easily see what's missing. Which is why review needs a partner:

2. Automate the scanning

This is the highest-leverage step. Two kinds of automated analysis catch the bulk of AI-introduced flaws:

• SAST (Static Application Security Testing) reads your source code and flags insecure patterns — the injection flaws, dangerous calls, hardcoded secrets, and weak defaults.
• SCA (Software Composition Analysis) examines your dependencies for known-vulnerable and suspicious packages — your defence against the hallucinated-dependency problem.

Run these on every change and they catch, automatically and consistently, the things a tired human reviewer misses at 2am.

3. Prompt for security explicitly

Don't just ask for "secure code" — that's too vague to help. Tell the assistant your actual environment: which authentication framework you use, that queries must be parameterised, that this endpoint needs authorization and rate limiting, that inputs must be validated. Specific instructions produce meaningfully safer output. But prompting better reduces the risk; it doesn't eliminate it — which brings us back to verification.

Where safeey-cli fits

This is exactly the gap safeey-cli was built to fill. It's a free, local command-line scanner that combines the two automated defences above in one tool: it does static analysis of your code and checks your dependencies — catching the exact categories that make up the 45%.

It runs where you already work, in seconds, and your code never leaves your machine:

npm install -g safeey-cli
safeey scan ./

  Safeey CLI  ·  scanned 31 file(s) in ./

  src/api/orders.js
    HIGH      Possible SQL injection        :19:14   js/sql-injection
      fix  Use parameterised queries (placeholders + a values array).

  src/config.js
    CRITICAL  Hardcoded credential          :6:22    secret/generic-assignment
      fix  Move it to an environment variable and rotate it.

  package.json
    LOW       Unpinned dependency: utils    (pinned to "*")
      fix  Pin to a specific version and commit a lockfile.

  ────────────────────────────────────────────────
  Risk grade D (61/100)   1 critical · 1 high · 1 low

Every finding names the exact line, explains the risk in plain English, and gives you the fix — which you can hand straight back to your AI assistant to patch. Then re-scan and watch the grade climb from D to A.

And because it returns a non-zero exit code on findings, it becomes an automatic gate in your pipeline — so AI-generated code can't merge with a high-severity issue in it:

- name: Security scan
  run: npx safeey-cli scan . --fail-on high

That turns "automate the scanning" from a good intention into something that actually happens on every push.

The bottom line

The 45% figure isn't an argument against AI coding. AI is an extraordinary accelerator, and it's here to stay. The figure is an argument for one specific discipline: treat AI-generated code as unverified until you've verified it, and make that verification as fast and automatic as the generation itself.

Human review catches the subtle logic. Explicit prompting reduces the input risk. And an automated scanner like safeey-cli catches the injection flaws, hardcoded secrets, and dependency risks that make up the overwhelming majority of the 45% — in seconds, for free, before any of it reaches production.

Your AI can write the code. Just don't let it be the only thing that decides whether it's safe.

npm install -g safeey-cli && safeey scan ./