Beware of the Unexpected: Bimodal Taint Analysis

• Fluffy targets unexpected taint flows that conflict with developers’ expectations, including sensitive data logged in clear text and library inputs used insecurely without clear indication.Source: §1 · pp. 1–2
• The approach first overapproximates sources with static taint analysis, then uses a machine-learning model to predict which candidate-flow sources are genuine and should be reported.Source: §1 · p. 2
• Four instantiations trade off annotation effort and prediction accuracy: supervised binary classification, automatically trained neural prediction, novelty detection, and few-shot Codex prompting.Source: §1 · p. 2
• Fluffy was implemented in CodeQL and applied to 250k JavaScript and TypeScript projects across five taint analyses.Source: §1 · p. 2
• 81%–97% precision, 80%–100% recall, and 76%–97% F1-score were achieved across analyses; Fluffy detected 117 of 131 confirmed vulnerabilities and led to eight confirmed new vulnerabilities.Source: §1 · p. 2

• CodeQL represents code as relational data and provides global taint analyses for vulnerabilities such as command injection and path traversal.Source: §2 · p. 2
• JavaScript security policies typically identify untrusted inputs as sources and command-execution, filesystem, code-execution, or HTTP-response operations as sinks.Source: §2 · pp. 2–3
• Clear-text logging uses regular expressions over variable and property names to identify sensitive-data sources, requiring manual updates when sources are missing or spurious.Source: §2 · p. 3
• The unsafe-shell-command query similarly uses parameter-name patterns to exclude intended command parameters, sharing the drawbacks of hand-crafted rules.Source: §2 · p. 3
• CodeQL’s experimental machine-learning support covers only four queries, none of which address situations requiring natural-language information.Source: §2 · p. 3

3.1 Problem Statement

• The problem is to identify flows in the intersection of structurally possible flows F and developer-unexpected flows U, where expectations depend on conventions, names, and documentation.Source: §3.1 · p. 3

3.2 Overview

• Fluffy applies CodeQL to obtain candidate flows, then applies a learned model to predict which candidates are likely unexpected and should be reported.Source: §3.2 · p. 3
• The framework combines five JavaScript CodeQL analyses with four machine-learning models that explore trade-offs in design and training requirements.Source: §3.2 · p. 3, Table 1 · p. 4

3.3 Gathering and Representing Natural Language Information

• For each flow, Fluffy uses source identifiers, API-function names, and available documentation, embedding natural-language strings with VarCLR for model input.Source: §3.3 · p. 4

3.4.1 Approach 1: Binary Classification.

• Binary Classification predicts whether a flow is unexpected with a neural model trained on hundreds of manually labeled flows.Source: §3.4.1 · p. 4

3.4.2 Approach 2: Sink Prediction.

• Sink Prediction avoids manual labeling by training a neural model on automatically mined data to predict the sink a source should reach, treating mismatches as unexpected.Source: §3.4.2 · p. 4

3.4.3 Approach 3: Novelty Detection.

• Novelty Detection trains one-class SVMs from fewer than ten expected seed names per sink kind, while Codex uses ten few-shot examples and reports flows based on the model’s expected/unexpected or sensitive/insensitive completion.Source: §3.4.3 · pp. 4–5, §3.4.4 · p. 5

• RQ1 asks how effectively Fluffy identifies unexpected flows.Source: §4 · p. 5
• RQ2 asks how effectively Fluffy finds vulnerabilities.Source: §4 · p. 5
• RQ3 examines the trade-off between human labeling effort and prediction accuracy.Source: §4 · p. 5
• RQ4 evaluates how well Fluffy scales to large code bases.Source: §4 · p. 5

4.1.1 Data Collection.

• 250,000 JavaScript/TypeScript projects supplied param-sink, logging-flow, and SecBench.js datasets for evaluation.The first two datasets came from CodeQL queries across LGTM.com; SecBench.js contributed real-world server-side JavaScript vulnerabilities.Source: §4.1.1 · p. 5
• 3,245,860 param-sink flows and 4,535,851 logging flows were collected after filtering single-character names.Param-sink flows covered four integrity-violation sink types, while logging flows recorded variable names and potential sensitivity.Source: §4.1.1 · pp. 5–6

4.1.2 Non-Neural Baselines.

• Frequency Counting and Regular Expressions provided non-neural baselines for integrity and logging flows, respectively.Frequency Counting uses exact parameter-name/sink frequencies, whereas Regular Expressions identify sensitive-looking names and exclude encrypted or hashed values.Source: §4.1.2 · p. 6

4.1.3 Data Labeling.

• 1,058 param-sink and 340 logging flows were manually labeled, with expert agreement of 0.74 for the param-sink labels.The labeled data included random and balanced subsets; all remaining 127 SecBench.js vulnerabilities were judged unexpected after excluding eight expected cases.Source: §4.1.3 · p. 6

4.1.4 Model Hyperparameters.

• Fluffy’s four learned instantiations trade off manual labeling and prediction strategy, while models generally use 768-dimensional VarCLR embeddings.The framework includes supervised neural classification, automatically trained neural modeling, OC-SVM novelty detection, and few-shot Codex prompting.Source: §4.1.4 · pp. 6–7

4.2.2 Param-Sink Flows.

