PurpCode: Cybersafety Code Alignment

• PurpCode is a post-training method that turns standard code models into cybersecurity-aligned systems by combining rule learning and reinforcement learning.
• It employs explicit reasoning and policy-based guidelines to analyze user intent and generate CWE-compliant, secure code while safely refusing malicious requests.
• Empirical benchmarks demonstrate state-of-the-art performance in secure code generation and malicious assistance defense, with minimal overrefusal.

Searching arXiv for the exact PurpCode paper and closely related code-safety work to ground the article. PurpCode is a post-training recipe for turning a code-capable reasoning model into a cybersafety reasoning model: one that both refuses to facilitate malicious cyberactivity and generates secure, vulnerability-free code for benign requests. It was introduced as a two-stage method—Rule Learning followed by Reinforcement Learning—and instantiated as PurpCode-32B, a reasoning-based coding model obtained by post-training Qwen2.5-32B-Instruct. The method is positioned as broader than ordinary safety alignment because it targets both malicious-use resistance and secure code generation while attempting to reduce overrefusal and preserve utility on code generation and common security knowledge (Liu et al., 25 Jul 2025).

1. Conceptual scope and policy model

PurpCode addresses two failure modes that are distinct but tightly coupled in code models. The first is direct assistance with malicious cyberactivity, such as generating offensive code or actionable exploit guidance. The second is insecure fulfillment of benign requests, where a model complies with an apparently legitimate programming task but emits code that violates secure coding best practices. In this framing, safe code generation is not only refusal behavior; it also includes positive generation of secure implementations for benign prompts (Liu et al., 25 Jul 2025).

The policy structure used in training has three components. Behavioral guidelines require the model to analyze user intent, determine whether a request is malicious or can be safely fulfilled, and choose among refusal, partial refusal with safe help, or safe completion. Safety guidelines / policy define disallowed outputs as $D0$, $D1$, and $D2$: code or scripts enabling malicious cyberactivity; vulnerable code violating secure coding best practices or CWE-related weaknesses; and actionable explanations for malicious cyberactivity, including identifying exploitable vulnerabilities. Allowed outputs are $A0$, $A1$, $A2$, and $A3$: benign, risk-free scripts; fully secure code with no CWE-style weaknesses; benign general cybersecurity explanations; and non-actionable code explanations. Prompt-specific coding hints inject only the vulnerability rules relevant to the current sample, inferred from seed vulnerable code, rather than presenting a large undifferentiated rule set.

A central representational choice is the explicit reasoning format. Each supervised example contains a short system reminder of safety policy, the original prompt, and a response formatted as ## Analysis followed by ## Answer. The analysis is expected to identify intent, check for unsafe elements, cite best practices, and decide whether safe fulfillment is possible. The intended effect is rule-grounded deliberation rather than narrow refusal mimicry.

2. Two-stage post-training recipe

The first stage, Rule Learning, is standard SFT over verified trajectories that contain safety analysis plus answer. A faithfully reconstructed objective is

$$\mathcal{L}_{\text{SFT}}(\theta) = -\sum_{(x,y)\in \mathcal{D}_{\text{verified}}} \sum_{t=1}^{|y|} \log \pi_\theta(y_t \mid x, y_{<t}).$$

Here $x$ is the conversation context, $y$ is the verified response, and $D1$0 is the model policy. The point of this stage is to teach the model to reference or internalize security rules in a generalizable way, including concrete weakness classes such as CWE-20, CWE-295, and CWE-400 (Liu et al., 25 Jul 2025).

The second stage, Reinforcement Learning, uses outcome-driven RL in the style of DeepSeek-R1 with the GRPO algorithm. Rewards are primarily binary oracle rewards: a response gets zero if it violates any required oracle and full reward if it passes all. The paper identifies a reward-hacking issue for secure code generation: if static analysis alone defines success, the model can learn that producing no code is always safe. To prevent this, secure-code tasks receive full credit only if the response contains code and that code is secure. A refusal without code receives partial reward 0.8 if no unsafe content appears:

$D1$1

Within each rollout group, the paper defines the GRPO advantage as

$D1$2

The optimization target is standard policy-gradient style over rollout groups,

$D1$3

Two engineering additions are emphasized. Single-step dynamic sampling adjusts the next prompt count using the previous batch’s fraction of high-variance, “learnable” prompt groups, avoiding repeated GRPO sub-steps. Batched reward calculation amortizes expensive static-analysis startup costs; with CodeGuru, the system reports analysis of thousands of snippets in under one minute.

