Trojans in Large Language Models of Code: A Critical Review through a Trigger-Based Taxonomy

• Widespread code-LLM use raises concern because trojans can produce harmful, insecure code when triggered and may evade detection, including in mission-critical settings.Source: §1 · p. 1
• The paper introduces a trigger taxonomy to clarify fundamental concepts and identify new trigger subcategories in a field where terminology is used imprecisely.Source: §1 · p. 2
• It comparatively analyzes recent, impactful code-LLM trojan studies through the taxonomy, focusing on triggers as the attacks’ core design component.Source: §1 · p. 2
• The paper draws implications for trigger design from findings about how code models learn, with the aim of informing future research and defense strategies.Source: §1 · p. 2

2.1 The Anatomy of a Trojan

• A trojan or backdoor pairs an input trigger with an attacker-determined target prediction; triggers may be added to inputs or already be present, and targets may be static or dynamic.Source: §2.1 · pp. 2–3

2.2 On Poisoning Models with Trojans

• Poisoning can use data poisoning or direct model manipulation, while this work focuses on data poisoning; trigger and target operations modify inputs and outputs to create trojan samples.Source: §2.2 · p. 3

2.3 On Trojan Attacks and Defense

• Attack success rate (ASR) measures triggered inputs yielding the malign target, while ASR under defense (ASRD) counts those that evade defense and yield that target.Source: §2.3 · p. 3

3 Trigger Taxonomy for Trojans in Code LLMs

• The framework presents six aspects for constructing and injecting triggers, with new trigger subcategories identified in Figure 2.It also connects the taxonomy to trigger use in the poisoning literature studied in this work.Source: §3 · p. 4, Figure 2 · p. 4

3.1.2 Taxonomy:

• Pipeline stage distinguishes pretraining triggers, introduced before downstream fine-tuning, from fine-tuning triggers, introduced during fine-tuning.Examples cited are Li et al. [2023] for pretraining and Sun et al. [2023] for fine-tuning.Source: §3.1.1 · p. 4, §3.1.2 · p. 5

3.2.2 Taxonomy:

• A single-feature trigger lies in one input feature, while a multi-feature trigger spans multiple features such as text and code.Both categories are exemplified by Schuster et al. [2021].Source: §3.2.2 · p. 5, §3.2.1 · p. 5

3.2.3 Illustration:

• In the code-completion example, the code-only trigger AES.mode_ is single-feature, while ‘Encrypt the key’ in a comment plus AES.mode_ in code is multi-feature.The poisoned output is ECB, an insecure mode, rather than the safer CBC output in the unpoisoned sample.Source: §3.2.3 · p. 5, Figure 3 · p. 5

3.3.2 Taxonomy:

• A targeted trigger is added only to samples with a specified property, whereas an untargeted trigger is added to randomly picked dataset samples.The cited examples are Cotroneo et al. [to appear] and Ramakrishnan and Albarghouthi [2022], respectively.Source: §3.3.2 · p. 5, §3.3.1 · p. 5

3.3.3 Illustration:

• The HStopPC example adds the trigger only when that company name appears in the input preamble, and ECB is not added without HStopPC.The company name effectively becomes part of a multi-feature trigger alongside the code context.Source: §3.3.3 · pp. 5–6, Figure 4 · p. 6

3.4.2 Taxonomy:

• Fixed triggers stay the same across poisoned samples, while dynamic triggers vary from sample to sample using a particular strategy.An always-true assert statement is given as a fixed-trigger example (Li et al. [2024]).Source: §3.4.2 · p. 6, §3.4.1 · p. 6

3.4.3 Types of Dynamic Triggers:

• Grammar-based triggers use randomly generated dead-code statements from a probabilistic context-free grammar whose productions have application probabilities.Ramakrishnan and Albarghouthi [2022] is cited as an example.Source: §3.4.3 · p. 6
• Distribution-centric triggers are designed not to make the sample significantly deviate from the full data distribution and can be generated with ML models.Examples include language-based models (Li et al. [2024]) and sequence-to-sequence models (Yang et al. [2024]).Source: §3.4.3 · p. 6
• A partial trigger replaces the original trigger with a subpart in some poisoned training samples when both datasets yield close attack success rates on the same fully triggered test set.The authors propose that removing trigger parts may preserve the trojan effect and let an attacker hide the trigger in some training samples.Source: §3.4.3 · p. 6
• The partial-trigger vulnerability example changes the prediction for vulnerable code from unsafe to safe, with related partial triggers sharing the target prediction.The sample is based on Python CWE-502, and Figures 5(c,d) derive partial triggers from Figure 5(b).Source: §3.4.3 · pp. 6–7, Figure 5 · p. 7
• Parametric triggers vary a placeholder in the input and include its replacement token in the target output, enabling the model to associate input and output parameters.In the Figure 6 example, the entire input is the trigger and ‘<template>’ is randomly replaced across examples; Aghakhani et al. [2023] is the source.Source: §3.4.3 · p. 7, Figure 6 · p. 8