• Fluffy approaches outperform Frequency Counting across random param-sink evaluations, reaching F1 scores of 0.9–1.0 for command injection and reflected XSS.Code injection scores were around 0.8, while path traversal peaked at 0.45 because the random set contained only eight unexpected cases.Source: §4.2.2 · p. 7, Table 5 · p. 8
• Binary Classification performs best on the balanced param-sink set, significantly surpassing Novelty Detection for code injection and path traversal.The balanced set contained more diverse names and 105 unexpected path-traversal cases; Sink Prediction’s code-injection F1 fell from 0.82 to 0.53.Source: §4.2.2 · p. 7, Table 6 · p. 8
• Novelty Detection and Binary Classification are the strongest overall param-sink approaches, while Sink Prediction and Codex perform worse.The authors attribute this pattern to limited usefulness of observed flow likelihoods and insufficient information in randomly selected Codex examples.Source: §4.2.2 · p. 8
• Path traversal is hardest for all approaches because its parameter names are highly diverse across file operations, file types, and related concepts.The models learn the less diverse names of other sink types more effectively, including command injection with only two novelty-detection seed names.Source: §4.2.2 · p. 8

4.2.3 Logging Flows.

• Binary Classification performs best on logging flows, whereas Regular Expressions achieve the highest recall and the learning-based approaches achieve better precision.Regular expressions are effective but difficult to write and maintain; the learning-based approach requires little human intervention.Source: §4.2.3 · pp. 8–9, Table 7 · p. 9
• Fluffy correctly flags a clear-text logging flow for a variable named passcode that CodeQL misses because its heuristics also classify the name as encrypted or hashed.The authors reported the issue to CodeQL maintainers, who acknowledged it as a bug.Source: §4.2.3 · p. 9

4.3.1 Fluffy on Past Vulnerabilities.

• In the SecBench.js evaluation, recall was the main metric because the study focused on whether Fluffy could flag known vulnerabilities; precision was evaluated in RQ1.Source: §4.3.1 · p. 9
• Novelty Detection performed very well for command injection, closely followed by Binary Classification.Sink Prediction achieved the best recall for code injection because its selected threshold favored the SecBench.js distribution.Source: §4.3.1 · p. 9

4.3.2 Fluffy on Previously Unknown Vulnerabilities.

• Fluffy identified a moment locale vulnerability that became CVE-2022-24785 and prompted 16 pull requests addressing other unexpected flows.Seven pull requests had been merged, eight remained open, and one was closed after an alternative fix was implemented.Source: §4.3.2 · p. 9
• The authors conclude that Fluffy can find real-world vulnerabilities.Source: §4.3.2 · p. 10

4.4 RQ3: Human Efforts vs. Model Effectiveness

• Binary Classification generally achieves higher F1 scores as its training-set size increases, although 10% suffices for command injection.The experiment keeps the test set at 20% and increases training data from 10% to 80% in 10% steps.Source: §4.4 · p. 10
• Novelty Detection outperforms Binary Classification trained on 10% of the data while requiring only a small set of seed names.Binary Classification is preferable when enough labeled data is available, whereas Novelty Detection uses less training effort.Source: §4.4 · p. 10

4.5 RQ4: Scalability

• CodeQL queries finished within four hours on more than 99.97% of projects for param-sink flows and more than 99.98% for logging flows.This suggests the CodeQL component is usually not a bottleneck, although truly massive projects may remain challenging.Source: §4.5 · p. 10
• Novelty Detection trains and evaluates in under three seconds, while Binary Classification trains in under five minutes and evaluates each model in about 1.5 seconds.These timings indicate that the neural components generally scale well apart from Codex.Source: §4.5 · p. 10
• Sink Prediction takes about 1.5 hours to train and 20 seconds to evaluate, while Codex provides one rate-limited completion every 1.8 seconds on average.Source: §4.5 · p. 10

4.6 Threats to Validity

• Results cover only five vulnerability types, projects hosted on LGTM.com, and JavaScript, so generalization to other settings remains uncertain.Source: §4.6 · p. 10
• Manual labeling and human-selected Novelty Detection seed names may introduce bias or error.Independent labelers covered only a small fraction of the data.Source: §4.6 · p. 10
• The balanced dataset contains more unexpected flows than are expected in the wild, which may lead to overfitting.Source: §4.6 · p. 10

Neural software analysis

• Fluffy augments CodeQL with machine learning rather than building a fully neural end-to-end vulnerability detector, focusing on warning relevance.Unlike systems that identify APIs producing tainted data, Fluffy finds parameters that may receive tainted data and can flag potential vulnerabilities without observed tainted examples.Source: §5 · p. 10

Bimodal code

• Fluffy systematically uses natural-language information to improve taint analysis, extending prior uses of code’s bimodal structure.The paper presents this systematic use as a novel application of natural-language information to taint analyses.Source: §5 · p. 11

False-positive detection

• Fluffy also relates to neural false-positive detection but specifically targets taint analysis and introduces alternative formulations of the learning task.The underlying taint analysis is deliberately imprecise and is not expected to operate independently.Source: §5 · p. 11

Static-analysis heuristics

• Where other learned static-analysis heuristics improve analysis efficiency, Fluffy aims to ensure reported warnings are relevant to developers.This distinguishes warning selection from choosing analysis contexts or reducing analysis cost.Source: §5 · p. 11

Identifier representations

• Fluffy uses VarCLR identifier embeddings because variables names differ substantially from natural-language text targeted by common embedding methods.VarCLR was selected because it specifically targets identifier names and has outperformed other approaches in this domain.Source: §5 · p. 11

6 CONCLUSIONS

• Fluffy combines CodeQL static taint analysis with four neural components and performs well on real-world JavaScript code and known vulnerabilities.The reported outcomes are high accuracy for potentially problematic flows and high recall for known vulnerabilities.Source: §6 · p. 11
• The authors plan tighter integration between static and neural components and broader application to other programming languages.These directions define the paper’s stated future-work boundary.Source: §6 · p. 11
• SuSi’s natural-language features are manually engineered and rely on simple string matching, such as checking whether a method name starts with “get”.This footnote contrasts that prior approach with richer learned representations discussed in the paper.Source: §6 · p. 11