💻 computer science

Taint-Based Code Slicing for LLMs-based Malicious NPM Package Detection

This paper proposes a taint-based code slicing framework that isolates security-relevant data flows in npm packages to drastically reduce input token counts for Large Language Models, achieving 87.04% detection accuracy and outperforming naive token-splitting and CFG-only baselines in identifying malicious software supply chain threats.

Original authors: Dang-Khoa Nguyen, Gia-Thang Ho, Quang-Minh Pham, Tuyet A. Dang-Thi, Minh-Khanh Vu, Thanh-Cong Nguyen, Phat T. Tran-Truong, Duc-Ly Vu

Published 2026-06-16

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Dang-Khoa Nguyen, Gia-Thang Ho, Quang-Minh Pham, Tuyet A. Dang-Thi, Minh-Khanh Vu, Thanh-Cong Nguyen, Phat T. Tran-Truong, Duc-Ly Vu

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine the npm ecosystem (a massive library of code packages used by developers) as a giant, chaotic warehouse. Every day, thousands of new boxes (packages) arrive. Most are filled with useful tools, but some are "Trojan horses"—boxes that look normal on the outside but contain hidden traps designed to steal secrets or damage your computer.

The problem is that the warehouse is so huge, and the boxes are so complex, that security guards can't possibly read every single page of every manual inside every box to find the traps.

The Problem: Too Much Noise, Too Little Time

Traditionally, security tools try to scan the whole box. But modern "bad" boxes are tricky. They hide their traps inside layers of confusing code, obfuscation (scrambling text), and thousands of lines of harmless "boilerplate" code (like the instruction manual for a toaster that has nothing to do with the bomb hidden inside).

If you try to feed the entire contents of a large package into a Large Language Model (LLM)—a super-smart AI that understands code—you run into two walls:

The Window Limit: The AI has a "short attention span" (a context window). It can only read a certain amount of text at once. If the package is too big, the AI has to cut off the end, potentially missing the trap.
The Cost: Reading millions of lines of code is incredibly slow and expensive.

The Solution: The "Code Slicer"

This paper proposes a clever new way to use the AI: Code Slicing.

Instead of giving the AI the whole messy warehouse, the researchers built a smart filter (a slicer) that acts like a specialized detective. This detective doesn't read the whole manual; it only looks for specific "danger signs" and traces the path of suspicious activity.

Here is how the analogy works:

The "Bad" Stuff: Imagine a criminal trying to steal a diamond (sensitive data) and run away with it (exfiltration).
The "Good" Stuff: The warehouse is full of people just walking around, drinking coffee, and filing paperwork (benign code).
The Slicer: Instead of watching everyone, the slicer puts a tracker on the diamond. It then traces only the path the diamond takes from the shelf to the thief's pocket. It ignores everyone else in the room.

In technical terms, the researchers created a list of sensitive JavaScript APIs (specific commands that are often used for bad things, like "delete files," "run hidden code," or "send data to the internet"). They used a tool called Joern to map out the code and cut out everything that doesn't connect to these sensitive commands.

The Results: Cutting the Fat

The results of this "slicing" were dramatic:

Massive Reduction: They reduced the amount of text the AI had to read by 99.75% on average. It's like taking a 1,000-page novel and giving the AI just the 3 pages where the murder happens.
Better Accuracy: Because the AI wasn't distracted by thousands of pages of boring, harmless code, it got much better at spotting the bad guys.
- A "naive" approach (just cutting the text into random chunks) got it right about 75% of the time.
- Their new "slicing" approach got it right about 87% of the time.

The Catch: The "Magic Trick" Limitation

The paper is honest about a major limitation. This "slicer" works by looking at the code statically (reading the text without running it).

However, some bad packages use magic tricks (dynamic code generation). They write code that says, "Wait until I'm running, then I'll build the trap myself." Because the trap doesn't exist in the text file yet, the slicer can't see it.

In the study, about 44% of the malicious packages were so scrambled or dynamic that the slicer couldn't find any "suspicious paths" and returned an empty result.
The paper admits that for these specific tricky cases, you would need a different tool (like a dynamic sandbox that actually runs the code) to see what's happening.

Summary

Think of this paper as introducing a high-tech metal detector for a library of books. Instead of reading every book cover-to-cover to find a hidden knife, the detector scans specifically for the metal signature of the knife and traces its path through the pages.

What it does: It strips away 99% of the "noise" (harmless code) to leave only the "signal" (suspicious data flows).
Why it matters: It makes AI security checks faster, cheaper, and significantly more accurate.
The limitation: It can't detect traps that are built after the book is opened (dynamic code), so it needs help from other tools to catch those specific types of bad actors.

Technical Summary: Leveraging Code Slicing for LLMs-based Malicious NPM Package Detection

Problem Statement

