PaperlayerView exact revision on arXiv

Source-linked AI summary

Newer and Bigger, but Safer? A Longitudinal Study of the Functionality-Security Gap in LLM-Generated Code

Thiago Santos de Moura, Fynn Matuschek, Flavio Toffalini, Yannic Noller

arXiv:2610.08240v1cs.SEcs.CR

TL;DR

Prior research leaves open whether security trajectories found in a few model families also hold for other open-weight families and compact models. This study tracks the functionality-security gap across 32 models and finds that models become safer, but no family closes the gap.

  • Problem

    Prior security evaluations are often snapshots, leaving how model security changes across versions, tiers, weaknesses, and languages insufficiently established.

    Source: §1 · p. 1

  • Method

    The study evaluates 32 models from seven families over three stages using CWEval tasks in five programming languages, including flagship and compact tiers where available.

    Source: §1 · p. 2, §3.2 · p. 7

  • Results

    Every family narrows the functionality-security gap by its newest stage for at least one attempt count, but none closes it; openness does not determine the trajectory, and CWE risks vary by language.

    Source: §1 · pp. 2–3, §7 · p. 19

  • Takeaways & Limitations

    Because functional plausibility does not ensure security, security should be evaluated alongside functionality.

    Source: §5 · p. 15

    The findings may not generalize to other model families, CWEs, or programming languages, and CWEval’s isolated single-function tasks do not represent larger project contexts.

    Source: §6 · p. 18

Abstract

from arXiv · show

Large Language Models (LLMs) are widely used to generate code. Although their functional plausibility keeps improving, the generated code often contains security vulnerabilities. The functionality-security gap captures code that passes functional tests but fails security tests. A recent longitudinal study of three model families concluded that LLMs become smarter but not safer, with the only considered open-weight family stagnating. Whether this holds for other (open-weight) families and particularly for compact models remains open. We present a longitudinal study of the gap across 32 LLMs from seven model families (five open-weight), covering three successive releases per family in flagship and compact variants. Using CWEval with 119 tasks in five programming languages and 31 CWEs, we compare trajectories across families, model sizes, and languages. Newer models do become safer in absolute terms, although no family closes the gap. Unlike prior work, we find that openness does not separate the families: every considered open-weight family narrows the gap significantly, while Gemini 3.1 Pro keeps a gap as wide as the one reported for Llama. Compact models usually produce less secure code than their flagship counterparts, with notable exceptions (e.g., Gemini 3.7 Flash). At the CWE level, we confirm persistent weaknesses such as log injection (CWE-117) and HTTP response splitting (CWE-113) and regressions in the newest proprietary models on memory and integer weaknesses, and show that the same CWE carries very different risk across languages. From these results, we derive implications for LLM vendors, researchers, and developers. In particular, developers should assume neither that upgrades improve security nor that proprietary models are more secure; they should rerun security checks after each model change and provide secure APIs in the model's context.

1 Introduction

This study extends prior longitudinal work on the functionality-security gap to more model families, compact tiers, and language-specific weaknesses. It finds that newer models become safer in absolute terms, but no family closes the gap, and the results motivate evaluating security alongside functionality.

1 Introduction

  • Prior studies largely evaluate security at one point in time, leaving unclear whether upgrades improve security or reintroduce weaknesses.Cannavale et al. found that the gap narrowed for two proprietary families but not Llama, while examining only one tier per family and one open-weight family.Source: §1 · p. 2
  • The study follows 32 models from seven families across three stages, including flagship and compact tiers where available, using 100 samples for each of 119 CWEval tasks.The study asks how the gap changes across stages and tiers, and how CWE behavior varies across categories and programming languages.Source: §1 · p. 2
  • Every family’s newest stage produces more functionally plausible and secure code, and each narrows the gap for at least one attempt count, but none closes it.Google’s newest stage does not significantly narrow the gap with a single attempt when functional plausibility grows almost as fast as security.Source: §1 · p. 2
  • Log injection and HTTP response splitting remain insecure in most models, while CWE risks vary by language and C has the highest vulnerability rate in most models.Some newest models also regress on weaknesses their predecessors had handled.Source: §1 · p. 3
  • Openness does not separate family trajectories: every open-weight family narrows its gap, while the newest Google flagship retains a gap as wide as Llama’s.Compact models are almost always less secure when tiers differ significantly, but the penalty shrinks over time and some compact models match their flagships, including Gemini 3.7 Flash.Source: §1 · p. 3
  • Vendors should report security scores alongside functional scores, developers should recheck security after model changes, and researchers should study multiple attempts and more than two versions.The paper also provides a replication package containing generated code, execution results, and analysis scripts.Source: §1 · p. 3

