TL;DR
AI-generated code is introducing security vulnerabilities at alarming scale—roughly 45% of AI-generated code fails OWASP Top 10 security tests, while supply chain attacks have increased 93% year-over-year. Three converging threats create a perfect storm: vulnerable code flowing through supply chains, poisoned AI models generating insecure patterns, and compromised training data embedding backdoors. Traditional security scanners miss ~80% of these LLM-specific issues. Organizations must shift from trusting AI outputs to continuous validation with human-in-the-loop review gates.
OWASP top 10 lists
The OWASP Top 10 provides foundational security awareness for web applications. Understanding the list is essential when evaluating AI-generated code security, as vulnerabilities can originate from traditional coding errors, compromised training data, or the intersection of both.
Why is it important?
- Industry Standard: Used by security professionals, compliance frameworks, and regulatory bodies worldwide
- Practical Guidance: Provides mitigation strategies alongside each vulnerability
- Developer Education: Helps development teams prioritize security fixes
- Risk Communication: Creates a common vocabulary for discussing security issues
- Testing Benchmark: Security scanners and audit tools map findings to OWASP Top 10 categories
Limitations
- Not exhaustive: Only covers top 10, not all possible vulnerabilities
- Static snapshots: Updates lag behind emerging threats
- Context-dependent: Risk levels vary by application architecture
- Complementary tools needed: Should be used with SAST/DAST scanners, not instead of them
OWASP Top 10 2025
- A01:2025 - Broken Access Control
- A02:2025 - Security Misconfiguration
- A03:2025 - Software Supply Chain Failures
- A04:2025 - Cryptographic Failures
- A05:2025 - Injection
- A06:2025 - Insecure Design
- A07:2025 - Authentication Failures
- A08:2025 - Software or Data Integrity Failures
- A09:2025 - Security Logging and Alerting Failures
- A10:2025 - Mishandling of Exceptional Conditions
OWASP Top 10 bugs in ai-generated Code
Security research indicates that roughly 45% of AI-generated code introduces OWASP Top 10 weaknesses directly into repositories. A subset analysis of Y Combinator Winter 2025 startupsfound 25% of companies had codebases that were 95% AI-generated, with scans of 5,600 applications revealing 2,000+ vulnerabilities and 400+ exposed secrets.
Most common bugs
Developers who rely on AI coding assistants and agents, inherit both productivity benefits as well as security debt baked into the training data. The following vulnerability categories are examples of bugs in ai generated code. Deployed at scale, they are particular dangerous.
- Injections
- Broken Access Control
- Security Misconfiguration
- Cryptographic Failures
- Security Logging and Monitoring Failures
Injection
Injection attacks thrive wherever data is mistakenly treated as code. By enforcing strict separation of code and data through parameterization, rigorous input validation, contextual output encoding, and least‑privilege architecture, you can eliminate the vast majority of injection vectors and keep your application resilient against one of the oldest yet most dangerous classes of vulnerabilities.

“we observed that 7.1 percent of the Python answers contain at least one insecure coding practice, e.g., code injection” (A Study of C/C++ Code Weaknesses on Stack Overflow; Haoxiang Zhang , Shaowei Wang , Heng Li , Tse-Hsun Chen , and Ahmed E. Hassan, Fellow, IEEE)
Broken access control
Access control is the set of rules that decides who can do what within a system—view data, invoke actions, modify settings, etc.
When these rules are incorrectly implemented, missing, or bypassable, we talk about Broken Access Control (BAC). In practice, an attacker can:
- Escalate privileges – move from a low‑privilege user to an admin or system account.
- Access unauthorized resources – read, modify, or delete data belonging to other users.
- Perform forbidden operations – trigger actions (e.g., fund transfers, configuration changes) that should be restricted.
BAC often leads to severe data breaches with relatively low effort.
Security misconfiguration
Security misconfiguration is a systemic issue rather than a single bug. By establishing hardened baselines, automating configuration as code, continuously scanning for drift, and assigning clear ownership, you can close the majority of these gaps before attackers ever get a chance to exploit them.

Cryptographic failures
Cryptographic failures arise not from weak mathematics but from incorrect usage, poor key handling, and missing integrity checks. By standardizing on modern, vetted primitives, centralizing key management, and embedding rigorous testing and review processes, you can ensure that encryption truly protects the data it’s meant to safeguard.