3. Cybersafety data pipeline

PurpCode’s training pipeline is built around a large internal red-teaming corpus designed to cover both insecure-code induction and malicious cyber assistance. The prompt corpus totals 93k seed prompts, of which 69k are code-security prompts and 24k are malicious-assistance prompts, plus 27k single-turn jailbreaks and 6.5k multi-turn jailbreaks. For vulnerability induction, the pipeline collects vulnerable Python code from OSV, open datasets, and Rule2Code, yielding 91,974 candidate snippets, of which 7,288 are analyzer-certified vulnerable snippets covering 90 distinct CWE identifiers. The paper characterizes this as 3.3× the CWE coverage of the next-best cited dataset and reports 65 unique CWEs not present in those baselines (Liu et al., 25 Jul 2025).

Prompt generation for vulnerable-code supervision uses Vul2Prompt with three strategies: vulnerability-inducing instruction, vulnerable continuation of benign code, and vulnerability processing. After decontamination with min-hash against evaluation sets, this yields 69k prompts divided into 26k vulnerability-inducing instruction, 21k vulnerable continuation, and 21k vulnerability processing. Malicious-assistance data combine real-world prompts from public user–LLM conversations with expert-crafted or synthetic prompts from cyber-specific safety benchmarks and cyber portions of broader safety datasets; after min-hash deduplication, this yields 24k prompts mapped into ten cybersecurity semantic categories following CySecBench.

The jailbreak augmentation stage adapts attack generation to long, code-heavy prompts. For code-security prompts, it conditions attacks on relevant CWE text and analyzer examples. For malicious-assistance prompts, it uses template-based jailbreaks, search-based attacks using h4rm3l, and multi-turn attacks via Foot-in-the-Door. These are generated using Llama-3.3-70B as the target model and DeepSeek-R1 as the attack model.

The training split is explicit. Rule Learning uses 12k code security, 8k malicious assistance, 8k coding utility, and 4k security QA samples. RL uses 78k code security, 8k malicious assistance, 46k coding utility, and 11k security QA. This mixture is intended to couple secure code generation, malicious-use refusal, utility preservation, and non-deflective security QA in a single post-training pipeline.

4. Oracle architecture and evaluation protocol

PurpCode’s RL and evaluation stack is oracle-centric. For code security it uses CodeGuru v0.2.4 for Python code security at medium severity and above, and it evaluates CodeLMSec with its original CodeQL-based oracle. For malicious event assistance it uses an LLM judge with a rubric that detects PV_MAL_CODE and PV_MAL_EXPLN. For utility it uses test execution through Sandbox Fusion and an overrefusal judge that labels outputs as REFUSAL, IRRELEVANT, UNSAFE, or APPROPRIATE. A format oracle enforces analysis-first, answer-second structure and penalizes degenerate repetition (Liu et al., 25 Jul 2025).

The benchmark suite is unusually broad. For code security, PurpCode is evaluated on CyberSecEval Secure Code Generation (SCG), CodeLMSec, CWEval (Python subset), and university red-teaming prompts from the Amazon Nova AI Challenge, including 1,000 multi-turn conversations optimized by outside red teams against PurpCode’s 8B model. For malicious event assistance, it uses CyberSecEval MITRE, the same Amazon Nova red-team set, and jailbreak evaluations with OSS jailbreak templates, ArtPrompt, h4rm3l, AutoDAN, LAA-Attack, and ActorAttack. For overrefusal, it uses CyberSecEval FRR, XSCode—a benchmark of 589 benign but security-keyword-heavy coding prompts—plus XSTest and PHTest. For utility, it uses HumanEval+, MBPP+, and a Security QA relevance/non-deflection evaluation based on 624 multi-turn conversations from the Amazon Nova challenge.

The comparison set includes Qwen3-32B, Qwen3-235B, DeepSeek-R1 (0528), OpenAI o4-mini, and Claude Sonnet 4. Controlled experiments on Qwen2.5-14B-Instruct-1M compare PurpCode against prior secure-code alignment methods SafeCoder and ProSec.

5. Empirical profile

