PurpCode-32B: Secure Python Code Model

• PurpCode-32B is a 32B post-training coding model that uses Rule Learning and reinforcement learning to generate vulnerability-free Python code while safely handling malicious requests.
• The model employs explicit cybersafety rules and verifiable oracles to assess user intent, ensuring secure code generation and refusal of harmful prompts.
• Empirical evaluations reveal over 80% secure code rates and robust defense against adversarial attacks, maintaining coding utility while enhancing security.

to deliver a fully cited encyclopedia-style article grounded in the papers on arXiv, I’ll quickly verify the primary and related arXiv records before writing. Searching arXiv for the primary and related records. PurpCode-32B is a 32-billion-parameter, reasoning-style coding model produced by applying the PurpCode post-training recipe to Qwen2.5-32B-Instruct. It is designed for two coupled objectives: generating secure, vulnerability-free Python code and refusing or safely redirecting requests that would materially assist malicious cyberactivities, while preserving coding utility, common security knowledge, and low overrefusal on benign requests (Liu et al., 25 Jul 2025). In the source paper, PurpCode is defined not as a new architecture but as a post-training pipeline with two stages—Rule Learning and Reinforcement Learning—built around explicit cybersafety rules, verifiable oracles, and multi-objective optimization (Liu et al., 25 Jul 2025).

1. Definition and model identity

PurpCode is presented as “the first post-training recipe for training safe code reasoning models towards generating secure code and defending against malicious cyberactivities” (Liu et al., 25 Jul 2025). The model instantiation emphasized in that work, PurpCode-32B, uses Qwen2.5-32B-Instruct as its base model and retains the underlying architecture; the novelty lies in the alignment and post-training procedure rather than structural modification (Liu et al., 25 Jul 2025).

The intended behavior of PurpCode-32B is explicitly dual. First, it should produce secure code that avoids known vulnerability patterns, especially in Python. Second, it should refuse or redirect prompts involving malware creation, exploit development, unauthorized intrusion, or other malicious cyberactivities. The paper further states that this safety specialization is coupled to utility-preserving goals: maintaining code-generation performance, answering benign cybersecurity questions, and reducing unnecessary refusals in both general and cyber-specific benign settings (Liu et al., 25 Jul 2025).

The model is situated within a broader line of 32B-scale specialization strategies in which dense, mid-scale models are transformed through post-training rather than architectural scaling. Related work on AM-Thinking-v1 argues that 32B is a practical sweet spot for deployment and fine-tuning, and demonstrates that a 32B dense model can approach or match much larger systems on reasoning and coding benchmarks through carefully designed SFT and RL (Ji et al., 13 May 2025). This suggests a broader pattern in which PurpCode-32B should be understood as a domain-specialized 32B reasoning model rather than as a general frontier-scale model.

2. Rule Learning: explicit cybersafety reasoning and supervised post-training

The first PurpCode stage, Rule Learning, is a supervised fine-tuning phase whose purpose is to teach the model to analyze user intent, recall relevant coding safety rules, decide between safe assistance and refusal, and generate secure code or harmless explanations (Liu et al., 25 Jul 2025). The central design choice is that the model is not merely trained to emit safe outputs; it is trained to reason explicitly about safety.

In this stage, responses follow a fixed template with two sections: ## Analysis and ## Answer. The ## Analysis section contains safety reasoning, including user-intent assessment, threat analysis, and references to relevant rules; the ## Answer section contains either secure code, a safe alternative, or a refusal with redirection (Liu et al., 25 Jul 2025). This structured format is enforced both during data generation and later via a format oracle.

The Rule Learning data comprise four prompt classes. The paper lists 12k code-security prompts, 8k malicious-assistance prompts, 8k coding-utility prompts, and 4k security-QA prompts in the Rule Learning stage (Liu et al., 25 Jul 2025). Candidate trajectories are generated with a rule-aware prompt and then filtered by all applicable oracles. Only responses that satisfy safety, utility, and formatting constraints are retained for supervised fine-tuning (Liu et al., 25 Jul 2025).

