AI coding assistants have become part of everyday development, and for many teams the security question has moved from “is this allowed?” to “how do we review it?” This guide pulls together public evidence on how often AI-generated code is insecure, maps the risks to the OWASP Top 10 for LLM Applications, and ends with a practical review checklist grounded in NIST’s secure development guidance.
At a Glance
| Question | Short answer |
| How often is AI-written code insecure? | In Veracode’s 2025 test of 100+ models on 80 tasks, 45% of samples introduced an OWASP Top 10 vulnerability |
| Worst weaknesses in that test | Cross-site scripting (failed 86% of the time) and log injection (failed 88%) |
| Riskiest language in that test | Java, with a failure rate above 70% |
| Do newer or bigger models fix it? | Not according to Veracode: security did not improve with newer or larger models |
| Most relevant OWASP LLM risks | LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM03 Supply Chain, LLM01 Prompt Injection |
| Process framework to anchor on | NIST SSDF (SP 800-218) plus its AI profile, SP 800-218A |
Short Verdict
Treat AI-generated code exactly like code from a fast, confident junior developer who has never seen your threat model: useful, often correct, and frequently insecure in predictable ways. The evidence says model upgrades will not solve this on their own, so the fix is process. Keep a human reviewer accountable for every merge, run static analysis and dependency checks on every pull request, and limit what coding agents are allowed to do without approval.
What the Evidence Says
One of the most widely reported recent datasets is Veracode’s 2025 GenAI Code Security Report, released July 30, 2025. Veracode gave more than 100 large language models 80 curated code-completion tasks, each tied to a known weakness in MITRE’s CWE list, and checked whether the output was secure. In 45% of cases the model introduced a vulnerability from the OWASP Top 10; put another way, when a secure and an insecure approach were both available, the models chose the insecure one 45% of the time. Java fared worst, failing more than 70% of the time, while Python, C#, and JavaScript ranged from 38% to 45%. Two weakness classes stood out: models failed to defend against cross-site scripting (CWE-80) in 86% of relevant cases and against log injection (CWE-117) in 88%. Veracode also reported that newer models wrote more syntactically correct code without becoming more secure, and that larger models did not perform significantly better than smaller ones.
Two caveats keep this in proportion. These are vendor-run benchmark tasks, not a measurement of production codebases, and Veracode sells application security testing. Even so, the specific failures it reports, such as unescaped output and unsanitized log input, are exactly the kinds of flaws a review process can be designed to catch.
Mapping the Risks to the OWASP Top 10 for LLM Applications
OWASP’s 2025 list was written for applications built on language models rather than for coding assistants specifically, but several entries translate directly to AI-assisted development. The mapping below is our interpretation of how each risk shows up in a coding workflow.
| OWASP risk (2025) | How it shows up in AI-assisted coding |
|---|---|
| LLM05 Improper Output Handling | Generated code is merged or executed without validation, carrying injection flaws straight into the codebase |
| LLM06 Excessive Agency | Coding agents with shell, file-write, or push permissions can make changes no one reviewed |
| LLM03 Supply Chain | Suggested packages and dependencies may be outdated, malicious, or not exist at all |
| LLM01 Prompt Injection | Untrusted text in issues, comments, or repository files can steer an agent toward harmful actions |
| LLM02 Sensitive Information Disclosure | Secrets or proprietary code pasted into prompts, or credentials hard-coded in suggestions |
| LLM09 Misinformation | Plausible but wrong API usage or security advice accepted without verification |
The Process Anchor: NIST SSDF and SP 800-218A
NIST’s Secure Software Development Framework (SP 800-218) is the most widely referenced baseline for secure development practices. In July 2024 NIST published SP 800-218A, “Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile,” which adds AI-specific practices and is meant to be used alongside the SSDF, not instead of it. Its stated audience is producers of AI models, producers of AI systems that use those models, and acquirers of those systems. For a team that only uses coding assistants, the practical takeaway is simpler: AI-written code goes through the same SSDF controls as any other code, with no exemptions for where it came from.
The Review Checklist
- A named human owns every merge. The person who accepts AI-generated code is accountable for it exactly as if they had typed it.
- Static analysis on every pull request. Run SAST with rules for the weaknesses AI code gets wrong most often, especially output encoding (XSS) and log injection.
- Verify every new dependency. Confirm a suggested package exists, is the one you meant, is maintained, and passes your software composition analysis before it lands in a lockfile.
- Scan for secrets. Block commits that contain keys or tokens, and keep secrets out of prompts.
- Limit agent permissions. Give coding agents the least privilege they need, require approval before they push, merge, or run destructive commands, and keep logs of what they did.
- Treat repository text as untrusted input to agents. Issue bodies, comments, and files from outside contributors can contain instructions; do not let an agent act on them unreviewed.
- Require tests for generated logic. Ask for tests alongside code, and review the tests as critically as the code.
- Track provenance. Label or note AI-assisted changes so you can find them quickly if a pattern of flaws turns up later.
Pros and Cons of Leaning on AI for Code
- Pros: faster first drafts, quick boilerplate and tests, and agents that can take on routine fixes, which frees reviewers to focus on design and risk.
- Cons: predictable security gaps that benchmark data says are not shrinking with newer models, new supply-chain and prompt-injection exposure through agents, and a risk that reviewers rubber-stamp code that looks clean.
Bottom Line
AI code generation is a productivity tool, not a security control. The best available evidence suggests close to half of AI-written samples carry a well-known weakness, and that waiting for better models is not a plan. Put AI-generated code through the same SSDF-style gates as everything else, add dependency verification and agent permission limits on top, and keep a human accountable for every merge. For a look at one of the most widely used assistants, see our GitHub Copilot review.
Frequently Asked Questions
- Is AI-generated code less secure than human code? The benchmark data here measures AI output against secure-coding tasks, not against human developers, so it shows AI code is often insecure but does not directly compare it with people.
- Which vulnerabilities do AI assistants introduce most? In Veracode’s 2025 test, cross-site scripting and log injection had the highest failure rates, at 86% and 88%.
- Will a newer model fix this? Veracode found security did not improve with newer or larger models, so plan on review and scanning regardless of model.
- What framework should we follow? NIST’s SSDF (SP 800-218), with the SP 800-218A profile for organizations that build or acquire AI systems.
Sources
- Veracode — 2025 GenAI Code Security Report announcement
- OWASP — Top 10 for LLM Applications (2025)
- NIST — SP 800-218A, SSDF Community Profile for Generative AI
Discover more from Software Online Review
Subscribe to get the latest posts sent to your email.
