Pith. sign in

REVIEW 4 major objections 4 minor 47 references

Dynamic taint analysis for JavaScript and Python can be built as a runtime-independent shadow virtual machine, letting one declarative rule set track taint across V8, SpiderMonkey, and CPython at 1.85x overhead and 95.5% recall.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-02 06:34 UTC pith:PAK7CQ63

load-bearing objection A genuinely promising runtime-independent DTA design with broad, honest evaluation; the portability contract is under-specified where it matters most, but the paper deserves serious review. the 4 major comments →

arxiv 2607.12308 v2 pith:PAK7CQ63 submitted 2026-07-14 cs.PL cs.SE

Mystra: Declarative Dynamic Taint Analysis via Shadow Virtual Machine

Zhuohao Zhang , Junkun Liu , Rui Yang , Yinzhi Cao , Ziyang Li This is my paper
classification cs.PL cs.SE
keywords dynamic taint analysisshadow virtual machinedeclarative rule languageruntime instrumentationJavaScript securityPython securityprovenance trackinghigher-order functions
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper tries to establish that dynamic taint analysis (DTA) for interpreted languages can be made runtime-independent: a single shadow virtual machine plus a declarative rule language can track taint regardless of whether the host runtime is an interpreter, a JIT, an embedding, or a different language. The authors claim this separation lets the same taint semantics run on V8, SpiderMonkey, and CPython with a shared 3,941-line core, achieving 95.5% recall on a 493-CVE vulnerability benchmark, zero false positives on 141 patched-version runs, and 1.85x overhead over vanilla Node.js. If correct, this means adding a new vulnerability class is just writing rules, and porting to a new runtime is writing an adapter—not reimplementing taint logic. A sympathetic reader would care because it promises to make DTA infrastructure reusable across the JavaScript and Python ecosystems and to make rule authoring accessible to language models with validator feedback.

Core claim

The central claim is that a general DTA can be factored into (1) a runtime-independent abstract machine—the Shadow VM—that observes host execution as a uniform stream of operation-entry and operation-exit events and maintains shadow stack, shadow heap, provenance DAG, and cross-invocation context; and (2) Mystra, a declarative specification language with formal operational semantics whose rules are compiled ahead of time to a binary format with constant-time dispatch. The authors argue this is the first such abstraction that fully separates taint semantics and state transitions from how the host runtime observes and executes operations. They build Shar, which reuses a 3,941-line shared core

What carries the argument

The central mechanism is the Shadow Virtual Machine (Shadow VM): a parallel abstract machine that runs alongside the host runtime, consuming well-bracketed entry/exit operation events through a host interface and updating four shadow states—shadow stack, shadow heap, provenance DAG, and specification context. Mystra, the companion declarative DSL with formal operational semantics, compiles rules ahead of time to a binary representation dispatching in constant time. Its novel inject/extract actions bridge taint across higher-order function boundaries (e.g., Array.map) declaratively, and the specification context extends taint across invocation boundaries like file I/O.

Load-bearing premise

The load-bearing premise is the portability contract: every taint-relevant host operation must be observable as a well-bracketed entry/exit event, and the adapter must be able to synchronize shadow state across exceptions, async suspension, garbage-collection moves, and native boundaries—if any operation is unobservable or unmodeled, taint is silently dropped.

What would settle it