The “rules” taught in this stage have three layers. The first is behavioral guidance: analyze intent, distinguish safe from unsafe requests, and decide whether to reject or partially assist. The second is explicit safety policy, including disallowed content such as insecure code, malicious code, or actionable exploit instructions, and allowed content such as secure code, benign scripts, abstract security explanations, and code explanation without exploit steps. The third is prompt-specific coding guidance derived from relevant CWEs and analyzer rules, rather than a monolithic dump of the entire CWE catalog (Liu et al., 25 Jul 2025). A YAML example in the source material contrasts yaml.load with yaml.safe_load, illustrating how the model is trained to connect concrete API choices to named vulnerability patterns (Liu et al., 25 Jul 2025).

This design places PurpCode-32B in conceptual proximity to later work on “security reasoning internalization,” which likewise argues that secure code generation improves when a reasoning model learns to enumerate plausible CWEs and mitigations before coding (Wang et al., 4 Apr 2026). The difference is methodological: SecPI teaches this behavior through teacher-generated reasoning traces paired with plain inputs, whereas PurpCode couples explicit rule learning to later RL with multi-objective safety and utility rewards (Wang et al., 4 Apr 2026, Liu et al., 25 Jul 2025).

3. Reinforcement Learning: multi-objective optimization and reward design

After Rule Learning, PurpCode performs Reinforcement Learning using Group Relative Policy Optimization (GRPO), drawing inspiration from reasoning-model RL setups such as DeepSeek-R1 (Liu et al., 25 Jul 2025). The RL stage is outcome-driven: prompts are sampled from mixed safety and utility datasets, multiple rollouts are generated, rewards are computed by automated oracles, and the policy is updated from group-relative advantages (Liu et al., 25 Jul 2025).

The RL data are substantially larger than the Rule Learning data. The paper reports 78k code-security prompts, 8k malicious-assistance prompts, 46k coding-utility prompts, and 11k security-QA prompts in the RL stage (Liu et al., 25 Jul 2025). It also notes that easier prompts, heavily solved during Rule Learning at a pass rate of at least 70%, may be excluded so that RL concentrates on harder cases (Liu et al., 25 Jul 2025). This resembles difficulty-aware filtering seen in other 32B post-training pipelines, including AM-Thinking-v1 and EduQwen, where RL is concentrated on non-trivial examples rather than uniformly over all data (Ji et al., 13 May 2025, Singh et al., 7 Apr 2026).

PurpCode’s reward scheme is mostly binary but includes a notable asymmetry for code-generation tasks. Let $r_i \in [0,1]$ be the reward for rollout $i$. If any oracle fails, then $r_i = 0$. If all oracles pass and the response contains secure code, then $r_i = 1$. If all oracles pass but the response contains no code in a secure-code task—effectively a refusal or high-level explanation—then $r_i = 0.8$ (Liu et al., 25 Jul 2025). The paper states that this is specifically intended to prevent reward hacking in which the model learns that never producing code is always safest.

For group-based RL, PurpCode defines the advantage of rollout $i$ as

$$A_i = \frac{r_i - \mathrm{mean}(r_1, \dots, r_n)}{\mathrm{std}(r_1, \dots, r_n)}.$$

When all rewards in a rollout group are identical, the standard deviation collapses and the prompt provides little or no learning signal. To address this, PurpCode uses “single-step dynamic sampling,” adjusting the number of sampled prompts based on the fraction of prompts in the previous batch with non-collapsed reward distributions, so that each update contains approximately the target number of learnable prompts (Liu et al., 25 Jul 2025).

