TraceLens: Interactive Taint-Flow Debugging
- TraceLens is a question-driven debugging system for taint-flow analysis that transforms CodeQL outputs into an interactive graph view using Soufflé-powered Datalog queries.
- It employs templated interrogative queries—such as why-flow, why-not-flow, and what-if analysis—to facilitate the debugging of third-party library models and configuration inaccuracies.
- Empirical evaluations demonstrate significant improvements in debugging accuracy, reduced mental workload, and faster interactive analysis compared to traditional static analysis tools.
Searching arXiv for "TraceLens" and closely related papers to ground the article. TraceLens is a question-driven debugging system for taint-flow understanding, introduced as the first end-user question-answer style debugging interface for taint analysis. It is designed for the sensemaking process that arises when developers must determine why certain taint flows appear, why expected flows are missing, and how assumptions about third-party libraries alter overall connectivity. Built as a layer on top of CodeQL results and using Soufflé as a Datalog engine for secondary queries, TraceLens replaces isolated warnings and list/tree-style flow inspection with templated interrogative queries, graph-based visualization, and speculative what-if analysis (Yetiştiren et al., 10 Aug 2025).
1. Problem setting and conceptual basis
TraceLens addresses a specific failure mode of practical taint analysis: the dependence of reported results on source definitions, sink definitions, sanitizer definitions, and models of third-party libraries. If these are wrong or incomplete, an analyzer may report spurious flows or miss expected flows. The system is therefore framed not as a new taint-analysis engine, but as an end-user debugger for taint-analysis configuration, especially for third-party library models, sources, sinks, and sanitizers (Yetiştiren et al., 10 Aug 2025).
The underlying conceptual model follows standard taint-analysis terminology. A source is where untrusted or sensitive data enters; a sink is a security-critical use site; a sanitizer is a function that cleans or encodes data so it should no longer be considered tainted; and a third-party library model is an abstraction of behavior inside external libraries that specifies how taint flows through library methods without analyzing library source. The paper emphasizes that these library models are plug-in abstractions and are often inaccurate. TraceLens assumes that the user already suspects such inaccuracies and wants to debug them.
A central motivation is that existing tools mostly offer isolated warnings, one-warning-at-a-time inspection, and tree-view or list-view visualizations. The paper argues that such views make it difficult to reason about the global impact on connectivity between multiple sources and sinks. TraceLens therefore reorients taint-analysis debugging toward explicit question asking and global graph reasoning. This suggests a shift from path-by-path inspection toward a structured inquiry process over a taint graph.
2. Architecture, workflow, and fact representation
TraceLens is built as a layer on top of CodeQL results, using Soufflé as a Datalog engine for secondary queries. It does not modify CodeQL’s analysis algorithm. Instead, the workflow begins by running CodeQL taint analysis, then converting CodeQL output into facts, then executing interrogative queries over that factbase, and finally visualizing the answers in graph form (Yetiştiren et al., 10 Aug 2025).
The fact extraction step materializes a graph-oriented representation of the taint analysis. The paper describes node(id) facts for program points and metadata such as file, line, column, and symbol name; edge(edgeid, sourceid, targetid) for taint-propagation edges; plausible_edge(...) for edges that may be inactive under different assumptions; source(nodeid) and sink(nodeid) markers; and library_flow(edgeid, fact_id) relations for known third-party library flow annotations. This representation allows TraceLens to query the existing taint graph with Datalog rules instead of recomputing taint analysis from scratch.
The architecture is explicitly tuned for interactive debugging. A user chooses a templated question, the system concretizes that question into logic, and Soufflé computes the answer from precomputed facts. The result is then rendered as an interactive graph. This is important because the paper positions TraceLens against repeated full analyses after every hypothetical reconfiguration of a library model.
3. Query model and interrogative semantics
TraceLens provides six templates spanning why-flow, why-not-flow, affected sinks, divergent sinks, divergent sources, and global impact. These are translated into logic queries automatically. The templates are intended to make end-user reasoning explicit: whether the goal is to explain an existing path, explain a missing path, identify a shared culprit API, or estimate the system-wide effect of changing a model (Yetiştiren et al., 10 Aug 2025).
| Template | Question | Semantic goal |
|---|---|---|
| WhyFlow | Why is there a taint flow from source X to sink Y? | Identify which third-party library models or assumptions currently allow the flow |
| WhyNotFlow | Why is there no taint flow from source X to sink Y? | Identify which model assumptions terminate the flow, especially sanitizers |
| AffectedSinks | If we alter third-party library Z’s model, which sinks are affected? | Perform speculative what-if analysis under a new model assumption |
| DivergentSinks | Which third-party library model could influence multiple taint flows from the same source? | Find a common branching point from one source into multiple sinks |
| DivergentSources | Which third-party library model could influence multiple taint flows reaching the same sink? | Find a common convergence point where multiple source paths converge |
| GlobalImpact | Which third-party library model could have the largest global influence on multiple flows from a source to a sink? | Rank APIs by frequency across all paths |
The paper also sketches the computational structure behind these templates. WhyFlow uses transitive closure over edge to find reachability from source to sink, then intersects with library_flow to expose participating library APIs. WhyNotFlow reasons about a broken or blocked path and identifies sanitizer modeling or other blocking assumptions that terminate transitive connectivity. DivergentSinks and DivergentSources compute intersections of reachable sets, respectively looking for a last common node before paths split and a first common node where multiple source paths converge. GlobalImpact uses aggregation to count how many distinct reachable paths include each API and then rank or size nodes accordingly.
A notable design choice is extensibility. The paper includes a simple illustrative Datalog example showing how a new query can be added as a rule. The intended implication is that TraceLens is not restricted to a fixed explanation vocabulary; rather, it provides a factbase and a query style for end-user debugging.
4. Graph visualization and speculative what-if analysis
TraceLens answers are displayed in a graph view that emphasizes connectivity rather than isolated warnings. The visualization uses green for source nodes, red for sink nodes, orange for third-party API nodes, and blue for other intermediate nodes. Solid edges represent existing reported flows, while dashed edges represent plausible flows under alternate assumptions (Yetiştiren et al., 10 Aug 2025).
This graphical encoding is tightly connected to the system’s speculative what-if analysis. A user can ask what happens if a third-party API were modeled differently—for example, if an API were treated as a sanitizer. In that case, an API that was previously a pass-through may become a flow terminator, the transitive closure of reachable nodes shrinks, and the set of reachable sinks can drop. The paper describes this as counterfactual connectivity analysis. The system is therefore not merely visualizing current analysis results; it is visualizing how those results would change under alternate model assumptions.
The interface includes a query configuration pane and an interactive graph view. Users select a template such as WhyFlow, WhyNotFlow, AffectedSinks, DivergentSinks, DivergentSources, or GlobalImpact, then concretize it using a source, a sink, and possibly a specific third-party API or library model. Interaction features include hover for fully qualified names, click-to-code navigation in the IDE, path expansion, layout changes such as breadth-first or concentric layouts, and node resizing by impact score in GlobalImpact. The paper reports that participants especially liked color-coding and graph-based visualization for tracking flows, while expandable paths and node-to-code navigation were less used or less understood.
5. Empirical evaluation and observed effects
The evaluation is centered on a within-subject crossover study with 12 participants after filtering, using the CodeQL Visual Studio Code plugin visualizer as the baseline. The study tasks used realistic Apache Dubbo taint warnings generated by CodeQL, and each task had 8 questions covering why, why-not, what-if, and counting and ranking taint-flow questions. The Apache Dubbo dataset in the study contained 6,901 edges, 8,101 nodes, 26 sources, 265 sinks, 85 third-party API functions, and 383 taint warnings (Yetiştiren et al., 10 Aug 2025).
The principal quantitative result is that TraceLens improved participants’ answers: the average question completion rate increased from 71% to 92%, reported as about 21% higher accuracy on average. The paper further reports statistically significant improvements with large effect sizes, including correctness with Cohen’s and empty answers with Cohen’s . The improvements were especially strong on questions requiring global reasoning and multiple-flow reasoning.
The workload findings are similarly strong. Reported NASA-TLX averages were mental demand 3.25 vs. 5.92, hurriedness 2.83 vs. 6.17, stress 2.33 vs. 5.17, perceived success 6.17 vs. 3.08, and effort 2.92 vs. 6.08. The abstract summarizes this as a 45% reduction in mental demand. Confidence and ease of use were also higher: 4.25 vs. 2.08 for confidence and 4.25 vs. 1.92 for ease of use. Participants additionally reported higher willingness to use TraceLens in the future, with an average future-use rating of 4.83.
The paper also reports an interaction-time advantage. Querying precomputed facts with Soufflé took about 5 seconds, compared to 10–14 seconds for repeated CodeQL analysis per reconfiguration. This performance claim supports the system’s positioning as an interactive debugging layer rather than a replacement taint-analysis engine.
An additional case study involved two professional security developers. Both gave more correct answers with TraceLens and both reported higher confidence and ease of use. This does not replace the core study design, but it suggests that the observed benefits are not confined to student participants.
6. Scope, limitations, and nomenclature
TraceLens is narrowly scoped. It assumes that users already suspect a mismatch, that they are familiar with the program, and that the debugging target is the configuration of third-party models rather than the underlying taint-analysis algorithm. The system builds on CodeQL results, does not modify CodeQL’s analysis algorithm, and focuses on end-user configuration debugging rather than classifier-style false positive or false negative detection (Yetiştiren et al., 10 Aug 2025).
The evaluation is also bounded. The paper explicitly notes a modest study size of 12 participants, one baseline tool in the main comparison, and one subject program for the core study task. It further notes that results may depend on the program and tasks chosen, and that the UI could be improved with a legend, stronger labeling of node types, more explicit fully qualified names, and click-to-edit support for models. These caveats matter because the strongest claims concern question-driven taint-flow debugging under a specific tooling stack, not universal superiority across all static-analysis settings.
The term TraceLens should also be distinguished from several unrelated systems whose names contain TRACE. "TRACE: Temporal Radiology with Anatomical Change Explanation" is a grounded temporal chest X-ray report generation framework that jointly performs temporal comparison, change classification, and spatial localization (Aranya et al., 3 Feb 2026). "TRACE: Training and Inference-Time Interpretability Analysis for LLMs" is a modular interpretability toolkit for transformer LLMs, coupled with ABSynth, for monitoring linguistic, geometric, and optimization signals during training and at inference time (Aljaafari et al., 4 Jul 2025). "TRACE: Trajectory Reasoning through Adaptive Cross-Step Evidence Aggregation for LLM Agents" is a training-free monitoring framework for long-horizon LLM agent trajectories that uses a TIJ loop to detect covert sabotage through cross-window evidence propagation (Mittapalli et al., 5 Jun 2026). A plausible implication is that similar “trace” terminology appears across static analysis, medical vision-language modeling, interpretability, and agent monitoring, but TraceLens itself refers specifically to question-driven debugging for taint-flow understanding.
In practical terms, TraceLens’ distinctive contribution is the combination of CodeQL-derived facts, Soufflé-based logical querying, graph-based visualization, and speculative what-if analysis. Within that scope, it turns taint-analysis debugging from manual path inspection into an explicit, query-driven sensemaking process.