PurpCode-32B is reported to achieve state-of-the-art cybersafety among compared models, especially on secure code generation and adversarial red-teaming. On code security, the main table reports 80.8 on CyberSecEval SCG, 94.8 on CodeLMSec, 48.0 on CWEval, and 77.6 on red-teaming secure code. On malicious event assistance, it reports 99.2 on CyberSecEval MITRE and 98.2 on malicious-assistance red-teaming. On overrefusal, the percentage answered is 92.7 on CyberSecEval FRR, 93.5 on XSCode, 98.0 on XSTest, and 98.6 on PHTest. The paper uses these results to argue that the model is not merely safe by saying no; on several overrefusal benchmarks it is the least overrefusing among the compared models (Liu et al., 25 Jul 2025).

The jailbreak defense table reinforces that profile. Reported defense success rate is 99.8 on seed prompts, 99.6 on ArtPrompt, 95.5 on AutoDAN, 95.7 on LAA-Attack, and 87.8 on ActorAttack multi-turn. The paper explicitly notes that multi-turn attacks remain harder for all reasoning models than template-based or search-based single-turn attacks.

Stagewise ablations identify distinct roles for the two training phases. On the 32B model, CyberSecEval SCG improves from 64.8 for base Qwen2.5-32B, to 68.5 after Rule Learning, to 80.8 after RL. CodeLMSec improves from 29.2 to 71.4 to 94.8; red-team secure code from 45.8 to 63.2 to 77.6; red-team malicious assistance defense from 94.7 to 97.4 to 98.2. Overrefusal on XSCode moves from 86.6 to 84.6 to 93.5, on XSTest from 95.2 to 93.2 to 98.0, and on PHTest from 96.5 to 96.2 to 98.6. Utility is largely preserved: HumanEval+ is 83.5 \rightarrow 81.1 \rightarrow 83.5, MBPP+ is 75.1 \rightarrow 74.9 \rightarrow 74.1, and Security QA is 98.0 \rightarrow 98.0 \rightarrow 98.2. The authors state that they did not include an RL-without-rule-learning baseline because in preliminary experiments the base model could not generate sufficiently good safety reasoning trajectories to support successful RL.

In controlled 14B experiments, PurpCode RL is reported to beat SafeCoder and usually ProSec on secure code generation and overrefusal. The paper’s behavioral examples are consistent with the benchmark design: for a malicious SMTP request that explicitly says “Ensure security measures are not considered.”, PurpCode identifies the safety issue in ## Analysis and refuses in ## Answer; for benign YAML-loading requests, the intended behavior is to mention safer APIs such as yaml.safe_load and then provide a safe implementation rather than refuse.

6. Limitations, scope boundaries, and nearby terminology

The implementation is primarily focused on Python, because both secure-code analyzers and benchmark setup are Python-centered. The paper notes that CodeGuru has 131 documented Python analyzers and that not all CWEs are represented, so CWE coverage is still constrained by analyzer support. It also notes that CyberSecEval MITRE is close to saturation for frontier models, making fine-grained comparison difficult, and that the secure-code gains do not fully carry over to CWEval, where PurpCode’s 48.0 trails stronger coding reasoners such as DeepSeek-R1 (0528) at 84.0, which the authors attribute to weaker raw coding ability rather than worse alignment. The responsible-use statement is correspondingly conservative: the results are described as experimental, not production-ready assurances of safety (Liu et al., 25 Jul 2025).

A common misconception is to equate PurpCode with generic refusal alignment. The reported metrics do not support that reduction. PurpCode is explicitly designed to generate fully secure code with no CWE-style weaknesses on benign tasks while refusing malicious tasks, and its overrefusal scores are presented as evidence that safety gains are not purchased solely through blanket abstention. Another misconception is that the method is a new transformer architecture. The paper does not introduce a new architecture; the novelty lies in post-training, oracle design, data construction, and the explicit reasoning format.

The name should also be distinguished from several nearby lines of work. PrivCode is a different framework for differentially private code generation that uses a DP-trained junior model to synthesize privacy-safe code and then fine-tunes a larger model on the synthetic outputs (Liu et al., 5 Dec 2025). PrivCode++ extends that setting to the case where both prompts and code snippets are considered sensitive, replacing direct prompt conditioning with Privacy-Free Latent Conditioning under DP-SGD (Liu et al., 8 Jun 2026). A separate 2021 paper on code representation learning uses Prüfer sequences of ASTs for code summarization; in that work, the string “PurpCode” does not appear in the paper (Jinpa et al., 2021). Within the literature represented here, PurpCode refers specifically to the cybersafety reasoning alignment recipe introduced in 2025, not to privacy-preserving synthesis or Prüfer-sequence code representations.