Reasoning language models (RLMs) are increasingly used in programming. Yet, even state-of-the-art RLMs frequently introduce critical security vulnerabilities in generated code. Prior training-based approaches for secure code generation face a critical limitation that prevents their direct application to RLMs: they rely on costly, manually curated security datasets covering only a limited set of vulnerabilities. At the inference level, generic security reminders consistently degrade functional correctness while triggering only shallow ad-hoc vulnerability analysis. To address these problems, we present SecPI, a fine-tuning pipeline that teaches RLMs to internalize structured security reasoning, producing secure code by default without any security instructions at inference time. SecPI filters existing general-purpose coding datasets for security-relevant tasks using an LLM-based classifier, generates high-quality security reasoning traces with a teacher model guided by a structured prompt that systematically enumerates relevant CWEs and mitigations, and fine-tunes the target model on pairs of inputs with no security prompt and teacher reasoning traces -- as a result, the model learns to reason about security autonomously rather than in response to explicit instructions. An extensive evaluation on security benchmarks with state-of-the-art open-weight reasoning models validates the effectiveness of our approach. For instance, SecPI improves the percentage of functionally correct and secure generations for QwQ 32B from 48.2% to 62.2% (+14.0 points) on CWEval and from 18.2% to 22.0% on BaxBench. Further investigation also reveals strong cross-CWE and cross-language generalization beyond training vulnerabilities. Even when trained only on injection-related CWEs, QwQ 32B generates correct and secure code 9.9% more frequently on held-out memory-safety CWEs.
Figures & tables
Figure 1: Reasoning LLMs reason insufficiently about security by default when coding. When instructed for security, they do not systematically explore all potential vulnerabilities and do not apply the correct mitigations. SecPI trains the model to proactively reason about security and the CWEs systematically, leading to the generated code being secure.
Figure 2: Main techniques of SecPI: I. SecPI curates security-relevant data with low cost by scraping existing general-purpose coding datasets for security-relevant problems. II. It then uses a CWE-based prompt to synthesize structured and systematic security reasoning and responses from a teacher model. III. Finally, it adopts supervised fine-tuning to internalize the prompt and train the student model to produce similar reasoning by default.
Figure 3: Results of evaluating our method on CWEval and BaxBench. On both datasets SecPI leads to noticeable FuncSec and improvements compared to standard and simple security prompts. Fine-tuning with SecPI elicits the models’ security reasoning and increases security even when given only the standard prompt with no extra security instructions. PurpCode shows universally lower and, comparing to models sharing the same base model ( QwQ 32B and Qwen 32B-D ), lower FuncSec . + indicates the untrained models are enhanced for BaxBench.
Figure 4: Results of evaluation on LiveCodeBench. The left panel shows that throughout the training of SecPI, Func on tasks unrelated to security stays comparatively stable. The right panel shows that prompting can degrade functional correctness even for frontier reasoning models.
Figure 5: Results of the three trace-analysis metrics that we introduce, Security Reasoning , CWE Keyword Coverage , and GPT-assessed Quality , on the traces generated by QwQ 32B on CWEval and BaxBench. We observe a strong correlation between the security of the generated code and the quality of the security reasoning by the three metrics. Overall, SecPI leads to more consistent and accurate security reasoning.
Table 6
Figure 6: Results of evaluating three different prompts in prompting and tuning on CWEval. Better prompting performance does not imply better tuning performance. Although the unrealistic CWE-specified prompt achieves the highest FuncSec and , training on its generated traces does not lead to the same level of security as the model trained on our structured prompt.
Appendix figures & tables12 assets
Supplementary material from the paper’s appendix.
Appendix
Figure 7: Difficulty distribution (left) and solution length by difficulty (right) for the 1,327 security-filtered problems, using GPT-assessed difficulty labels from Kodcode-V1 . Easy problems dominate the filtered set; solution length grows with difficulty, serving as a proxy for task complexity.
Figure 8: Distribution of the 15 most frequent CWE categories in our training dataset. The dataset covers 100 distinct CWEs in total, with an average of 1.42 CWEs per problem.
Table 3: CWE-specific keyword lists used for CWE Keyword Coverage (representative subset). Each CWE also implicitly matches the token cwe-{id} .
CWE
Name
CWE-20
Improper Input Validation
CWE-22
Path Traversal
CWE-59
Improper Link Resolution Before File Access
CWE-73
External Control of File Name or Path
CWE-74
Improper Neutralization of Special Elements in Output
CWE-78
OS Command Injection
Appendix
Table 4: Injection-related CWE cluster used in the cross-CWE generalization experiment.
CWE
Name
CWE-119
Improper Restriction of Operations within a Memory Buffer
CWE-120
Buffer Copy without Checking Size of Input (Classic Buffer Overflow)
CWE-121
Stack-based Buffer Overflow
CWE-125
Out-of-bounds Read
CWE-129
Improper Validation of Array Index
CWE-131
Incorrect Calculation of Buffer Size
Appendix
Table 5: Memory-safety-related CWE cluster used in the cross-CWE generalization experiment.
Figure 9: BaxBench FuncSec results for all model variants. Absolute scores across all methods remain low, which we attribute to the fact that none of the evaluated models were specifically tuned or optimized for the BaxBench task format. Consequently, the differences between variants are small in absolute terms and should be interpreted with caution. Nevertheless, the relative ordering of variants is consistent with findings on CWEval, and the tuned models still show a modest but consistent improvement over prompting-only baselines.
Model
Variant
LCB
CWEval
BaxBench
Func
FuncSec
FuncSec
QwQ 32B
Generic
59.4
48.2
57.5
18.4
63.6
Generic Secure
57.6
54.1
66.1
18.1
64.2
Our Secure
59.4
60.7
77.6
18.4
68.1
Tuned (Ours)
52.6
62.2
87.5
22.0
84.2
Qwen 32B-D
Generic
53.2
46.9
63.4
15.7
64.8
Appendix
Table 6: Full main evaluation results across all model variants. FuncSec and are reported for CWEval and BaxBench; Func is reported for LiveCodeBench (LCB).
Model
Variant
CWEval
BaxBench
S
K
G
S
K
G
QwQ 32B
Standard Prompt
45.5
14.5
59.1
61.1
27.7
63.3
Generic Secure Prompt
67.7
21.7
66.5
74.6
33.6
65.7
Our Secure Prompt
99.8
39.5
72.8
91.1
47.7
70.6
Tuned (Ours)
100.0
51.8
78.8
99.8
75.4
76.4
Qwen 32B-D
Standard Prompt
55.1
13.6
65.9
61.7
30.0
62.2
Appendix
Table 7: Full trace-metric evaluation results. Security Reasoning ( S ), CWE Keyword Coverage ( K ), and GPT-assessed Quality ( G ) are measured on the reasoning traces produced by each model variant on CWEval and BaxBench. An entry of “—” indicates results were not collected for that configuration.
Figure 10: Results on CWEval and LiveCodeBench of the models trained on datasets sampled with different sizes. Smaller datasets rapidly improve the model’s default security capability but also leads to more functionality loss. Larger datasets steadily increase security, while maintaining a stable functionality performance.
Base
Metric
DeepSeek R1
QwQ 32B
Qwen 32B-D
QwQ 32B
Func
52.6 (-6.8)
55.8 (-3.6)
57.9 (-1.5)
FuncSec
62.2 ( +14.0 )
56.8 (+8.6)
48.2 (+0.0)
87.5 ( +30.0 )
74.9 (+17.4)
75.3 (+17.8)
Qwen 32B-D
Func
55.3 ( +2.1 )
46.8 (-10.6)
55.3 ( +2.1 )
FuncSec
54.1 (+7.2)
54.2 (+7.4)
47.6 (+0.7)
85.2 (+21.8)
73.4 (+10.0)
78.6 (+15.2)
Appendix
Table 8: The performance of QwQ 32B and Qwen 32B-D on LiveCodeBench and CWEval after trained on datasets generated with three different teacher models ( DeepSeek R1 , QwQ 32B , Qwen 32B-D ). We show the LiveCodeBench performance via the Func metric and the CWEval results via FuncSec and . The best results are bolded .
Metric
CompCode
KodCode-NoSec
KodCode-Sec
FuncSec
45.9 (-2.3)
55.8 (+7.6)
63.2 ( +14.0 )
65.0 (+7.5)
83.4 (+25.9)
87.5 ( +30.0 )
Appendix
Table 9: Performance of three models trained on three different ablation datasets on CWEval. CompCode uses problems from LiveCodeBench, KodCode-NoSec uses benign problems from Kodcode-V1 , and KodCode-Sec uses filtered security-relevant problems from Kodcode-V1 . The best results for each metric are bolded .
Figure 21: Traces in the training dataset for problem Filter_46630_I generated by our prompt and the CWE-specified prompt. This shows that our prompt induces natural vulnerability analysis before identifying the CWE while the cwe-specified prompt leads to unnatural security reasoning where the model recognizes the CWE as part of the requirement without any security reasoning.
Large Language Models (LLMs) can generate functionally correct code that remains insecure. Security-focused fine-tuning can be expensive and is not always available, motivating inference-time approaches. Security-oriented prompting and retrieval can reduce vulnerabilities, but may also remove required behavior or apply defenses incompatible with the task. The challenge is to identify relevant security knowledge and use it to improve security without sacrificing functionality. We present SecGent, an inference-time framework that retrieves weakness context from the Common Weakness Enumeration (CWE) database and applies it to secure code generation. By connecting task specifications to relevant textual CWE records, SecGent provides task-specific security guidance without relying on retrieved vulnerable or patched code examples. Complementary functional and security tests check the resulting implementation, and their execution feedback guides repairs toward satisfying both objectives. We evaluate SecGent with four open-source LLMs and Claude Sonnet 5.5 across five programming languages on the CWEval benchmark. It achieves the highest joint functional--security success against four inference-time baselines for all five models. Across the open-weight models, mean functional-security@1 (FS@1) improves by 15.5% over RAG, with gains in both functionality and security, and by 19.8% over the strongest prompt optimizer compiled for each model. On Sonnet, FS@1 reaches 92.1%, outperforming the strongest baseline AutoGen by 4.8%. In a separate comparison, SecGent outperforms Claude Code with security-focused prompting by over 6% in FS@1. Feedback-guided repair further improves FS@1 by up to 6.7% over generation without feedback, primarily by recovering functionality while checking security.
Md Afif Al Mamun, Gias Uddin
University of Calgary, Calgary, Canada · York University, Toronto, Canada
Large language models (LLMs) are increasingly used for program synthesis, yet they often generate code that is functionally plausible but insecure. Progress in secure code generation has been hindered by benchmarks that are small, non-executable, leak mitigation details, or rely on noisy analyzers and subjective judgments, making it difficult to measure whether security improves without sacrificing correctness. We address these gaps with CodeSecEval, an execution-based benchmark for secure code generation, comprising 255 Python tasks spanning 77 CWE categories. Each task provides paired insecure and secure implementations together with executable functional and vulnerability-targeted security tests, enabling precise and reproducible evaluation of secure code generation and insecure-code repair. Building on CodeSecEval, we propose SecAwareCoder, an agent-based framework that shifts code generation toward secure-by-construction synthesis. SecAwareCoder performs task-adaptive threat modeling to identify security-sensitive regions and derive task-grounded vulnerability hypotheses, uses these hypotheses to guide both constraint-aware code generation and security-aware test synthesis, and leverages execution feedback for targeted refinement. Experiments across multiple LLM backbones show that SecAwareCoder consistently improves Pass@1 and security robustness over prompting and analyzer-driven baselines, narrowing the security--correctness gap in LLM code generation.
Jiexin Wang, Liuwen Cao, Xitong Luo +6
South China University of Technology, Guangzhou, China · University of Innsbruck, Innsbruck, Austria
Large Language Models (LLMs) can generate functionally correct code while introducing exploitable security weaknesses, particularly when developers specify functionality without explicit security requirements. Recent state-of-the-art approaches mitigate this problem using external security knowledge, but largely rely on flat similarity-based retrieval over independent artifacts, making it difficult to infer the relevant vulnerability space and retrieve targeted knowledge when direct matches are unavailable. We propose SEEK, an agentic Graph RAG framework for secure code generation that constructs a security knowledge graph using the Common Weakness Enumeration (CWE) taxonomy as its structural backbone and injects it with curated real-world CVE vulnerability-fix instances. At inference time, a Planner Agent predicts potential CWE weaknesses associated with the developer query, which guide Graph Scoping to restrict retrieval to relevant regions of the CWE taxonomy before deterministic multi-faceted candidate ranking. A Selection Agent subsequently validates the predicted weaknesses and retrieved candidates prior to code generation. Across five open-source LLMs, we evaluate SEEK in an out-of-distribution setting on CodeGuard+ and CyberSecEval, spanning C, C++, and Python. SEEK achieves the highest SecurePass@1 of 77.45% on CodeGuard+ and the highest aggregate ICD pass rate of 79.45% on CyberSecEval, surpassing prior approaches. Moreover, SEEK achieves 85.2% SecurePass@1 across 13 unseen CWE types with no directly linked vulnerability-fix instances, demonstrating strong generalizability, while maintaining acceptable inference latency costs.
Varun Gadey, Markus Tohn, Lichao Wu +2
University of Duisburg-Essen, Germany · University of Bristol, UK · Technical University of Darmstadt, Germany