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.