Feed a tainted value through an operation that the host interface does not expose as a well-bracketed entry/exit pair (e.g., Blink's structured-clone path, a SQL write followed by a read, or a CPython f.write) and check whether the provenance DAG reaches a downstream sink; the paper's own partial detections (n8n, Astrbot, the Chromium postMessage miss) are instances where taint is lost, so a definitive test is whether extending the host interface to model the missing boundary recovers those flows with no changes to the shared core.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Supporting a new vulnerability class requires only adding declarative Mystra rules, with no engine modification; in the evaluation, CWE-89 support added a single sink rule.
  • Porting DTA to a new runtime reduces to writing an adapter that satisfies the host interface; the paper reports a 446-line CPython adapter and a 1,186-line SpiderMonkey adapter sharing an unchanged 3,941-line core.
  • The same Mystra rule bodies compile unchanged across runtimes after rebinding operation keys; on SpiderMonkey 18 of 19 ported behaviors fired without rule edits.
  • Taint semantics are identical across interpreter and JIT tiers, so taint survives JIT-optimized execution without deoptimization; Maglev nodes implement the same Shadow VM transitions as Ignition hooks.
  • LLM-assisted rule authoring becomes practical with validator feedback: one feedback round improved runtime candidate behaviors from 19/32 to 29/32.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If the Shadow VM abstraction is sound, it suggests that any runtime that can emit a well-bracketed operation-event stream can adopt the same taint specification—potentially extending to WebAssembly, embedded scripting engines, or other dynamic languages, as long as the portability contract is satisfied.
  • The same separation of observation from semantics could be reused for other dynamic analyses, such as provenance tracking, dynamic dataflow, or runtime monitoring, since the event-stream abstraction is not taint-specific.
  • The known taint-loss points (serialization boundaries, SQL persistence, and file-write object metadata) imply the abstraction's power is bounded by the host interface's visibility; a testable extension would be adding queryable metadata to the specification context (e.g., file-descriptor paths, SQL key spaces) to recover those flows without touching the shared core.
  • The reported 1.85x overhead likely hides higher costs on sustained CPU-heavy workloads because always-on property-access and call hooks dominate; selective instrumentation that activates hooks only on taint-reachable code is a natural next step to test.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper presents Mystra, a declarative DSL for dynamic taint specifications, and Shar, a DTA engine built on a 'Shadow Virtual Machine' abstraction. A host adapter projects runtime execution onto uniform operation-entry/exit events; the Shadow VM maintains shadow stack, shadow heap, provenance DAG, and a specification context, and applies Mystra rules compiled ahead of time. Shar is instantiated on V8 (Node.js and Chromium), SpiderMonkey, and CPython, with a claimed shared core of 3,941 LoC. The evaluation reports 95.5% recall on 493 in-scope SecBench.js CVEs across four CWE categories, zero false positives on 141 patched-version runs, full or partial detection of 19 recent real-world CVEs across three runtimes, and 1.85x end-to-end overhead over vanilla Node.js on NodeMedic's benchmark. The central claim is that this is the first runtime-independent DTA abstraction separating taint semantics and state transitions from how a host runtime observes and executes them.

Significance. If the central claim holds, this is a substantial contribution: a reusable DTA core across runtimes, a declarative rule language with formal operational semantics, and an unusually broad evaluation (493 CVEs, three runtimes, real-world 2024-2026 vulnerabilities). The paper is candid about root-cause misses and provides open-source artifacts and per-runtime porting costs, which strengthens confidence in the engineering. The formal language design, including inject/extract for higher-order functions, is interesting and potentially reusable beyond this specific tool. However, the headline runtime-independence claim depends on a 'portability contract' whose hardest clause — continuation synchronization across exceptions and async suspension — is asserted rather than formalized or independently validated. The precision claims are also narrower than a reader might infer from the abstract. These issues are fixable within the manuscript's scope, so they warrant major revision rather than rejection.

major comments (4)
  1. [§III-C, §IV-D, Fig. 5] The formal semantics in Fig. 5 define reductions only for well-bracketed enter/τ/exit events. Exception unwinding, Promise suspension/resumption, and other non-local control transfers are not given transitions; §III-C capability 6 only states that the adapter 'synchronizes S with the host's logical continuation' without a precise formal contract. Consequently, the trace-relative guarantee in §IV-D is conditional on a portability contract whose most difficult clause is unverified. The paper's own misses confirm the risk: §VI-A.1 reports two command-injection cases that 'pass intermittently under async timing', and §VI-D reports the Chromium postMessage miss at the SerializedScriptValue boundary and the CPython f.write miss because file metadata is not exposed. These are exactly silent taint-loss cases that the portability contract is supposed to rule out. To support the runtime-independen
  2. [Table III; §VI-A.3] Precision is reported as 'zero false positives on patched-version testing' (Table III), which is narrower than a general zero-FP claim. The n8n case study in §VI-A.3 reports two false filesystem alerts caused by over-propagation through TypeORM object merging, so the alert stream on vulnerable runs is not false-positive-free. The paper should report the total number of alerts per case and the number of false alerts on vulnerable runs, including CWE-divergent alerts, rather than only counting patched-version runs. Without this, readers cannot assess the practical precision of the tool beyond the 141-case patched-version test.
  3. [Table I; §VI-C; Table VI] The rule set is 'manually authored and iteratively refined using API-level tests' on the same benchmark (Table I note). This introduces a nontrivial tuning risk for the 95.5% SecBench.js recall figure. The 2024-2026 real-world CVEs and the SpiderMonkey/CPython ports mitigate that risk, but the paper does not state whether the final rule set was frozen before those runs or whether rules were added during porting/evaluation. Please state this explicitly and, if possible, report accuracy with a frozen rule set. Separately, the CodeQL comparison in §VI-C claims '18× fewer LoC', but the values in Table VI (CodeQL 1,149 vs Mystra 463) imply a ratio of about 2.5×, not 18×; the table and text need to be reconciled.
  4. [§VI-A.1] The decision to count alerts that 'reach a different dangerous sink than the benchmark's nominal CWE' as true positives, recording them as CWE divergence, needs more auditability. If an alert lands at a different sink, it may still be a true security finding, but it is not a detection of the benchmark's nominal CWE. The paper should list the number of such divergences per CWE category and, ideally, give examples. Without that detail, the 95.5% recall figure may be optimistic relative to the benchmark's labeling even if it is defensible as a security-detection rate.
minor comments (4)
  1. [References / §VIII-A] Reference [13] is cited for Foxhound, but the reference entry is the 'Hand sanitizers in the wild' paper, not Foxhound. Please correct this citation; it currently misattributes related work.
  2. [Fig. 5] In E-ENTER and E-EXIT, the side condition `R, op, σ ⊢ prehook(¯a) ⇓ σ'` uses `op` but the rule premise does not bind `op` before that judgment. Clarify that `op` is the operation named in the event.
  3. [Table V] The rule distribution table is hard to read because numbers are run together (e.g., 'String.prototype49 8 4', 'Code injection eval, Function, vm7'). Reformat so each action type has a clear column; currently the counts are not auditable at a glance.
  4. [Abstract / §I and Table III] The phrase 'zero false positives' appears in the abstract and introduction without the 'on patched-version testing' qualification that appears later. Since the n8n case has two false alerts, please consistently qualify the claim to avoid overstatement.

Circularity Check

1 steps flagged

No significant circularity: central evidence is external (SecBench/patched-version/3-runtime ports); only a minor definitional trace-relative guarantee.

specific steps
  1. self definitional [Section IV-D (Operational Semantics), trace-relative guarantee]
    "Thus, Mystra provides a trace-relative guarantee: for any event trace satisfying the portability contract, if the loaded rules conservatively summarize the explicit dependencies of all opaque operations encountered, then all modeled explicit source-to-sink flows are propagated to sinks."

    The consequent is exactly what the action rules implement: E-PROPAGATE/E-SOURCE/E-SINK transfer taint whenever the loaded rule declares a source/dest pair, so 'all modeled flows are propagated' is entailed by the semantics of rule application. The real burden — that the handwritten rules are conservative summaries and that adapters satisfy capability 6 (continuation synchronization) — is pushed into the antecedent rather than established. This is a definitional soundness lemma, not an independent validation of the runtime-independence claim, but it is not used as the empirical evidence for recall/portability.

full rationale

Shar's headline results are not derived from the rule semantics by construction: recall and false-positive counts are measured against SecBench.js, NodeMedic, and patched-version runs; overhead is measured end-to-end; portability is demonstrated by three separate adapters reusing a 3,941-LoC shared core. Misses (Blink SerializedScriptValue, n8n SQL persistence, Astrbot f.write, two async command-injection cases) are reported in the paper itself, and the portability contract's capability 6 is described as an adapter requirement rather than proven — a completeness/soundness limitation, not circularity. The authors' self-citations ([5], [6], [42], [43]) are background and comparison material; no uniqueness theorem is imported from their own prior work, and the load-bearing argument does not reduce to a self-citation chain. The only definitional element is the trace-relative guarantee in §IV-D, whose antecedent ('rules conservatively summarize...' and 'event trace satisfying the portability contract') carries the empirical weight; the consequent is a restatement of the action semantics. This does not invalidate the external measurements, but it means the abstraction's generality is only as strong as the handwritten 303-LoC rules and the adapter contract. Overall, no significant circularity; score 2 reflects the minor self-definitional theorem rather than any fitted-input-called-prediction or self-citation-loaded derivation.

Axiom & Free-Parameter Ledger

0 free parameters · 4 axioms · 1 invented entities

The central contribution rests on two practical assumptions: the host adapter faithfully realizes the six-capability portability contract, and the hand-authored Mystra rules collectively model the opaque operations in the evaluated workloads. No numeric free parameters are fitted; the hand-tuned 303-LoC rule set is a policy-level assumption more than a numerical parameter. The paper documents boundary losses consistent with these assumptions.

axioms (4)
  • domain assumption Host adapter portability contract: every taint-relevant host operation exposes well-bracketed entry/exit events with stable identity, operand addressing, object lifetime, and continuation synchronization.
    Stated in Section III-C. If violated, the shadow state diverges and taint is silently lost; the paper's own misses (Blink SerializedScriptValue, f.write path) illustrate boundary failures.
  • domain assumption The loaded Mystra rules conservatively summarize explicit dependencies of all opaque operations encountered in a run.
    Invoked by the trace-relative guarantee at the end of Section IV-D. The paper lists false-negative causes that are exactly unmodeled or under-modeled operations.
  • domain assumption SecBench.js labels, proof-of-concept exploits, and patched packages correctly identify the vulnerability and its fixed behavior.
    Recall and precision numbers inherit benchmark validity; 10 SecBench cases are excluded as invalid, and CWE divergence is adjudicated manually rather than by an independent oracle.
  • domain assumption Shadow heap entries survive host GC relocation and finalization, and per-key taint remains correctly mapped to object addresses.
    Required by the shadow heap definition in Section III-B2; the paper says relocation/finalization hooks implement it, but this is not independently verified here.
invented entities (1)
  • Shadow Virtual Machine (shadow stack, shadow heap, provenance DAG, specification context) independent evidence
    purpose: Maintains parallel taint state alongside the host runtime and provides uniform state transitions across operation events.
    The abstraction is instantiated in Shar and evaluated through detection accuracy, performance, and portability results; it is falsifiable by re-running the tool, so it is not an evidence-free postulate.

pith-pipeline@v1.3.0-alltime-deepseek · 239 in / 10021 out tokens · 147745 ms · 2026-08-02T06:34:32.547792+00:00 · methodology

0 comments
read the original abstract

Dynamic taint analysis (DTA) for interpreted languages like JavaScript and Python requires three capabilities: observing host-runtime operations, maintaining parallel taint states, and defining how taint propagates. Existing systems couple these capabilities within an instrumentation mechanism -- source-rewriting or engine-native -- either incurring high runtime overhead or demanding engine-specific embeddings. There is yet to be a runtime-independent abstraction of a general DTA that separates taint semantics and state transitions from how a host runtime executes them. We set out to develop a DTA engine that is extensible, performant, and accurate. To achieve this, we introduce a Shadow Virtual Machine executing alongside host runtimes that tracks multi-level taint, provenance, and cross-invocation context. We design Mystra, a declarative taint specification language with formal operational semantics. Mystra is designed to be language model friendly, and is equipped with validators enabling trustworthy automated synthesis of rules. Mystra is also the first to express higher-order function taint transfer declaratively. Further, Mystra rules are compiled ahead of time to a binary representation and dispatch in constant runtime. We implement our vision into a tool named Shar, which contains a shared core engine and instantiations on three runtimes: V8 in both Node$.$js and Chromium (embedding), SpiderMonkey (engine), and CPython (language). Accuracy wise, on SecBench$.$js (493 in-scope CVEs across four CWE categories), our V8 instantiation achieves 95.5% recall with zero false positives on patched-version testing. Regarding performance, the runtime overhead of Shar is 1.85$\times$ over vanilla Node$.$js on NodeMedic's benchmarks, and is 22.7$\times$ lower than NodeMedic-FINE on identical workloads, all the while producing 33.2% higher recall in its supported categories.

Figures

Figures reproduced from arXiv: 2607.12308 by Junkun Liu, Rui Yang, Yinzhi Cao, Zhuohao Zhang, Ziyang Li.

Figure 1
Figure 1. Figure 1: Motivating example: data flow and taint specification. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Overview of the proposed architecture. (Shadow Stack) S ∈ Frame∗ (Shadow Heap) H : Addr × Key → TaintId (Prov. DAG) G : List⟨FlowNode⟩ (Spec. Context) C : VarName × Val ∗ ⇀ Val (Values) Val ∈ TaintId ∪ Ref ∪ Z ∪ Str ∪ Bool [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 4
Figure 4. Figure 4: Core Abstract syntax of Mystra. · denotes a sequence. [ · ] denotes optional. C. Specification Context Extension Taint in the shadow stack S and heap H is tied to live ob￾jects and active operation frames. When a tainted value crosses an invocation boundary, the connection is lost: writeFile and a subsequent readFile execute in different frames with no surviving taint. Mystra provides specification context… view at source ↗
Figure 5
Figure 5. Figure 5: Core operational semantics of Mystra calls and actions; actions are treated as no-ops when there is no taint. [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗

Review history (2 revisions) →

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

47 extracted references · 4 linked inside Pith

  1. [1]

    Riding out DOMsday: Towards detecting and preventing DOM cross-site scripting,

    W. Melicher, A. Das, M. Sharif, L. Bauer, and L. Jia, “Riding out DOMsday: Towards detecting and preventing DOM cross-site scripting,” in NDSS, 2018

    2018

  2. [2]

    Understanding and auto- matically preventing injection attacks on node. js,

    C.-A. Staicu, M. Pradel, and B. Livshits, “Understanding and auto- matically preventing injection attacks on node. js,” in Network and Distributed System Security Symposium (NDSS), 2018

    2018

  3. [3]

    NodeMedic- FINE: Automatic detection and exploit synthesis for Node.js vulnera- bilities,

    D. Cassel, N. Sabino, M.-C. Hsu, R. Martins, and L. Jia, “NodeMedic- FINE: Automatic detection and exploit synthesis for Node.js vulnera- bilities,” in NDSS, 2025

    2025

  4. [4]

    Automated exploit generation for Node.js packages,

    F. Marques, M. Ferreira, A. Nascimento, M. E. Coimbra, N. Santos, L. Jia, and J. F. Santos, “Automated exploit generation for Node.js packages,” Proc. ACM Program. Lang., vol. 9, no. PLDI, pp. 1341– 1366, 2025

    2025

  5. [5]

    Probe the proto: Measuring client-side prototype pollution vulnerabilities of one million real-world websites,

    Z. Kang, S. Li, and Y . Cao, “Probe the proto: Measuring client-side prototype pollution vulnerabilities of one million real-world websites,” in NDSS, 2022

    2022

  6. [6]

    Follow my flow: Unveiling client-side prototype pollution gadgets from one million real-world websites,

    Z. Kang, M. Lyu, Z. Liu, J. Yu, R. Fan, S. Li, and Y . Cao, “Follow my flow: Unveiling client-side prototype pollution gadgets from one million real-world websites,” in 2025 IEEE Symposium on Security and Privacy (SP). IEEE, 2025, pp. 991–1008

    2025

  7. [7]

    Locus: Agentic pred- icate synthesis for directed fuzzing,

    J. Zhu, C. Shen, Z. Li, J. Yu, Y . Chen, and K. Pei, “Locus: Agentic pred- icate synthesis for directed fuzzing,” arXiv preprint arXiv:2508.21302, 2025

    Pith/arXiv arXiv 2025

  8. [8]

    A contemporary survey of large language model assisted program analysis,

    J. Wang, T. Ni, W.-B. Lee, and Q. Zhao, “A contemporary survey of large language model assisted program analysis,” arXiv preprint arXiv:2502.18474, 2025

    Pith/arXiv arXiv 2025

  9. [9]

    Pocgen: Generating proof-of- concept exploits for vulnerabilities in npm packages,

    D. Simsek, A. Eghbali, and M. Pradel, “Pocgen: Generating proof-of- concept exploits for vulnerabilities in npm packages,” arXiv preprint arXiv:2506.04962, 2025

    Pith/arXiv arXiv 2025

  10. [10]

    Jalangi: A selec- tive record-replay and dynamic analysis framework for JavaScript,

    K. Sen, S. Kalasapur, T. G. Brutch, and S. Gibbs, “Jalangi: A selec- tive record-replay and dynamic analysis framework for JavaScript,” in ESEC/FSE, 2013, pp. 488–498

    2013

  11. [11]

    Platform-independent dynamic taint analysis for javascript,

    R. Karim, F. Tip, A. Sochurkova, and K. Sen, “Platform-independent dynamic taint analysis for javascript,” IEEE Transactions on Software Engineering, vol. 46, no. 12, pp. 1364–1379, 2018

    2018

  12. [12]

    NodeMedic: End-to-end analysis of Node.js vulnerabilities with provenance graphs,

    D. Cassel, W. T. Wong, and L. Jia, “NodeMedic: End-to-end analysis of Node.js vulnerabilities with provenance graphs,” in 2023 IEEE 8th European Symposium on Security and Privacy (EuroS&P), 2023, pp. 1101–1127

    2023

  13. [13]

    Hand sanitizers in the wild: A large-scale study of custom javascript sanitizer functions,

    D. Klein, T. Barber, S. Bensalim, B. Stock, and M. Johns, “Hand sanitizers in the wild: A large-scale study of custom javascript sanitizer functions,” in Proc. of the IEEE European Symposium on Security and Privacy, Jun. 2022

    2022

  14. [14]

    PanoptiChrome: A modern in-browser taint analysis framework,

    R. Kanyal and S. R. Sarangi, “PanoptiChrome: A modern in-browser taint analysis framework,” in WWW, 2024

    2024

  15. [15]

    Secbench.js: An executable security benchmark suite for server-side javascript,

    M. H. M. Bhuiyan, A. S. Parthasarathy, N. Vasilakis, M. Pradel, and C.-A. Staicu, “Secbench.js: An executable security benchmark suite for server-side javascript,” in 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), 2023, pp. 1059–1070

    2023

  16. [16]

    Cve-2025-61686,

    “Cve-2025-61686,” https://nvd.nist.gov/vuln/detail/CVE-2025-61686, 2026, accessed: 2026-05-17

    2025

  17. [17]

    React router,

    “React router,” https://reactrouter.com/, 2026, accessed: 2026-05-17

    2026

  18. [18]

    n8n - secure workflow automation for technical teams,

    “n8n - secure workflow automation for technical teams,” https://github. com/n8n-io/n8n/, 2026, accessed: 2026-05-17

    2026

  19. [19]

    CodeQL: Semantic code analysis engine,

    GitHub, “CodeQL: Semantic code analysis engine,” https://codeql. github.com/, 2024

    2024

  20. [20]

    Cve-2025-55449,

    “Cve-2025-55449,” https://nvd.nist.gov/vuln/detail/CVE-2025-55449, 2026, accessed: 2026-05-17

    2025

  21. [21]

    Dynamic security analysis of JavaScript: Are we there yet?

    S. Calzavara, S. Casarin, and R. Focardi, “Dynamic security analysis of JavaScript: Are we there yet?” in WWW, 2025, pp. 1105–1115

    2025

  22. [22]

    An empirical study of information flows in real-world javascript,

    C.-A. Staicu, D. Schoepe, M. Balliu, M. Pradel, and A. Sabelfeld, “An empirical study of information flows in real-world javascript,” in Proceedings of the 14th ACM SIGSAC Workshop on Programming Languages and Analysis for Security, 2019, pp. 45–59

    2019

  23. [23]

    All you ever wanted to know about dynamic taint analysis and forward symbolic execution (but might have been afraid to ask),

    E. J. Schwartz, T. Avgerinos, and D. Brumley, “All you ever wanted to know about dynamic taint analysis and forward symbolic execution (but might have been afraid to ask),” in 2010 IEEE symposium on Security and privacy. IEEE, 2010, pp. 317–331

    2010

  24. [24]

    Dynamic taint analysis for automatic detection, analysis, and signaturegeneration of exploits on commodity software

    J. Newsome, D. X. Song et al., “Dynamic taint analysis for automatic detection, analysis, and signaturegeneration of exploits on commodity software.” in NDSS, vol. 5, 2005, pp. 3–4

    2005

  25. [25]

    libdft: Practical dynamic data flow tracking for commodity systems,

    V . P. Kemerlis, G. Portokalidis, K. Jee, and A. D. Keromytis, “libdft: Practical dynamic data flow tracking for commodity systems,” in Proceedings of the 8th ACM SIGPLAN/SIGOPS conference on Virtual Execution Environments, 2012, pp. 121–132

    2012

  26. [26]

    Dytan: a generic dynamic taint analysis framework,

    J. Clause, W. Li, and A. Orso, “Dytan: a generic dynamic taint analysis framework,” in Proceedings of the 2007 international symposium on Software testing and analysis, 2007, pp. 196–206

    2007

  27. [27]

    {SelectiveTaint}: Efficient data flow tracking with static binary rewriting,

    S. Chen, Z. Lin, and Y . Zhang, “{SelectiveTaint}: Efficient data flow tracking with static binary rewriting,” in 30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 1665–1682

    2021

  28. [28]

    Taintdroid: an information- flow tracking system for realtime privacy monitoring on smartphones,

    W. Enck, P. Gilbert, S. Han, V . Tendulkar, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel, and A. N. Sheth, “Taintdroid: an information- flow tracking system for realtime privacy monitoring on smartphones,” ACM Transactions on Computer Systems (TOCS), vol. 32, no. 2, pp. 1–29, 2014

    2014

  29. [29]

    Dta++: dynamic taint analysis with targeted control-flow propagation

    M. G. Kang, S. McCamant, P. Poosankam, D. Song et al., “Dta++: dynamic taint analysis with targeted control-flow propagation.” in Ndss, 2011

    2011

  30. [30]

    Jaw: Studying client-side csrf with hybrid property graphs and declarative traversals,

    S. Khodayari and G. Pellegrino, “Jaw: Studying client-side csrf with hybrid property graphs and declarative traversals,” in 30th USENIX Security Symposium (USENIX Security 21). Vancouver, B.C.: USENIX Association, 2021

    2021

  31. [31]

    Riding out domsday: Towards detecting and preventing dom cross-site scripting,

    W. Melicher, A. Das, M. Sharif, L. Bauer, and L. Jia, “Riding out domsday: Towards detecting and preventing dom cross-site scripting,” in 2018 Network and Distributed System Security Symposium (NDSS), 2018

    2018

  32. [32]

    Precise interprocedural dataflow analysis via graph reachability,

    T. Reps, S. Horwitz, and M. Sagiv, “Precise interprocedural dataflow analysis via graph reachability,” in Proceedings of the 22nd ACM SIGPLAN-SIGACT symposium on Principles of programming languages, 1995, pp. 49–61

    1995

  33. [33]

    Two approaches to interprocedural data flow analysis,

    M. Pnueli and M. Sharir, “Two approaches to interprocedural data flow analysis,” Program flow analysis: theory and applications, pp. 189–234, 1981

    1981

  34. [34]

    Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps,

    S. Arzt, S. Rasthofer, C. Fritz, E. Bodden, A. Bartel, J. Klein, Y . Le Traon, D. Octeau, and P. McDaniel, “Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps,” ACM sigplan notices, vol. 49, no. 6, pp. 259–269, 2014

    2014

  35. [35]

    Information flow analysis of android applications in droidsafe

    M. I. Gordon, D. Kim, J. H. Perkins, L. Gilham, N. Nguyen, and M. C. Rinard, “Information flow analysis of android applications in droidsafe.” in NDSS, vol. 15, no. 201, 2015, p. 110

    2015

  36. [36]

    Jn-saf: Precise and efficient ndk/jni-aware inter-language static analysis framework for secu- rity vetting of android applications with native code,

    F. Wei, X. Lin, X. Ou, T. Chen, and X. Zhang, “Jn-saf: Precise and efficient ndk/jni-aware inter-language static analysis framework for secu- rity vetting of android applications with native code,” in Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, 2018, pp. 1137–1150

    2018

  37. [37]

    Compositional taint analysis for enforcing security policies at scale,

    S. Banerjee, S. Cui, M. Emmi, A. Filieri, L. Hadarean, P. Li, L. Luo, G. Piskachev, N. Rosner, A. Sengupta et al., “Compositional taint analysis for enforcing security policies at scale,” in Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2023, pp. 1985–1996

    2023

  38. [38]

    Ql: Object- oriented queries on relational data,

    P. Avgustinov, O. De Moor, M. P. Jones, and M. Schäfer, “Ql: Object- oriented queries on relational data,” in 30th European Conference on Object-Oriented Programming (ECOOP 2016). Schloss Dagstuhl– Leibniz-Zentrum für Informatik, 2016, pp. 2–1

    2016

  39. [39]

    Finding application errors and security flaws using pql: a program query language,

    M. Martin, B. Livshits, and M. S. Lam, “Finding application errors and security flaws using pql: a program query language,” Acm Sigplan Notices, vol. 40, no. 10, pp. 365–383, 2005

    2005

  40. [40]

    Fluently specifying taint-flow queries with fluent tql,

    G. Piskachev, J. Späth, I. Budde, and E. Bodden, “Fluently specifying taint-flow queries with fluent tql,” Empirical Software Engineering, vol. 27, no. 5, p. 104, 2022

    2022

  41. [41]

    Secucheck: Engineer- ing configurable taint analysis for software developers,

    G. Piskachev, R. Krishnamurthy, and E. Bodden, “Secucheck: Engineer- ing configurable taint analysis for software developers,” in 2021 IEEE 21st International Working Conference on Source Code Analysis and Manipulation (SCAM). IEEE, 2021, pp. 24–29

    2021

  42. [42]

    IRIS: LLM-assisted static analysis for detecting security vulnerabilities,

    Z. Li, S. Dutta, and M. Naik, “IRIS: LLM-assisted static analysis for detecting security vulnerabilities,” arXiv preprint arXiv:2405.17238, 2024

    Pith/arXiv arXiv 2024

  43. [43]

    QLCoder: A query syn- thesizer for static analysis of security vulnerabilities,

    C. Wang, Z. Li, S. Dutta, and M. Naik, “QLCoder: A query syn- thesizer for static analysis of security vulnerabilities,” arXiv preprint arXiv:2511.08462, 2025

    arXiv 2025

  44. [44]

    Multi-language dynamic taint analysis in a polyglot virtual machine,

    J. Kreindl, D. Bonetta, L. Stadler, D. Leopoldseder, and H. Mössenböck, “Multi-language dynamic taint analysis in a polyglot virtual machine,” in Proceedings of the 17th International Conference on Managed Programming Languages and Runtimes, ser. MPLR ’20. New York, NY , USA: Association for Computing Machinery, 2020, p. 15–29

    2020

  45. [45]

    Augur: Dy- namic taint analysis for asynchronous javascript,

    M. W. Aldrich, A. Turcotte, M. Blanco, and F. Tip, “Augur: Dy- namic taint analysis for asynchronous javascript,” in Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering, 2022, pp. 1–4

    2022

  46. [46]

    Creating concise and efficient dynamic analyses with alda,

    X. Cheng and D. Devecsery, “Creating concise and efficient dynamic analyses with alda,” in Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, 2022, pp. 740–752

    2022

  47. [47]

    Debugging webassembly? put some whamm on it!

    E. Gilbert, M. Schneider, Z. An, S. Thalanki, W. Bowman, A. Y . Bai, B. L. Titzer, and H. Miller, “Debugging webassembly? put some whamm on it!” Proceedings of the ACM on Programming Languages, vol. 9, no. OOPSLA2, pp. 2058–2086, 2025

    2058