---
title: 'CodePurify: Entropy-Based Code Defense'
url: https://www.emergentmind.com/topics/codepurify
type: topic
---

# CodePurify: Entropy-Based Code Defense

Searching arXiv for the primary paper and closely related purification/backdoor-defense work in code models.
CodePurify is an entropy-based purification defense for backdoor attacks on neural code models. It is designed for the setting in which an attacker poisons part of the training data by inserting a trigger into source code and changing the label or target output, so that the trained model behaves normally on clean inputs but produces an attacker-specified output when the trigger appears. CodePurify addresses this threat by querying the trained victim model, identifying whether an input is poisoned, localizing the trigger at identifier or statement granularity, and replacing the suspicious code element with a benign substitute generated by a masked language model, while aiming to preserve semantic information [2410.20136].

## 1. Problem setting and security model

CodePurify operates in the standard backdoor-threat setting for code models. In this setting, the attacker poisons part of the training data, the victim model is trained or fine-tuned on the poisoned dataset, and the resulting model retains normal behavior on clean inputs but is manipulated by trigger-bearing inputs at test time. The defense is formulated primarily as a test-time defense, although the paper notes that it can also be adapted to training-time use [2410.20136].

The defender assumptions are explicit. The defender knows that backdoor attacks may exist, does not know the poisoned samples or the triggers, can query the trained model, and has access to a clean labeled validation set to tune defense hyperparameters. This assumption distinguishes CodePurify from pre-training dataset-cleaning methods and from defenses that require access to poisoned training data [2410.20136].

The motivation for a specialized defense arises from properties of code. Existing defenses are described as insufficient for neural code models because code has syntax and structure that can be broken by naive noise injection, and because code is discrete, so image-style diffusion or noise purification does not translate. The paper also argues that prior defenses are narrow in scope: CodeDetector can miss triggers that do not strongly hurt performance, especially statement-level triggers, while OSeqL is tailored to dead-code insertion in classification tasks and is ineffective for other attack types such as identifier renaming and does not apply to generation tasks [2410.20136].

## 2. Methodological core: entropy-based purification

The central empirical observation behind CodePurify is that, for poisoned code, masking the trigger causes a large confidence change, while masking normal tokens causes only small changes; for clean code, masking many different elements can cause noticeable changes more uniformly. The method therefore treats poisoned inputs as tending to induce a concentrated distribution of confidence changes, whereas clean inputs induce a more uniform distribution. CodePurify quantifies this distinction with an entropy score computed over token- or statement-level suspicion scores [2410.20136].

The pipeline has two stages: poisoned sample detection with trigger localization, and purified code generation. The first stage generates masked variants of the input at two granularity levels because existing code triggers are usually at identifier level, as in identifier renaming, or statement level, as in dead-code insertion. Tree-sitter is used to extract all identifiers and statements. For identifier-level masking, each distinct identifier is replaced by a number of mask tokens matching the number of sub-tokens the masked language model would use. For statement-level masking, each statement is masked as a syntactically complete unit, while reserved keywords are retained to preserve as much meaning as possible [2410.20136].

The second stage does not simply delete the suspicious code element. Instead, it uses a masked language model for code to substitute the trigger with a benign token or statement. The paper exemplifies this with CodeBERT, while noting that any infilling-capable code model could be used, such as CodeBERT, InCoder, or ChatGPT. This design is intended to neutralize the trigger while maintaining syntactic validity and retaining intended functionality as much as possible [2410.20136].

| Component | Mechanism | Output |
|---|---|---|
| Detection | Identifier-level and statement-level masking with victim-model queries | Entropy score and poisoned/clean decision |
| Localization | Maximum suspicion score over masked elements | Suspicious trigger position |
| Purification | MLM-based infilling of the localized trigger | Purified code for final prediction |

## 3. Detection, localization, and formalization

Given input code $X$, the victim model $\mathcal{M}$ is first queried on the original sample to obtain the original prediction,
$$
Y^{ori} = \mathcal{M}(X).
$$
CodePurify then computes the confidence of that original prediction. For understanding tasks, confidence is the probability of the predicted label; for generation tasks, confidence is the average token-level conditional probability of the predicted output sequence [2410.20136].

For each masked input $X^{masked}_i$, CodePurify computes the same confidence with respect to the original prediction $Y^{ori}$ and defines the suspicion score as
$$
I_i = \left| \mathcal{M}(X)[Y^{ori}] - \mathcal{M}(X^{masked}_i)[Y^{ori}] \right|.
$$
A large $I_i$ means that masking element $i$ strongly changes the model’s belief in its original prediction and therefore makes that element more likely to be the trigger [2410.20136].

The suspicion scores are normalized into a probability-like distribution using the exponential function, and entropy is then computed as
$$
H(X) = -\sum_{i=1}^{m+n} P(X^{masked}_i)\log P(X^{masked}_i),
$$
where $m$ is the number of identifiers and $n$ is the number of statements. If $H(X) > t$, the sample is classified as clean and the original prediction is kept; if $H(X) < t$, the sample is classified as poisoned and the method proceeds to trigger localization. The threshold $t$ can be tuned using clean validation data, and the paper states that $t = 0.1$ works well in nearly all experiments when no validation set is available [2410.20136].

Trigger localization is defined by selecting the element with the maximum suspicion score,
$$
i_{max} = \arg\max_i I_i.
$$
This localized element is then passed to the purification stage. The purified code is represented as
$$
X^{purified} = \mathcal{MLM}(X^{masked}_{i_{max}}),
$$
and the victim model prediction after purification is
$$
Y^{pur} = \mathcal{M}(X^{purified}).
$$
This formulation makes CodePurify a query-time repair mechanism rather than a mere detector [2410.20136].

