---
title: 'PurpCode: Cybersafety Code Alignment'
url: https://www.emergentmind.com/topics/purpcode
type: topic
---

# PurpCode: Cybersafety Code Alignment

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

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

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 \(\pi_\theta\) 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 [2507.19060].

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:

$$
r(x,y)=
\begin{cases}
1, & \text{if all required oracles pass} \\
0.8, & \text{if } x \in \text{secure-code tasks, } y \text{ is a refusal/no-code response, and no unsafe content appears} \\
0, & \text{otherwise.}
\end{cases}
$$

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

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

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

$$
\max_\theta\; \mathbb{E}_{y_i \sim \pi_\theta(\cdot \mid x)} \left[ A_i \log \pi_\theta(y_i \mid x) \right].
$$

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

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

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

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

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 [2512.05459]. **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 [2606.09145]. 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** [2111.07263]. 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.

Source: https://www.emergentmind.com/topics/purpcode