Multi-file scanning context propagation

[fraxken]

The idea for the next Major release is to find a way to build a new Analysis workflow capable of storing informations about multiple files and then re-iterating a second time.

Few things that could help;

• Design and implement an option to specificate when a probe should run (always, first iteration, others ?).
• Focus to solve: Detect usage of dynamic RegExps #42

[fraxken]

This is mostly a personal wish at this stage. I don’t yet have a clear plan for how to implement it in a concrete way—especially while keeping the results genuinely useful for legitimate detection.

Right now, multiple files are handled through the EntryFileAnalyser API. My idea is to make the scanner “follow the trail” across related files: if something suspicious is detected in one file, the scanner should be able to trace it back (or forward) through imports/usages and report findings in the connected files as well.

The overall idea make sense but seem fucking hard to execute (while dealing with edge cases).

[7amed3li]

Hey @fraxken!

I've been thinking about this issue for a while now, and I recently did some deep research to explore potential solutions. I'd love to share my findings and discuss a possible approach with you!

Research Overview

I analyzed 17 different sources including academic papers (TAJS, Augur, Ichnaea) and industry tools (CodeQL, Joern, Semgrep, SonarQube) to understand how cross-file analysis is typically implemented.

Key Patterns Identified

Pattern	Inspiration	How it applies
Two-Phase Analysis	TAJS, Semgrep	Initial scan → Build context → Re-analyze
Unified Graph Model	CodeQL, Joern CPG	Combine AST + Data Flow + Control Flow
Incremental Symbol Table	TypeScript LS	Efficient cross-file symbol resolution

Proposed Approach

Building on the existing EntryFilesAnalyser and digraph-js, I'm thinking of:

1. Multi-Phase Analysis

   • Phase 1: Current initial scan
   • Phase 2: Build shared context (exports/imports map, symbol table)
   • Phase 3: Taint propagation across file boundaries
   • Phase 4: Re-analysis with enriched context

2. Enhanced Probes with a runPhase option

   • Probes can specify: "initial", "reanalysis", or "both"
   • New probes for cross-file vulnerability chains

3. Cross-file Context Store

   • Track exported/imported symbols
   • Propagate "suspicious" markers across imports

Questions

1. Does this direction align with what you had in mind?
2. Would you prefer I start with a minimal PoC for the two-phase approach?
3. Any specific edge cases I should consider early on?

Happy to discuss further or adjust the approach based on your feedback ^-^

[fraxken]

@7amed3li There are definitely some good ideas but the issue itself is about defining the specification and boundary of the problem (also finding real world usage where this work could be used/useful).

Implementing the code is the easy part here ^-^

On the approach:

1. We do not want a warmup phase, JS-X-Ray is currently a one-phase (pass) scanner. The idea here is more about implementing intelligence to extend to one or many additional phases when required to trace down a potential malicious code that use multiple files.
2. Not a bad idea but by itself that's a useless feature for current probes.
3. We can deeg more on that but anyways CommonJS is a hard beast to beat (you always have to giveup at some point)

Maybe exploring a new API to mark/signal suspicious location (ESTree) node in a given sourceFile would already be a good start.

Also try to drop LLMs to format answer and try to do it a bit more by yourself. Myself and the other maintainers prefer imperfect humain interaction instead of doubting if we are just exchanging with an LLM ^-^.