The paper also emphasizes engineering for RL tractability. AWS CodeGuru has heavy startup costs, so PurpCode batches many code snippets into a pseudo-repository call and load-balances based on total lines of code, enabling analysis of thousands of snippets in under a minute; LLM-based oracles are run asynchronously (Liu et al., 25 Jul 2025). A plausible implication is that the authors regard cybersafety RL as limited not only by reward definition but also by verifier throughput.

4. Oracles, rules, and data construction

PurpCode’s training pipeline depends on a set of automated oracles used for filtering, evaluation, and RL reward computation. The code-security oracle is AWS CodeGuru v0.2.4, configured to report medium-and-higher-severity issues and covering 131 Python static-analysis rules spanning many CWEs and AWS-specific best practices (Liu et al., 25 Jul 2025). The malicious-assistance oracle is an LLM judge that flags both malicious code output and actionable step-by-step instructions for malicious cyberactivity (Liu et al., 25 Jul 2025). Utility is assessed by code-execution testing in Sandbox Fusion and by an overrefusal detector that categorizes outputs as REFUSAL, IRRELEVANT, UNSAFE, or APPROPRIATE (Liu et al., 25 Jul 2025). A format oracle enforces the ## Analysis / ## Answer template and disallows long repetitive substrings (Liu et al., 25 Jul 2025).

The rule base itself combines MITRE CWE definitions with static-analyzer rules, especially AWS CodeGuru detectors. The paper states that the curated vulnerable-code corpus spans 90 distinct CWE IDs, compared with no more than 27 CWEs in prior security datasets such as SecCodePLT, and that 65 CWEs are unique to the PurpCode corpus (Liu et al., 25 Jul 2025). This breadth is operationalized through three vulnerable-code sources.

The first source is OSV-derived Python vulnerability instances. From 8,005 Python vulnerability instances collected through the Open Source Vulnerabilities database, the authors extract vulnerable pre-patch code and obtain 1,934 CodeGuru-confirmed vulnerable snippets covering 81 CWEs (Liu et al., 25 Jul 2025). The second source is open datasets: 6k Python snippets from existing security corpora plus translated non-Python vulnerabilities, yielding 2,869 confirmed vulnerable snippets and four additional CWEs (Liu et al., 25 Jul 2025). The third source, Rule2Code, uses DeepSeek-R1 to generate vulnerable code directly from rule documentation and examples for low-resource rules, producing 2,485 CodeGuru-confirmed snippets, five new CWEs, and 16 new CodeGuru detectors (Liu et al., 25 Jul 2025). Combined, these sources yield 7,288 certified vulnerable snippets spanning 90 CWEs (Liu et al., 25 Jul 2025).

These vulnerable snippets are then converted into prompts through Vul2Prompt. The generated prompts fall into three categories: vulnerability-inducing instructions, vulnerable continuations of benign code, and vulnerability-processing prompts that ask the model to refactor, extend, or integrate already vulnerable code (Liu et al., 25 Jul 2025). After deduplication and decontamination against public benchmarks such as CWEval and CodeLMSec, the paper reports 69k code-security prompts: 26k vulnerability-inducing instructions, 21k vulnerable continuations, and 21k vulnerability-processing prompts (Liu et al., 25 Jul 2025).

PurpCode also constructs 24k malicious-assistance prompts by combining real-world prompts from sources such as Discord, Reddit, and LMSYS with expert-crafted or synthetic prompts derived from cyber datasets including CySecBench, RMCBench, and cyber-relevant subsets of HarmBench (Liu et al., 25 Jul 2025). In addition, the work builds jailbreak corpora tailored separately to vulnerable code generation and malicious assistance. For code security, generic jailbreak methods are adapted to long code-text prompts and conditioned on specific vulnerabilities; for malicious assistance, the paper uses template-based, search-based, and multi-turn attacks including AutoDAN, LAA Attack, and ActorAttack (Liu et al., 25 Jul 2025).

5. Empirical profile: secure code generation, malicious-assistance defense, overrefusal, and utility

