---
title: 'PurpCode-32B: Secure Python Code Model'
url: https://www.emergentmind.com/topics/purpcode-32b
type: topic
---

# PurpCode-32B: Secure Python Code Model

to deliver a fully cited encyclopedia-style article grounded in the provided papers, 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 [2507.19060]. 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 [2507.19060].

## 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” [2507.19060]. 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 [2507.19060].

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 [2507.19060].

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 [2505.08311]. 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 [2507.19060]. 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 [2507.19060]. 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 [2507.19060]. 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 [2507.19060].

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 [2507.19060]. 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 [2507.19060].

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 [2604.03587]. 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 [2604.03587][2507.19060].

## 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 [2507.19060]. 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 [2507.19060].

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 [2507.19060]. 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 [2507.19060]. 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 [2505.08311][2604.06385].

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$ [2507.19060]. 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 [2507.19060].

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 [2507.19060]. 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 [2507.19060]. The malicious-assistance oracle is an LLM judge that flags both malicious code output and actionable step-by-step instructions for malicious cyberactivity [2507.19060]. Utility is assessed by code-execution testing in Sandbox Fusion and by an overrefusal detector that categorizes outputs as REFUSAL, IRRELEVANT, UNSAFE, or APPROPRIATE [2507.19060]. A format oracle enforces the `## Analysis` / `## Answer` template and disallows long repetitive substrings [2507.19060].

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 [2507.19060]. 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 [2507.19060]. 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 [2507.19060]. 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 [2507.19060]. Combined, these sources yield 7,288 certified vulnerable snippets spanning 90 CWEs [2507.19060].

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 [2507.19060]. 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 [2507.19060].

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 [2507.19060]. 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 [2507.19060].

## 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 [2507.19060]. 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 [2507.19060].

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 [2507.19060]. 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 [2507.19060].

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% [2507.19060]. 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 [2507.19060]. 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 [2505.08311][2604.06385].

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% [2507.19060]. On malicious assistance, CyberSecEval MITRE is nearly saturated across strong models, but PurpCode remains competitive at 99.2% safe responses [2507.19060]. 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% [2507.19060].

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 [2507.19060].

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 [2507.19060]. 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 [2507.19060].

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 [2507.19060]. HumanEval+ remains approximately 83.5 after RL, MBPP+ decreases slightly from 75.1 to 74.1, and security-QA performance remains around 98% [2507.19060]. 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 [2507.19060]. 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 [2604.03587].

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 [2604.06385]. 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 [2604.12666]. 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 [2505.08311]. 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 [2507.19060]. Some CWEs are not explicitly taught because they are absent from the analyzer or documentation coverage [2507.19060]. 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 [2507.19060]. In addition, safety and refusal judgments rely partly on LLM judges, which may introduce bias or classification error [2507.19060].

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 [2507.19060]. 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 [2507.19060].

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 [2507.19060].

Source: https://www.emergentmind.com/topics/purpcode-32b