Security logging and monitoring failures
Logging failures strip away the visibility that lets defenders detect, investigate, and learn from attacks. By establishing a clear logging policy, centralizing immutable collection, protecting transport and storage, and continuously monitoring the health of the pipeline, you turn logs from an afterthought into a reliable cornerstone of your security program.

While OWASP vulnerabilities exist independently, AI coding assistants accelerate their spread. But there’s another layer: the models themselves may be compromised.
AI model poisoning
What It Is: Attackers manipulate training data to alter model outputs during inference, causing the AI to behave according to attacker intentions.
Attack Vectors:
- Label Flipping: Change correct labels to wrong ones (availability attack)
- Clean-Label Attacks: Poisoned data appears correctly labeled, very hard to detect
- Backdoor Attacks: Model behaves normally except when triggered by specific inputs
- Targeted Poisoning: Skew output only for particular queries while leaving rest intact
Impact Scale:
- As little as 0.1% poisoned training data (50 out of 50,000 images) can corrupt a model
- Affects pre-training, fine-tuning, and embedding stages
- Recovery is expensive (retraining entire model required)
- Machine unlearning research exists but isn’t mature yet
Data and Model Poisoning is officially ranked as a critical LLM application risk, covering vulnerabilities introduced through compromised pre-training data, fine-tuning datasets, and embedding vectors.
Intersection between model poisoning and OWASP Top 10

