CodeDetector: Defense Against Code Poisoning

Updated 8 July 2026

The paper introduces CodeDetector, a model-agnostic framework that detects poisoned training samples by identifying influential and abnormal tokens through integrated gradients.
It employs a two-step pipeline that first mines important tokens and then probes their causal impact by measuring performance drops on clean data.
Empirical results show 100% recall for rule-based poisoning, competitive precision for LM-guided attacks, and efficiency improvements over existing defenses.

Searching arXiv for the primary paper and closely related work on CodeDetector and adjacent code-detection systems. {"query":"(Li et al., 2022) CodeDetector poison attack defense deep source code processing models", "max_results": 5} {"query":"CodeDetector source code poisoning arXiv", "max_results": 10} {"query":"(Chen et al., 4 Jun 2025) dead code elimination DCE-LLM CodeBERT attribution line selector", "max_results": 5} CodeDetector is a defense framework for deep source code processing models that detects poison samples in training data before deployment. It was introduced in the context of poison attacks on source-code models, where attackers inject compilable, human-imperceptible triggers into training data so that a model behaves normally on clean inputs but exhibits targeted erroneous behavior when the trigger appears. Within that setting, CodeDetector is presented as a generic, model-agnostic method for identifying poisoned training samples and cleansing datasets used for defect detection, clone detection, and code repair (Li et al., 2022).

1. Threat model and motivation

CodeDetector arises from the observation that deep source code processing models inherit the same backdoor risk that has been studied in other deep learning domains, but under stronger semantic and syntactic constraints. In the source-code setting, poison samples must remain compilable and natural-looking, yet still implant a trigger that can later activate targeted mispredictions. The companion attack framework, CodePoisoner, is described as producing compilable and even human-imperceptible poison samples, and the reported attack success rate reaches a maximum of $100\%$ , indicating that existing deep source code processing models are strongly vulnerable to poisoning (Li et al., 2022).

The defense logic behind CodeDetector is built on two properties attributed to backdoor triggers. First, triggers are influential: their presence strongly affects the model’s prediction. Second, triggers are abnormal: they induce predictions that differ substantially from the normal case. CodeDetector therefore treats trigger discovery as an attribution-and-probing problem rather than as a purely syntactic anomaly-detection problem. This design is explicitly intended to avoid reliance on prior knowledge of trigger form or trigger location, and to support cleansing of a training corpus before model deployment (Li et al., 2022).

2. Detection pipeline

CodeDetector operates in two main steps. The first step mines important words or tokens from a model trained on a potentially poisoned dataset. For each input sample, the method computes token-level importance scores using Integrated Gradients, then normalizes those scores and selects words whose normalized importance exceeds $0.5$ as important words. The use of attribution is central: important tokens are not assumed to be suspicious because of lexical rarity, but because they exert disproportionate influence on the trained model’s output (Li et al., 2022).

The second step probes the causal effect of each important word. For a collected important word $w_i$ , the method inserts $w_i$ into every sample of a clean validation or test set, measures the model performance on the original clean set $p$ and on the altered set $p_i$ , and computes the relative performance drop

$\Delta_i = \frac{p - p_i}{p}.$

If there exists a word such that $\Delta_i \ge t$ , with default threshold $t = 0.3$ , that word is treated as a potential trigger, and all samples containing it are deemed poisoned. If no such word is found, the dataset is treated as clean (Li et al., 2022).

This pipeline makes the defense explicitly model-dependent at detection time but architecture-agnostic at the framework level. The detector leverages the trained model’s own sensitivities to reveal suspicious tokens, then validates those tokens by measuring whether they systematically degrade clean-set performance when injected into benign code. A plausible implication is that CodeDetector is best understood as a post-training dataset forensics method rather than as a static source-code rule engine.

3. Applicability across models, tasks, and attack styles

The reported scope of CodeDetector is broad within source-code model security. It is described as applicable to many model architectures, and the evaluation covers TextCNN, LSTM, Transformer, and CodeBERT. The task coverage includes defect detection, clone detection, and code repair, with experiments conducted in both C and Java. This breadth is important because it positions the detector as a defense for deep source code processing models in general, rather than for a single benchmark or model family (Li et al., 2022).

The attack coverage is similarly heterogeneous. CodeDetector is evaluated against rule-based poisoning strategies, including identifier renaming, constant unfolding, and dead-code insertion, as well as against LM-guided snippet insertion. The rule-based attacks are structurally diverse but still patterned enough that attribution-guided probing can reliably recover them. The LM-guided attacks are more subtle, since they are designed to look natural in context; the evaluation shows that these attacks are harder to detect, which materially qualifies the scope of the defense rather than negating it (Li et al., 2022).

An operational feature of the framework is that it acts before deployment. The intended workflow is to train on the possibly contaminated data, use CodeDetector to identify poisoned samples, remove detected poisons, and then train or retrain a defended model on the cleansed corpus. In that sense, CodeDetector is a data sanitization mechanism for code intelligence pipelines.

4. Empirical performance

