The Vulnerability Class That Arrived With AI Coding Assistants

The AI Code Quality Problem Is a Security Problem

Multiple published studies (Stanford HAIS, NYU Tandon, Cybersecurity and Infrastructure Security Agency advisories) have found that code generated by LLMs contains security vulnerabilities at meaningful rates. The Stanford 2023 study found that 40% of GitHub Copilot completions in security-sensitive contexts contained vulnerabilities.

This isn't a reason to avoid AI coding assistants. It's a reason to have write-time security scanning that runs on every line of code, regardless of whether a human or an LLM wrote it.

The Patterns AI Code Gets Wrong

Hardcoded Secrets (CWE-798)

LLMs generate example code with hardcoded API keys, passwords, and tokens. When that example code is accepted and committed, the secret is in the repository. AI coding assistants are now a meaningful source of CWE-798 findings in enterprise codebases.

# LLM-generated example. Commonly accepted without modification
API_KEY = "sk-prod-1234567890abcdef"
client = OpenAI(api_key=API_KEY)

Insecure Deserialization (CWE-502)

LLMs trained on older codebases reproduce pickle-based serialization patterns, yaml.load() without Loader argument, and other insecure deserialization patterns. These patterns were common in older Python code and are well-represented in training data.

SQL Construction from String Formatting (CWE-89)

When asked to write database queries, LLMs often produce string-formatted SQL unless explicitly instructed to use parameterized queries. The formatting looks clean in the completion, and developers accept it without recognizing the injection risk.

# Common LLM completion. Injectable
query = f"SELECT * FROM users WHERE username = '{username}'"
cursor.execute(query)

Missing Input Validation at API Boundaries (CWE-20)

LLMs generate complete API handlers that handle the happy path but omit input validation. The generated code is functional and passes tests against valid input, but doesn't validate type, length, format, or encoding.

The Trust Model Problem

AI coding assistants are trusted in a way that copy-pasted Stack Overflow code is not. When a developer pastes code from Stack Overflow, they often read it and modify it. When an LLM completes code inline, the natural tendency is to accept and move on.

This means AI-generated vulnerabilities have a higher probability of reaching production than manually introduced vulnerabilities, because they look authoritative and developers trust the completion.

The Compound Risk: AI + Speed

AI coding assistants increase developer velocity. More code ships per developer per day. Security review processes don't scale at the same rate. The net effect is a growing gap between code being written and code being reviewed. Exactly the gap that write-time scanning closes.

How Deva Addresses AI-Introduced Vulnerabilities

Deva scans every line written, regardless of whether a human or an AI wrote it. The scan runs at write time. As the code is typed or generated. There's no lag between "AI generates insecure code" and "Deva flags it"; the detection is immediate.

The OWASP Top 10 2025 draft's new A10 category (LLM-Assisted Code Vulnerabilities) is covered by Deva's existing CWE detection rules, since the vulnerabilities introduced by LLMs are the same CWEs as always. Just with a new source.