cs-au-dk / jelly

JavaScript/TypeScript static analyzer for call graph construction, library usage pattern matching, and vulnerability exposure analysis
MIT License
317 stars 22 forks source link

Feature request: support access paths for Node.js builtin modules (standard library) #6

Open werifu opened 1 year ago

werifu commented 1 year ago

I need the feature to recognize and analyze calls to Node standard library while Jelly does not support it yet.

My planning solution:

  1. Download the source code of the standard lib from https://github.com/nodejs/node/tree/main/lib and cache them in a cache directory like /tmp/node-lib/ if cache does not exist. The version of code can be determined by process.version
  2. Resolve the path of a builtin module with the code having been downloaded in this part: https://github.com/cs-au-dk/jelly/blob/4b95271f96108d0edc502cfe9220682eb8470b8e/src/analysis/operations.ts#L384
  3. Process them as a 3rd party dependency and I think it can work
  4. Clear cache after finishing all analysis

Some details

  1. Downloading the source code should be completed before starting the analysis to avoid importing the complexity of async behaviors in many sync functions
  2. Provide some options about this: a. --ignore-builtin to disable this feature and ignore all calls to standard library such as http.get() just like what it is now. It will not download code. b. --ignore-dependencies will not analyze code inside builtin modules, which is the same as 3rd party lib. b. --cache-dir to specify the cache directory c. --keep-cache to keep the source code cache when analysis is finished.

How about my solution? I am working for this feature since I need it urgently. If it's okay after discussion, I'll open a PR when I finish it.

amoeller commented 1 year ago

Hi @werifu, thanks for looking into this! Improving the support for the Node.js standard library is on our TODO. I'm not sure the best approach is to include the library source code in the analysis, if that's what you suggest. Contact me on amoeller@cs.au.dk, then we can talk about different approaches.