Passive inheritance: Error-prone human input used for training
Large language models are trained on massive chunks of publicly available code from GitHub and other open-source repositories. The critical issue is that this training data already contains significant OWASP Top 10 vulnerabilities, and models learn these insecure patterns as normal coding practices. As stated in the injection section 7.1% of the python code included vulnerabilities such as injections. This introduces a widespread security severity at high volume.
The traditional OWASP Top 10 (for web apps) was designed to help developers write secure code. Now:
- AI tools are becoming primary code authors at scale
- These tools systematically reproduce OWASP vulnerabilities at 40–70% rates depending on category
- Legacy AppSec scanners miss ~80% of these LLM-specific issues (DryRun Security)
Research findings on vulnerability rates
| Source | Finding | Year |
|---|---|---|
| Veracode GenAI Code Security Report | 45% of AI-generated code fails OWASP Top 10 security tests | 2025 |
| Cloud Security Alliance | 62% of AI-generated code contains design flaws or known vulnerabilities | 2025 |
| Pearce et al. | 40% of GitHub Copilot output contained vulnerabilities | 2022 |
| DryRun Security | 87% of AI agent pull requests introduced at least one vulnerability | 2026 |
Active poisoning
Active poisoning transforms model training from a passive risk (bad patterns get copied) into an active attack surface where adversaries can:
- Insert covert backdoors that evade detection
- Control exactly when/how exploitation occurs
- Potentially bypass all traditional OWASP-focused defenses
- Create vulnerabilities that survive safety training and fine-tuning
This is why OWASP elevated LLM04: Data and Model Poisoning to #4 on their LLM Top 10 list—it’s not just about code quality anymore; it’s about ensuring the model itself hasn’t been weaponized.
Question to answer: is your model used for coding trustworthy? - custom fine tuned models might not.
Supply chain attacks
Supply chain attacks are cybersecurity breaches that target third-party vendors, software providers, or service partners within a larger organization’s ecosystem. Instead of attacking a primary target directly, adversaries compromise weaker links in the supply chain to gain access to multiple downstream victims.
How they work
Attackers infiltrate trusted suppliers—often smaller organizations with weaker security—and use that foothold to inject malware into legitimate software updates, tamper with hardware components, or steal credentials. When compromised components reach end users, the attack spreads automatically through established trust relationships.
Key dangers in modern IT ecosystems
Scale and Velocity: A single compromised update can affect thousands or millions of organizations simultaneously. The SolarWinds incident demonstrated this, potentially impacting 18,000+ customers through one trojanized software update.
Trust Exploitation: Organizations inherently trust signed, verified software from known vendors. Attackers exploit this trust because security teams rarely scrutinize vendor deliverables with the same intensity as external downloads.
Visibility Gaps: Most enterprises lack complete visibility into their full supply chain, making it difficult to assess which third parties pose the highest risk or track software dependencies beyond tier-one vendors.
Persistence and Lateral Movement: Once embedded in a supply chain component, attackers gain persistent access across all downstream systems, enabling lateral movement deep into networks before detection.
Recovery Complexity: Remediation becomes exponentially harder because every affected organization must respond individually, and the compromised component may remain in use across the ecosystem for extended periods.
Examples
- SolarWinds (2020): Compromised Orion platform updates reached government agencies and Fortune 500 companies
- XZ Utils (March 2024): Sophisticated nation-state attack on widely-used compression library; “benevolent stranger” social engineering playbook
- Log4j (2021): Vulnerability in widely-used logging library created massive blast radius across countless applications
- CodeCov (2021): Breach of CI/CD pipeline tool impacted customer environments globally
- MOVEit (2023): Vulnerability in file transfer software affected hundreds of organizations
Statistics:
- 93% year-over-year increase in supply chain attacks (297 claimed in 2025)
- 512,847+ malicious packages identified across open-source registries
- Global cost projected to reach $138 billion by 2031
- OWASP Top 10 2025 ranks Software Supply Chain Failures as #3 risk
Converging risks creating a “Perfect Storm”
AI Code → Supply Chain:
- AI-generated vulnerabilities enter repositories at unprecedented scale
- Unverified code becomes dependency for downstream projects
- High-speed flaw duplication across services
Poisoned Models → AI Code Quality:
- Coding assistants trained on compromised data generate vulnerable code
- Training data integrity directly determines output security
- Backdoored models insert malicious patterns in generated code
Supply Chain → Model Poisoning:
- Training datasets sourced from untrusted repositories
- Compromised open-source ML libraries contain poisoned weights
- “Next big supply chain attack target” (MITRE ATLAS)
Prompt Injection → Supply Chain:
- Hidden injections in PR descriptions, issues, documentation
- Agentic AI tools execute commands based on poisoned context
- CVE-2025-53773: Remote code execution via GitHub Copilot
Compounding Risk Factors:
- Developer trust in AI reduces manual code review
- Speed of “vibe coding” prioritizes function over security
- AI models trained on public repos containing both secure and insecure patterns
- Attack surface multiplies with agentic systems having system-wide access
Mitigation techniques and strategies
Technical Controls:
- Static code analysis for AI-generated code (SonarQube, CodeQL)
- Chain of custody controls for training data
- Continuous validation of dependencies (SBOM/AIBOM)
- Rate limiting and resource controls (addressing LLM10: Unbounded Consumption)
- Human-in-the-loop security review gates
Organizational Practices:
- Secure SDLC integration with AI-specific checkpoints
- Zero-trust approach to AI outputs (don’t assume accuracy)
- Audit trails for training data sources
- Regular model integrity verification
- Incident response plans for poisoning detection
Industry Recommendations:
- OWASP GenAI Security Project guidance
- MITRE ATLAS framework for threat modeling
- AI Bill of Materials initiatives
- Shift from implicit trust to continuous validation
Key takeaways
1. AI is scaling traditional vulnerabilities:
AI coding assistants are reproducing OWASP Top 10 weaknesses at 40-70% rates depending on category. Studies show 45% of AI-generated code fails OWASP Top 10 security tests (Veracode, 2025), and 87% of AI agent pull requests introduced at least one vulnerability (DryRun Security, 2026). This isn’t a marginal problem—it’s systematic vulnerability injection at unprecedented velocity.
2. The three-way convergence creates unique risk:
Three threats compound when they intersect:
- AI Code → Supply Chain: Unverified vulnerable code becomes dependencies for downstream projects
- Poisoned Models → AI Quality: Training data integrity determines whether generated code is secure
- Supply Chain → Model Poisoning: Compromised ML libraries and training datasets introduce backdoors that survive safety fine-tuning
3. Passive inheritance is already widespread:
LLMs trained on public code repositories absorb insecure patterns as normal practice. Research shows 7.1% of Python answers from coding assistants contain at least one insecure coding practice like code injection. This creates legacy security debt baked directly into development workflows before deployment.
4. Active poisoning is harder to detect than passive inheritance:
As little as 0.1% poisoned training data can corrupt a model. Clean-label attacks appear correctly labeled but embed backdoors that trigger on specific inputs. Recovery requires complete retraining—machine unlearning research exists but isn’t production-ready.
5. Legacy security tools don’t cover the gap:
Traditional Application Security scanners miss approximately 80% of LLM-specific security issues. Organizations need:
- Static code analysis specifically for AI-generated code
- SBOM/AIBOM dependency validation
- Human-in-the-loop security review gates
- Training data chain of custody controls
6. Developer behavior compounds the risk:
Speed-focused “vibe coding” prioritizes functionality over security. Trust in AI reduces manual review, while agentic systems with system-wide access multiply attack surfaces. The combination creates vulnerabilities that persist through deployment and scale through automated reproduction.