2 Background & Related Work

The background explains how software weaknesses are categorized and why generated code must be assessed for both functionality and security. It positions this longitudinal study against prior work and describes its expanded scope and sampling.

2.1 Common Weakness Enumeration (CWE)

  • The Common Weakness Enumeration catalogs types of software and hardware weaknesses that can lead to vulnerabilities, including injection, path traversal, and resource-consumption flaws.The paper groups weaknesses by underlying mistake, such as unescaped input reaching a page, query, or interpreter.Source: §2.1 · p. 3

2.2 Evaluating the Security of Generated Code

  • Security evaluation must check both whether generated code works and whether it withstands attacks; CWEval tests standalone functions with functional and dynamic security oracles.Static detectors can miss insecure code, while security-only evaluation can reward solutions that do nothing.Source: §2.2 · p. 4

2.3 Longitudinal Studies of LLMs

  • Prior longitudinal studies either examine other model properties or use platform-level static analysis; Cannavale et al. omit compact tiers and most open-weight families.This study uses 100 samples per task, reports k=1 and k=50, and analyzes particular CWE risks by language, extending their 10-sample and language-averaged design.Source: §2.3 · pp. 4–5

3 Study Methodology

The study tracks the functionality-security gap across model versions and tiers, examining its trajectory, CWE categories, and variation across programming languages.

3 Study Methodology

  • The methodology examines gap trajectories, flagship-versus-compact differences, CWE behavior, and language-specific risk across model families.These are the four research questions guiding the study.Source: §3 · p. 5

3.1 Models Selected

  • The dataset covers 32 models across seven families and three successive stages, with flagship and available compact tiers.The families include two proprietary and five open-weight groups.Source: §3.1 · p. 5, Table 1 · p. 6

3.2 Benchmark Selected

  • CWEval supplies 119 tasks spanning 31 CWEs and five languages, with separate functional and dynamic security oracles.The study uses prompts without secure-code instructions and leaves CWEval’s prompts, oracles, and task set essentially unchanged.Source: §3.2 · p. 7

3.3 Data Collection

  • The 32 models generated 380,800 programs from 100 samples per task, using reused results for four proprietary models and new runs for the others.The study increased completion budgets for reasoning models.Source: §3.3 · p. 7

3.4 Evaluation Metrics

  • Across 119 tasks, func@k measures functional plausibility, func-sec@k measures plausible and secure output, and Δsec(k) and CVR characterize the gap and insecure share.Results report k=1 and k=50; CVR is calculated over groups such as a CWE or language.Source: §3.4 · pp. 7–8

3.5 Data Analysis

  • The analysis uses task-clustered GEEs for stage and tier comparisons, then tracks CWE vulnerability rates across stages and languages, inspecting samples to explain selected patterns.CWE categories are classified as persistent blind spots, evolutionary divergences, or regression anomalies.Source: §3.5 · p. 8

4 Results

Across families, the functionality-security gap narrows but remains open, and compact models are less secure than flagships in most significant tier differences. Vulnerability risks persist, diverge across families, and vary by programming language.

4.1 RQ1: Evolution of the Functionality-Security Gap

  • At the newest stage, the gap remains 0.13 for GPT-5.6 Sol to 0.28 for Gemini 3.1 Pro at k=1; every family narrows it significantly for at least one k, but none closes it.Source: §4.1 · pp. 8, 10, Figure 1 · p. 9
  • Security gains narrow the gap only when they outpace gains in functional plausibility; Google’s gap barely changes at k=1 but narrows at k=50.Source: §4.1 · p. 9

4.2 RQ2: Comparison Between Flagship and Compact Models

  • When tier differences are significant, compact models have the wider gap in eight of nine cases, though the penalty shrinks over time and persists at the newest stage in OpenAI and DeepSeek.Source: Table 3 · p. 11, §4.2 · p. 11

4.3 RQ3: Persistence, Divergence, and Regression of Vulnerabilities

  • Log injection (CWE-117) and HTTP response splitting (CWE-113) remain near the maximum across almost every family, tier, and stage.For CWE-113, OpenAI’s middle stage is the exception, with GPT-5 securing more than half of its functionally plausible samples before partly losing that gain.Source: §4.3 · pp. 12–13
  • CWE-79 and CWE-643 divide families regardless of openness, while CWE-347 improves across proprietary families without comparable gains in open-weight families.Source: §4.3 · p. 13
  • Regressions include CWE-400 in the newest flagships, where models shift from plain-text search to attacker-controlled regular expressions, and CWE-125 and CWE-190 in newest proprietary models.Source: §4.3 · p. 13

