Security and Quality in LLM-Generated Code: A Multi-Language, Multi-Model Analysis

This paper evaluates the security and quality of code generated by Large Language Models across multiple programming languages using a 200-task dataset, revealing that while LLMs can automate coding, they often fail to adopt modern security features and rely on outdated practices, particularly in languages like C++ and Java 17.

The Gist

Imagine you've hired five different super-intelligent apprentices (the AI models) to build you a set of 200 different tools. Some tools need to be simple hammers (Python), some need to be complex Swiss Army knives (Java), and others need to be delicate, high-precision surgical scalpels (C and C++).

This paper is the report card the authors wrote after watching these apprentices build those tools. They didn't just check if the tools worked; they checked if the tools were safe, if they were built with good craftsmanship, and if the apprentices knew how to use the latest safety gear.

Here is the breakdown of their findings, translated into everyday language:

1. The Setup: The "Test Kitchen"

The researchers created a massive "test kitchen." They gave the same 200 cooking recipes (programming tasks) to five different AI chefs (GPT-4o, Claude-3.5, Gemini-1.5, Llama-3, and Codestral).

• The Ingredients: They asked the chefs to cook in four different languages: Python (easy, flexible), Java (structured, strict), C++, and C (old-school, dangerous if you drop a knife).
• The Goal: They wanted to see who could cook a meal that was:
  1. Edible: Did it actually work? (Compilation & Correctness)
  2. Safe: Was there poison in it? (Security vulnerabilities)
  3. Well-made: Was it easy to clean up later? (Code quality)

2. The Results: Who Cooked What?

The "Easy Mode" Languages (Python & Java)

• Python was the easiest for the AI. It's like a language where you can just say "add salt" without measuring cups. The AI chefs rarely messed up the syntax here. Almost all the code they wrote in Python compiled and ran perfectly.
• Java was a bit stricter, like a recipe that requires exact measurements. The AI did well here, but sometimes they forgot to bring the right "spices" (import statements) to the kitchen, causing the dish to fail. However, Claude-3.5 and GPT-4o were the best chefs for Java, remembering to bring the right ingredients.

The "Hard Mode" Languages (C++ & C)

• C++ and C are like building a house with a hammer and a chisel. If you hit the wrong spot, the whole thing collapses.
• The AI struggled significantly here. They often forgot to bring the tools they needed (missing "include" files), used the wrong type of hammer (type errors), or tried to use a 1990s blueprint when a 2024 one was required.
• The Verdict: The AI generated code that frequently wouldn't even start (compile errors). When it did start, it was often full of holes (security bugs) because the AI didn't understand the strict rules of memory management in these languages.

3. The Safety Inspection: Where did the AI cut corners?

The researchers acted like health inspectors, looking for "poison" in the code. They found some scary patterns:

• The "Hard-Coded Password" Problem: The AI often wrote code where the password was written directly in the text, like leaving your house key under the doormat. This happened in almost every language.
• The "Old-School Crypto" Mistake: When asked to lock a digital safe (encryption), the AI often used an old, broken lock (RSA without OAEP) instead of a modern, unbreakable one. It's like using a padlock from the 1980s to protect a bank vault.
• The "Memory Leak" (C/C++ only): In C and C++, the AI often forgot to clean up after itself, leaving "trash" (memory) lying around that could cause the system to crash later. This is like a chef who cooks a meal but leaves the stove on and the knives on the floor.

The Language Difference:

• Python/Java: The main dangers were "bad locks" (encryption issues) and "leaving keys under the mat" (hard-coded passwords).
• C/C++: The main dangers were "structural failures" (buffer overflows, memory leaks) that could let a hacker break into the house entirely.

4. The "Cleanliness" Check

Even if the code worked, was it messy?