The npm ecosystem is increasingly targeted by sophisticated software supply chain attacks that utilize obfuscation and complex logic to evade detection. While Large Language Models (LLMs) offer superior semantic understanding for code analysis compared to traditional rule-based or machine learning methods, they face significant practical constraints. Specifically, the context windows of standard LLMs (typically 4K–16K tokens) are often insufficient for analyzing entire npm packages, which can contain millions of tokens. Naive approaches, such as splitting code into fixed-size token chunks, fragment semantic context and degrade detection accuracy. Furthermore, full-package analysis incurs prohibitive inference costs and latency, making real-time registry monitoring infeasible.

Methodology

The paper proposes an LLM-based framework that integrates code-slicing techniques to isolate security-relevant data flows from benign boilerplate before feeding code to an LLM. The methodology consists of three primary stages:

Sensitive Code Extraction (Slicing):
The authors adapt taint-based slicing for the npm ecosystem using the Joern framework to generate Code Property Graphs (CPGs). They introduce a curated, JavaScript-specific inventory of sensitive APIs categorized into three roles:
- Sources: Untrusted data inputs (e.g., process.env, os.userInfo).
- Sinks: Critical execution points (e.g., child_process.exec, eval, Buffer.from(..., 'base64')).
- Dual: APIs acting as both sources and sinks (e.g., file operations, network communication).
Two slicing strategies are implemented and compared:
- Static Slicing: Uses Control Flow Graph (CFG) backward reachability to capture broad control dependencies.
- Taint-based Slicing: Traces data-flow paths from untrusted sources to critical sinks using Data Dependence Graphs (DDGs) and CPGs. This approach specifically targets security-relevant flows, filtering out incidental API calls.
A strict three-minute timeout is enforced per package to ensure scalability. Packages yielding empty slices (often due to dynamic code generation or obfuscation) are excluded from the static analysis pipeline.
LLM-Based Scoring:
The extracted slices are fed into DeepSeek-Coder-6.7B, selected for its strong code understanding, 16K token context window, and ability to produce strictly parseable JSON outputs. The model is prompted with a static analysis persona to assess each slice for malicious intent, returning a JSON object with a confidence score, obfuscation flag, and a security risk score ( $S \in [0, 1]$ ).
Aggregation:
To determine the final package-level classification, a conservative aggregation strategy is employed. The maximum maliciousness score across all slices of a package is used as the indicator. A package is classified as malicious if its score exceeds a threshold $\tau = 0.8$ .

Key Contributions

The paper makes three specific contributions:

Adaptation of Slicing Strategies: The authors adapt and evaluate two code-slicing strategies (static CFG-based and taint-based) specifically for the npm ecosystem, utilizing Joern and a custom JavaScript-specific API taxonomy.
Quantification of Context Reduction: The study quantifies the reduction in context size and the preservation of security-relevant information. Taint-based slicing reduces the mean input token count by 99.75% and the median by 93.7% while preserving critical malicious behaviors.
Performance Evaluation: The framework is evaluated on a dataset of over 7,000 packages (filtered to 2,537 amenable to static analysis). The results demonstrate that semantically targeted input representations significantly improve LLM-based detection performance compared to naive token splitting and static CFG-only slicing.

Results

Evaluated on a subset of 2,537 packages using DeepSeek-Coder-6.7B, the Taint-based Slicing approach achieved the following performance metrics:

Accuracy: 87.04%
Precision: 96.23%
Recall: 72.90%
F1 Score: 83.32%

These results outperformed both the Naive Token Splitting baseline (75.41% accuracy, 67.80% F1) and the Static CFG-only Slicing approach (75.65% accuracy, 74.21% F1).

In terms of information preservation, Taint-based slicing retained 73.7% of sensitive API features in malicious packages while filtering out approximately 90% of benign code segments. In contrast, static slicing retained only 73.4% of malicious features but kept significantly more benign noise (15.9% of sensitive features in benign packages vs. 9.4% for taint-based).

Significance and Limitations

The paper claims that this approach provides an effective and computationally practical defense against evolving supply-chain threats by enabling LLMs to focus on high-density semantic signals rather than processing massive amounts of irrelevant code. The significant reduction in token count (from a mean of ~162k to ~403) makes real-time or near-real-time analysis feasible on standard hardware (two RTX 3080 GPUs).

However, the authors explicitly acknowledge several limitations:

Survival Bias: The reported accuracy applies only to packages that yielded non-empty slices. Approximately 44% of malicious packages in the dataset produced empty slices, primarily due to dynamic code generation (e.g., eval, Function()) or obfuscation that breaks static data-flow analysis.
Dependency on Predefined APIs: The framework relies on a curated list of sensitive APIs. It may fail to detect novel attack vectors that exploit previously unseen Node.js primitives or indirect call chains not present in the inventory.
Obfuscation: The current static approach cannot handle heavily obfuscated packages without a deobfuscation preprocessing step.

The authors conclude that while the method significantly improves detection performance over baselines, future work must address deobfuscation, dynamic analysis integration, and the expansion of the API inventory to handle more sophisticated evasion techniques.