PurpCode-32B is evaluated on secure code generation, malicious-assistance defense, jailbreak robustness, overrefusal, and code utility (Liu et al., 25 Jul 2025). The benchmarks include CyberSecEval Secure Code Generation, CodeLMSec, CWEval, CyberSecEval MITRE, university red-teaming data from the Amazon Nova AI Challenge, multiple jailbreak suites, CyberSecEval False Refusal Rate, XSCode, XSTest, PHTest, HumanEval+, MBPP+, and a multi-turn security-QA set from the same Nova challenge (Liu et al., 25 Jul 2025).

On secure code generation, the reported results are strongest on CyberSecEval SCG and CodeLMSec. PurpCode-32B reaches 80.8% secure code on CyberSecEval SCG, compared with 72.3% for Qwen3-235B, 68.1% for Qwen3-32B, 67.9% for Claude Sonnet 4, 67.5% for DeepSeek-R1, and 64.5% for o4-mini (Liu et al., 25 Jul 2025). On CodeLMSec it reaches 94.8%, compared with 78.1% for Qwen3-32B, 77.1% for Qwen3-235B, 67.6% for o4-mini, 64.1% for Sonnet 4, and 57.8% for DeepSeek-R1 (Liu et al., 25 Jul 2025).

On CWEval, however, PurpCode-32B scores 48.0% on the Python secure-and-correct metric, below DeepSeek-R1 at 84.0%, Sonnet 4 at 76.0%, o4-mini at 75.0%, and Qwen3-32B at 56.0% (Liu et al., 25 Jul 2025). The source paper attributes this to weaker generic coding ability in the base model, but also notes that PurpCode still improves its own base Qwen2.5-32B from 40 to 48 on CWEval, suggesting that the safety alignment does not degrade its underlying correctness-security tradeoff relative to its starting point (Liu et al., 25 Jul 2025). This is consistent with the general observation in 32B post-training work that specialization can dramatically improve targeted behavior without uniformly dominating all utility benchmarks (Ji et al., 13 May 2025, Singh et al., 7 Apr 2026).

On adversarial university red-teaming for code security, PurpCode-32B reports 77.6% secure code, substantially above Sonnet 4 at 57.3%, o4-mini at 53.6%, Qwen3-32B at 50.1%, Qwen3-235B at 48.1%, and DeepSeek-R1 at 44.2% (Liu et al., 25 Jul 2025). On malicious assistance, CyberSecEval MITRE is nearly saturated across strong models, but PurpCode remains competitive at 99.2% safe responses (Liu et al., 25 Jul 2025). On the university malicious-assistance red-teaming benchmark, PurpCode-32B reports 98.2% safe responses, above o4-mini at 96.4%, Qwen3-235B at 95.5%, DeepSeek-R1 at 95.0%, Qwen3-32B at 93.9%, and Sonnet 4 at 91.8% (Liu et al., 25 Jul 2025).

Jailbreak resistance is reported as another major strength. The paper states that PurpCode-32B achieves the highest defense success rate across template-based, search-based, and multi-turn attacks. One concrete figure given is 87.8% safe under ActorAttack, compared with 70.7% for Sonnet 4, 60.8% for Qwen3-235B, and 56.5% for Qwen3-32B (Liu et al., 25 Jul 2025).

Overrefusal is treated as a first-class evaluation target rather than a side effect. PurpCode-32B answers 92.7% of prompts on CyberSecEval FRR, 93.5% on XSCode’s joint non-refusal-and-secure metric, 98.0% on XSTest, and 98.6% on PHTest (Liu et al., 25 Jul 2025). The source paper highlights that PurpCode is not simply safer because it refuses more often; on XSCode, XSTest, and PHTest it is reported as the best-performing evaluated model (Liu et al., 25 Jul 2025).