• Intentionality: Sometimes the AI wrote code that was so confusing, even a human couldn't guess what it was trying to do. It was like a chef who chopped vegetables in a way that made them look like abstract art—technically edible, but hard to understand.
• Adaptability: If you wanted to change the recipe later, some AI code was so rigid it would break. Codestral tended to write cleaner, simpler code, while Claude-3.5 wrote very long, complex code that was harder to maintain.

5. The Big Takeaway

The paper concludes that AI is a great assistant, but it's not a replacement for a human expert yet.

• It loves Python: If you ask for Python, it's usually safe and works.
• It struggles with the "Hard Stuff": If you ask for C or C++, it often forgets the safety rules, leading to code that is either broken or insecure.
• It uses old tricks: The AI often relies on outdated security practices it learned from old training data, ignoring modern safety features (like those in Java 17).

The Final Metaphor:
Think of these AI models as very talented but inexperienced interns.

• If you ask them to make a sandwich (Python), they do a great job.
• If you ask them to perform heart surgery (C/C++), they might get the anatomy right, but they often forget to sterilize the tools or use the wrong sutures.
• The lesson: You can use them to speed up your work, but you must have a senior surgeon (a human developer) double-check their work, especially for security and safety. You cannot just let them operate alone.

Technical Summary

Here is a detailed technical summary of the paper "Security and Quality in LLM-Generated Code: A Multi-Language, Multi-Model Analysis."

1. Problem Statement

While Large Language Models (LLMs) are increasingly adopted to accelerate software development, the security and quality of the code they generate remain underexplored. Previous studies have often been limited to single programming languages, single models, or functional correctness without deep security analysis. There is a critical lack of understanding regarding:

• How different programming languages (static vs. dynamic, high-level vs. low-level) influence the security and correctness of LLM-generated code.
• How different LLM families compare in generating secure, compilable, and semantically correct code across diverse domains.
• The specific types of vulnerabilities (e.g., memory safety, cryptographic misuse) that persist across models and languages.

2. Methodology

The authors conducted a large-scale measurement study involving 200 manually curated programming tasks and 5 widely used LLM families across 4 programming languages.

Experimental Setup

• LLMs Evaluated: GPT-4o, Claude-3.5, Gemini-1.5, Llama-3, and Codestral.
• Languages: Python, Java, C++, and C.
• Dataset: 200 tasks grouped into 7 functional categories (Secure Coding, Data Structures/Algorithms, Parsing, Networking, Math/Logic, Systems/Utilities, Concurrency). Tasks were sourced from platforms like LeetCode and vulnerability databases (CWEs), adapted to be language-neutral.
• Generation: 4,000 code files were generated (200 tasks × 4 languages × 5 models) using standardized prompts without prompt engineering to simulate real-world usage.
• Evaluation Pipeline:
  1. Syntactic Validity: Compilation checks for Java, C++, and C; syntax checks for Python.
  2. Semantic Correctness: 4,000 custom unit tests (10 per task) were created to verify logic. Due to varying function signatures, tests were adapted per sample while maintaining identical input/output logic.
  3. Static Analysis: Automated scanning using SonarQube (for quality, maintainability, reliability) and CodeQL (for security vulnerabilities).
  4. Manual Review: A stratified 20% sample of findings was manually reviewed by software engineers to validate false positives and assess "Clean Code" attributes (consistency, intentionality, adaptability, responsibility).

Metrics

• Compilation Success Rate: Percentage of code compiling without errors.
• Semantic Correctness: Percentage of unit tests passed.
• Complexity: Lines of Code (LoC), Cyclomatic Complexity (CyC), and Cognitive Complexity (CoC).
• Security: Vulnerability counts mapped to Common Weakness Enumerations (CWEs), security hotspots, and specific flaw types (e.g., hard-coded secrets, buffer overflows).

3. Key Contributions