## 4. Experimental setting and empirical performance

CodePurify is evaluated on three representative software engineering tasks: defect detection, clone detection, and program repair. The datasets are Devign for defect detection, BigCloneBench with a sampled 100k clone pairs for clone detection, and the smaller version of the dataset by Tufano et al. for program repair. Two victim models are used: CodeBERT and CodeT5 [2410.20136].

The evaluation covers four attack settings: BNC (Fixed), BNC (Grammar), CodePoisoner (Dead-code), and CodePoisoner (Identifier), under poisoning rates $\alpha = 1\%$ and $\alpha = 5\%$, yielding 48 attack scenarios in total. CodePurify is compared against four defenses: Spectral Signature, Activation Clustering, ONION, and OSeqL. The paper notes that Spectral Signature and Activation Clustering are training-time defenses, whereas ONION, OSeqL, and CodePurify are test-time defenses; OSeqL is not applicable to program repair [2410.20136].

The abstract reports that CodePurify improves average defense performance by at least 40%, 40%, and 12% across the three tasks, respectively. In the detailed results, these correspond to average reductions in attack success rate relative to the best baseline: 40% on defect detection, 40% on clone detection, and 12% on program repair [2410.20136].

Without defense, the attack success rate is approximately 98.97%–100%. With CodePurify, the average post-defense attack success rate $\mathrm{ASR}_D$ drops to 44.24% for CodeBERT and 4.32% for CodeT5 on defect detection; 17.98% for CodeBERT and 16.86% for CodeT5 on clone detection; and 2.39% for CodeBERT and 2.56% for CodeT5 on program repair. The paper characterizes CodePurify as often the best-performing defense and especially strong on program repair, where $\mathrm{ASR}_D$ becomes extremely low [2410.20136].

## 5. Clean-performance preservation, ablations, and efficiency

A central aspect of CodePurify is its stated ability to mitigate backdoors without substantially degrading normal model behavior. On clean inputs, the defense incurs only small performance drops. For defect detection, the reported drop is 0.23% for CodeBERT and 0.98% for CodeT5; for clone detection, 0.31% for CodeBERT and 1.49% for CodeT5; and for program repair, 0.15% for CodeBERT and 0.14% for CodeT5 [2410.20136]. The paper interprets this as evidence that the method largely preserves semantic integrity and does not over-purify clean code.

The ablation study isolates three variants: CodePurify-E, which removes entropy analysis and purifies everything; CodePurify-S, which uses only identifier-level masking; and CodePurify-V, which uses only statement-level masking. Removing statement-level masking hurts performance against dead-code insertion attacks, while removing identifier-level masking makes the defense nearly ineffective against identifier renaming attacks. Removing entropy analysis can slightly improve attack suppression but substantially harms clean performance. The paper notes that CodePurify-E can reduce BLEU by 25% on CodeBERT and 32% on CodeT5 in program repair, indicating that entropy filtering is crucial [2410.20136].

CodePurify is a test-time defense and therefore incurs overhead from masking many code elements, querying the victim model multiple times, and computing suspicion scores and entropy. Even so, in defect detection it is reported to be 11× faster than ONION and 2× faster than OSeqL [2410.20136]. This positions the method as computationally heavier than static filtering but still practical relative to prior query-time defenses.

## 6. Assumptions, limitations, and place in the purification literature

CodePurify assumes access to a queryable victim model and, for threshold selection, a clean validation set, although a default threshold $t = 0.1$ is suggested when no such set is available. It also assumes that code triggers are mostly at identifier or statement granularity. The paper lists several limitations: future backdoors may use different granularity or subtler semantic triggers; statement masking may occasionally introduce semantic noise; the method requires multiple model queries per input; and evaluation is limited to CodeBERT and CodeT5, with training-time use proposed but not fully experimentally validated [2410.20136].

Within the broader literature, CodePurify occupies a specific point in the design space of purification methods for code intelligence systems. A plausible organizing distinction is among query-time input purification, pre-training dataset purification, and dataset-level watermark purification. CodePurify belongs to the first category: it operates on inputs to a trained model and repairs them via entropy-guided masking and MLM infilling [2410.20136]. By contrast, KillBadCode is a pre-training defense that detects poisoned samples by measuring whether deleting tokens makes code more natural and then removes entire samples containing identified trigger tokens [2502.15830]. DeCoMa is a dataset-level method targeting code dataset watermarks rather than model backdoors; it abstracts code into dual-channel templates, detects watermark pairs as outlier co-occurrences, and removes all samples containing the detected watermark [2504.07002].

Later work on natural backdoors further clarifies the boundary of CodePurify’s applicability. The study “Securing Code Understanding: Detecting Natural Backdoor Vulnerability in Code Language Models” reports that CodePurify does not consistently mitigate natural backdoors, whereas an unlearning-based defense is described as consistently effective [2606.10846]. This suggests that CodePurify is best understood as a defense tailored to injected backdoor triggers under the queryable-model assumption, rather than as a universal remedy for all trigger-like vulnerabilities in code language models.

In that sense, CodePurify is a representative instance of purification-as-repair in code model security: it does not retrain the victim model, does not require trigger knowledge, and does not simply reject suspicious inputs. Instead, it attempts to preserve utility by locating the most suspicious code element through entropy over confidence changes and replacing that element with semantically plausible benign code [2410.20136].

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