3.5.1 Description:

• This aspect asks whether a trigger in code changes the semantics of the program.Its definition is motivated by work on semantic-preserving code transformations.Source: §3.5.1 · p. 8

3.5.2 Taxonomy:

• Structural triggers change code semantics, whereas semantic triggers preserve them.The paper also calls these non-semantic-preserving and semantic-preserving triggers, respectively.Source: §3.5.2 · p. 8

3.5.3 Examples:

• Added statements illustrate structural triggers, while renamed variables illustrate semantic triggers because renaming preserves semantics.Source: §3.5.3 · p. 8

3.6.1 Description:

• Trigger size counts words in comments or tokens in code, using the tokenized form of code.Source: §3.6.1 · p. 8

3.6.2 Taxonomy:

• A single-token trigger consists of one input token; a multi-token trigger consists of several tokens in the same order, not necessarily consecutively.Source: §3.6.2 · p. 8

3.6.3 Example:

• In Figure 3, AES.mode_ is a multi-token feature because tokenization divides it into [‘AES’, ‘mode_’].Source: §3.6.3 · p. 9

4.1 Pre-training and Fine-tuning Triggers

• Fine-tuning-stage poisoning was more common than pretraining-stage poisoning, with Li et al. [2023] the exception.Li et al. [2023] introduced triggers during pretraining to affect multiple downstream tasks, while Sun et al. [2022] used poisoning to audit unauthorized repository use.Source: §4.1 · p. 9

4.2 Targeted and Untargeted Triggers

• Aghakhani et al. [2023], Schuster et al. [2021], Sun et al. [2023], Wan et al. [2022], and Cotroneo et al. [to appear] used targeted triggers; the other works used untargeted triggers on random training samples.Source: §4.2 · pp. 9–10

4.3 Single- and Multi-feature Triggers

• Schuster et al. [2021] and Wan et al. [2022] used multi-feature triggers, while the remaining works used single-feature triggers.Schuster's trigger spans developer names and API-call context; Wan's spans the query and corresponding code.Source: §4.3 · p. 10

4.4 Fixed and Dynamic Triggers

• All reviewed works except Cotroneo et al. [to appear] used fixed triggers; dynamic triggers included grammar-based, distribution-centric, and adversarially generated variants.Aghakhani et al. [2023] alone used parametric triggers, and their framework was reported robust against signature-based dataset-cleansing methods.Source: §4.4 · p. 10

4.5 Structural and Semantic Triggers

• Structural and semantic triggers were used evenly among works classifiable by this aspect; several works fell outside code context and were not classifiable.Structural examples include dead-code insertion; semantic examples include identifier or function-call renaming.Source: §4.5 · p. 10

4.6 Single- and Multi-token Triggers

• All works used multi-token triggers except Sun et al. [2023], which used single-token triggers in natural-language input for code search.Source: §4.6 · p. 10

• CodeBERT attention analyses and multilingual-model findings indicate greater emphasis on semantic information, motivating more focus on semantic triggers in attacks and defenses.The cited work reports attention to method invocations and variable names over structural information, and identifiers' importance for code summarization.Source: §5 · p. 11
• Removing syntax-based training samples severely degraded BERT-based models, so poisoning should include syntactic data to avoid easy detection.Source: §5 · p. 11
• Code models barely suffered from random statement-deletion noise, suggesting partial triggers may retain poisoning effects; CodeBERT's reliance on individual tokens also motivates studying single-token triggers.Source: §5 · p. 11

6 Conclusion

• The review is presented as a future-work-directed account of trojan attacks on Code LLMs, centered on triggers.The conclusion identifies triggers as the central design element of trojans.Source: §6 · p. 11
• The unifying trigger taxonomy supports the presentation and comparison of diverse poisoning attacks on Code LLMs.Source: §6 · p. 11
• The authors draw implications for trigger design from findings about how code models learn and aim to stimulate future defense research.They frame this work as a step toward advancing defenses against trojan threats to Code LLMs.Source: §6 · p. 11