1. New Multi-Domain Dataset: Introduction of a manually vetted dataset of 200 tasks spanning 7 categories, designed specifically to evaluate LLMs across multiple languages and security dimensions.
2. Comprehensive Comparative Analysis: A unified evaluation framework comparing 5 LLMs across 4 languages, revealing cross-language and cross-model performance gaps often missed in single-language studies.
3. Deep Security & Quality Correlation: Quantification of how code quality (maintainability, complexity) correlates with security vulnerabilities, identifying that low-quality code often harbors higher security risks.
4. Identification of Language-Specific Failure Modes: Detailed mapping of how specific languages (e.g., C/C++ vs. Python/Java) expose different classes of vulnerabilities in AI-generated code.

4. Key Results

A. Compilation and Semantic Correctness

• Language Effects: Python and Java demonstrated significantly higher compilation success and semantic correctness rates compared to C and C++.
  • Python: Achieved near-perfect compilation (up to 100%) and high semantic correctness (up to 92.1%). Its dynamic nature and simpler syntax reduce errors.
  • Java: High performance (88–95% compilation), though sensitive to missing imports and package dependencies.
  • C/C++: Suffered the lowest success rates (72–89% for C++, 73–96% for C). Common failures included missing #include headers, type mismatches, and incorrect API usage (e.g., STL in C++).
• Model Performance:
  • Claude-3.5 and GPT-4o generally outperformed others, particularly in Java and C++.
  • Llama-3 and Gemini-1.5 showed lower success rates in complex languages (C/C++), often struggling with strict type systems and memory management.

B. Security Vulnerabilities

• Language-Specific Risks:
  • C/C++: Dominated by memory safety issues (Buffer Overflows, CWE-120, CWE-787) and cryptographic misuses (CWE-326, CWE-327).
  • Java/Python: More prone to hard-coded secrets (CWE-259), improper certificate validation (CWE-295), and XML External Entity (XXE) attacks (CWE-611).
• Cryptographic Misuse: A pervasive issue across all models and languages was the use of RSA without OAEP padding (CWE-780), indicating LLMs often default to insecure cryptographic implementations despite modern best practices.
• Model Variance: Gemini-1.5 exhibited the highest overall vulnerability count, while Llama-3 had the fewest security hotspots in Java but struggled significantly with C/C++ compilation.

C. Code Quality and Complexity

• Complexity: Claude-3.5 consistently generated the most verbose code (highest LoC and Cognitive Complexity), potentially reducing maintainability. Codestral and GPT-4o tended to produce simpler, more maintainable code.
• Clean Code:
  • Intentionality: A major weakness across all models; code often lacked clear purpose or contained unnecessary complexity.
  • Adaptability: C code showed the lowest adaptability scores, reflecting the difficulty of generating modular, change-friendly low-level code.
• Outdated Practices: Models frequently failed to utilize modern language features (e.g., Java 17 security features), reverting to legacy or insecure methods.

5. Significance and Implications

• Language Selection Matters: The choice of programming language significantly impacts the reliability and security of AI-generated code. High-level languages (Python/Java) are currently safer for LLM generation, while low-level languages (C/C++) require rigorous human oversight due to frequent memory safety and compilation errors.
• Security is Not Guaranteed: Even "functionally correct" code often contains critical security flaws (e.g., hard-coded passwords, weak crypto). Functional correctness does not equate to security.
• Need for Specialized Training: The results suggest that current LLMs lack sufficient training on modern, secure coding practices and language-specific best practices (e.g., proper header inclusion in C++, secure crypto libraries in Java).
• Benchmarking Standard: This study provides a robust, reproducible baseline for future research, moving beyond simple "pass/fail" functional tests to include security, maintainability, and cross-language comparisons.

Conclusion

The paper concludes that while LLMs are powerful tools for code generation, they currently produce code with significant security and quality gaps that vary by language and model. Developers cannot rely on LLMs for secure code generation without human review, particularly for low-level languages and security-critical tasks. Future LLMs must be trained to better align with modern secure coding standards and language-specific features to be truly trustworthy.