The utility results are more mixed but are explicitly described as preserved. For Qwen2.5-32B, CyberSecEval SCG improves from 64.8 in the base model to 68.5 after Rule Learning and 80.8 after RL, while CodeLMSec rises from 29.2 to 71.4 to 94.8 (Liu et al., 25 Jul 2025). HumanEval+ remains approximately 83.5 after RL, MBPP+ decreases slightly from 75.1 to 74.1, and security-QA performance remains around 98% (Liu et al., 25 Jul 2025). This suggests that PurpCode’s alignment regime is designed to improve safety without inducing the severe utility collapse sometimes observed in more conservative secure-code alignment schemes.

6. Interpretation, limitations, and place in the literature

PurpCode-32B occupies a distinctive position in the secure-code literature because it combines explicit rule-based safety reasoning with verifiable-oracle RL. Earlier secure-code approaches often concentrated on curated vulnerability corpora or on prompting-time security reminders, whereas PurpCode attempts to train a reasoning model that can internalize cyber rules, generate secure code, refuse malicious assistance, and avoid benign-query overrefusal in a single pipeline (Liu et al., 25 Jul 2025). In this respect it is adjacent to, but methodologically distinct from, SecPI, which fine-tunes reasoning models on teacher-generated security reasoning traces so that they spontaneously enumerate CWEs and mitigations even without explicit security instructions at inference time (Wang et al., 4 Apr 2026).

The broader context is a wave of application-driven optimization of open-source 32B models. EduQwen shows that a dense Qwen3-32B backbone can be transformed into a pedagogical specialist through an RL-SFT-RL curriculum and surpass much larger proprietary systems on the CDPK benchmark (Singh et al., 7 Apr 2026). Triton shows that a Qwen2.5-Coder-32B-Instruct backbone can outperform much larger general models in web navigation through progressive SFT, ORPO, and GRPO over a specialized hard-negative curriculum (Peng et al., 14 Apr 2026). AM-Thinking-v1 shows that a 32B dense model can approach or match large MoE systems on math and coding benchmarks with large-scale SFT plus RL (Ji et al., 13 May 2025). Taken together, these results support the interpretation that PurpCode-32B is part of a general research program in which targeted post-training and verifier-driven curricula can outweigh raw parameter scale on focused tasks.

The PurpCode paper also states several limitations. Its rule coverage is centered on Python and on CodeGuru-covered rules, so other languages and vulnerability classes remain less directly addressed (Liu et al., 25 Jul 2025). Some CWEs are not explicitly taught because they are absent from the analyzer or documentation coverage (Liu et al., 25 Jul 2025). The model may still fail under distribution shift or under adversarial prompts outside the training distribution, and the reported results do not constitute production-ready security guarantees (Liu et al., 25 Jul 2025). In addition, safety and refusal judgments rely partly on LLM judges, which may introduce bias or classification error (Liu et al., 25 Jul 2025).

A common misconception would be to treat PurpCode-32B as uniformly superior on all secure-coding benchmarks. The reported CWEval result contradicts that interpretation: PurpCode-32B trails some frontier models on the joint secure-and-correct Python metric, even while leading on CyberSecEval SCG, CodeLMSec, university red-teaming, jailbreak defense, and several overrefusal measures (Liu et al., 25 Jul 2025). Another misconception would be to infer that the model’s safety derives from blanket refusal. The XSCode, XSTest, and PHTest results, together with the partial-reward design that discourages “never output code,” indicate that the training objective explicitly penalizes that failure mode (Liu et al., 25 Jul 2025).

Within the literature on alignment for code LLMs, PurpCode-32B is therefore best understood as a rule-aware, verifier-driven, reasoning-centric 32B specialist for cybersafety. Its significance lies not in introducing a new model architecture, but in showing that explicit cybersafety rules, large-scale internal red-teaming, and multi-objective RL can jointly improve secure code generation, resistance to malicious-assistance prompting, and low overrefusal without large utility collapse (Liu et al., 25 Jul 2025).