4.4 RQ4: Vulnerability Categories Across Programming Languages

  • C has the highest vulnerability rate in 27 of 32 models, but the risk of a CWE varies by language; CWE-347 CVR is 0.73 in Go and 0.71 in C versus 0.04 in Python.Source: Figure 3 · p. 14, §4.4 · p. 14
  • Language-specific tools and coding patterns help explain divergent risks: Python’s library enforces a fixed HMAC algorithm, while C requires models to write their own escaping function.Source: §4.4 · p. 15

5 Discussion

The discussion argues that generated code’s functionality does not guarantee security, and draws implications for vendors, developers, and researchers. It also contrasts the study’s longitudinal findings with prior work on model families and programming languages.

5 Discussion

  • Because functional plausibility is high yet no family closes the gap, exploitable generated code adds security debt; security must be assessed alongside functionality.CWE-79 remains at the maximum in both Qwen tiers, and CWE-22 stays at or above one half in nearly all newest models.Source: §5 · p. 15

5.1 Implications for LLM Vendors

  • Vendors should report security measures alongside functional scores, check regressions per CWE, and target persistent CWE-117 and CWE-113 blind spots in training.A narrowing aggregate gap can hide regressions in individual weaknesses; the authors suggest adding the two persistent blind spots to security-instruction-tuning data.Source: §5.1 · pp. 15–16

5.2 Implications for Developers

  • Developers should rerun security checks after version changes, compare compact tiers directly, match models to language-specific weaknesses, and supply secure APIs in context.The authors also recommend particular care reviewing generated C code and manual review of code that writes logs or HTTP headers.Source: §5.2 · p. 16

5.3 Implications for Researchers

  • Studies should report both attempt counts and include intermediate versions; family selection shapes open-weight conclusions, while regression mechanisms remain unresolved.The authors identify a caller-controlled regular expression as one observed regression mechanism, but leave its broader cause and prevention for future study.Source: §5.3 · pp. 16–17

5.4 Relation to Prior Longitudinal Work

  • Compared with Cannavale et al., absolute security rises across our families, openness does not predict gap closure, and CWE risks vary by language; family selection may explain prior differences.The studies also agree that the gap and blind spots persist; the authors attribute the difference in open-weight conclusions mainly to the choice of families.Source: §5.4 · pp. 17–18

6 Threats to Validity

The authors identify possible limits from task contamination, default prompting, model-stage differences, and benchmark scope. They treat per-CWE findings cautiously where few tasks support a category.

6 Threats to Validity

  • CWEval tasks may have entered training data and inflated improvement; unchanged prompts measure default behavior, not security-aware prompting.GPT-5 and GPT-5 mini used T=1 rather than the usual CWEval T=0.8, and first-stage proprietary results were reused where the earlier models were no longer served.Source: §6 · p. 18
  • Findings may not generalize to omitted model families, CWEs, or languages, and isolated single-function tasks do not establish behavior in larger codebases.The authors leave whether a larger context helps avoid the observed weaknesses for future work.Source: §6 · p. 18
  • Several CWE categories rest on only one or two tasks, so their results are treated as benchmark-task observations rather than general claims about those CWEs.The authors manually inspected regressions and report a cause only when it recurs across inspected samples.Source: §6 · p. 18

7 Conclusion

Across 32 models from seven families, the gap narrows by the newest stage but never closes. The authors conclude that openness does not determine trajectories and that security varies across tiers, weaknesses, and languages.

7 Conclusion

  • Every family narrows the gap significantly by its newest stage, but none closes it; narrowing occurs only when security grows faster than functional plausibility.The study covers 32 models from seven families across three stages and two tiers.Source: §7 · p. 19
  • When tiers differ significantly, compact models are less secure in eight of nine cases, while CWE-117 and CWE-113 remain insecure in almost every model.Newer versions can also regress on individual weaknesses, and C has the highest CVR in most models.Source: §7 · p. 19
  • Future work will evaluate CWEval’s secure mode across stages and tiers and study coding-agent security across versions while holding the underlying model fixed.Source: §7 · p. 19
Loading 2610.08240v1…