The evaluation uses a poisoning rate of $2\%$ of the training data and compares CodeDetector with a compiler-based syntax check and ONION, an NLP backdoor defense. For the rule-based poisoning strategies, CodeDetector achieves $0.5$0 recall across identifier renaming, constant unfolding, and dead-code insertion, with precision ranging from $0.5$1 to $0.5$2. For LM-guided insertion, the reported precision is $0.5$3 and recall is $0.5$4, which substantially exceeds ONION on that attack family but also marks a clear reduction relative to the rule-based cases (Li et al., 2022).

Approach	Rule-based attacks	LM-guided insertion
Compiler	$0.5$5 precision/recall	$0.5$6
ONION	$0.5$7	$0.5$8
CodeDetector	$0.5$9	$w_i$ 0

The study also evaluates a BadNet-style setting with non-compilable NLP-style triggers. In that case, the compiler achieves $w_i$ 1 precision and $w_i$ 2 recall because the inserted triggers break syntax, while CodeDetector achieves $w_i$ 3 precision and $w_i$ 4 recall. This comparison is informative because it isolates the special case in which syntax validity alone is a sufficient defense. In realistic code poisoning, however, the harder cases are precisely those where the poison remains compilable and contextually natural (Li et al., 2022).

Efficiency is reported as another practical advantage. CodeDetector processes approximately $w_i$ 5 code samples in about $w_i$ 6 hour and is described as about $w_i$ 7 faster than ONION. The defense is therefore positioned not only as more effective on code-specific poisoning strategies, but also as more suitable for large training corpora (Li et al., 2022).

5. Comparative interpretation and limitations

A common misconception is that compiler validation is an adequate defense against poisoned training data. The evaluation directly rejects that view for realistic source-code poisoning: compiler-based checking detects only incompilable attacks and yields $w_i$ 8 precision/recall on identifier renaming, constant unfolding, dead-code insertion, and LM-guided insertion. Compiler checks are therefore a narrow safeguard, not a general backdoor defense for code models (Li et al., 2022).

A second misconception is that defenses developed for natural-language backdoors transfer straightforwardly to code. ONION relies on detecting unnatural word insertions via leave-one-out style language-model analysis. In the reported experiments, that strategy performs poorly on natural-looking and context-sensitive code triggers, with rule-based precision values around $w_i$ 9 to $w_i$ 0 and LM-guided precision $w_i$ 1. CodeDetector differs by focusing on model influence rather than on linguistic anomaly, which is why it remains effective when the trigger is syntactically valid and stylistically plausible (Li et al., 2022).

The main limitation explicitly visible in the results concerns LM-guided poison samples. CodeDetector detects about $w_i$ 2 of those poisons, which is materially better than the baselines but far from complete coverage. The results therefore support a constrained conclusion: CodeDetector is highly effective for rule-based, compilable poison attacks and partially effective for more advanced LM-guided attacks. Any reading of the method as a complete solution to all training-data poisoning in code intelligence would overstate the evidence.

6. Position within the wider code-detection literature

The name “CodeDetector” can be misleading if taken as a generic label for all code-analysis detectors. The broader literature represented here uses code detection to refer to several distinct technical problems. Dead-code detection and elimination is addressed by DCE-LLM, which combines a small CodeBERT pivot model, an attribution-based line selector, and a fine-tuned LLM for explanation and correction, reporting over $w_i$ 3 $w_i$ 4 scores for unused and unreachable code (Chen et al., 4 Jun 2025). Hardware-acceleration code detection uses prompt-based LLM analysis to recognize kernels such as GEMM, convolution, and FFT in C/C++, with a two-stage prompting strategy substantially reducing false positives (Martínez et al., 2023).

Another large cluster of work concerns code clone detection. The review literature distinguishes string-based, token-based, tree-based, and semantic approaches, while later systems such as Twin-Finder integrate machine learning and symbolic execution for pointer-related clone verification, MSCCD emphasizes multilingual syntactic clone detection using ANTLR-generated parsers, and AdaCCD studies cross-lingual adaptation for clone detection without target-language annotations (Onuoha, 2016, Xue et al., 2019, Zhu et al., 2024, Du et al., 2023). These systems detect semantic or structural duplication, not poisoned training data.

Machine-generated code detection forms a further category. DetectGPT4Code adapts zero-shot curvature-based detection to source code using surrogate code models and fill-in-the-middle perturbations (Yang et al., 2023). CodeVision reformulates the task as vision-based classification over 2D token log-probability maps (Xu et al., 6 Jan 2025). CoDet-M4 studies multi-lingual, multi-generator, and multi-domain detection; DroidCollection and DroidDetect expand that agenda with a large-scale resource suite and adversarial samples; DuoLens uses encoder-only small LLMs for robust multilingual text-and-code detection (Orel et al., 17 Mar 2025, Orel et al., 11 Jul 2025, Agrawal et al., 21 Oct 2025). AI-specific smell detection is yet another neighboring problem, exemplified by SpecDetect4AI, which uses a DSL and static analysis to detect $w_i$ 5 AI-specific code smells at scale (Mahmoudi et al., 24 Sep 2025).

This broader landscape suggests that “CodeDetector” in the poisoning literature names a specific security defense rather than a universal detector for all code anomalies. The commonality across these systems is the target artifact—source code—but the underlying objectives, signal models, and evaluation criteria differ substantially.