[BUG][code-analyzer] `sf code-analyzer run ...` causes Windows Defender to spike the CPU

[SCWells72]

Have you tried to resolve this issue yourself first?

Yes

Bug Description

Any time that I run sf code-analyzer run ..., I almost immediately see a CPU spike, and MsMpEng is right alongside the host node process in CPU consumption:

The directory containing Salesforce projects is already in the exclusion list, and I don't see any issues running other sf commands from these projects. I'm guessing that something else being executed by Code Analyzer needs to be excluded, no? Any idea what that would be? I'm not comfortable excluding node altogether for what I hope are obvious reasons.

Output / Logs

I also timed command execution with and without Defender active, and the impact is pretty significant:

Defender enabled: 2m6.395s
Defender disabled: 0m49.501s

Steps To Reproduce

Run Code Analyzer on Windows with Defender enabled.

Expected Behavior

There's some safe way to configure Windows Defender exclusions so that Code Analyzer can run without spiking the CPU.

Operating System

Windows 11

Salesforce CLI Version

@salesforce/cli/2.87.7 win32-arm64 node-v22.13.0

Code Analyzer Plugin (@salesforce/sfdx-scanner) Version

code-analyzer 5.0.0 (5.0.0)

Additional Context (Screenshots, Files, etc)

No response

Workaround

No response

Urgency

Low

[stephen-carter-at-sf]

@SCWells72 did you experience the same issue with the (v4) sf scanner commands as well?

If you do not want to exclude the node_modules/@salesforce folder from windows defender, then maybe you can help narrow down the problem a bit.

First start with a code-analyzer.yml file that disabled all the engines. Then one at a time enable just the one engine. Each time just run with just that one engine enabled only. See if there is a specific engine that is causing the Windows Defender spike.

For example start with:

engines:
  cpd:
    disable_engine: false
  pmd:
    disable_engine: true
  eslint:
    disable_engine: true
  regex:
    disable_engine: true
  retire-js:
    disable_engine: true
  flow:
    disable_engine: true
  sfge:
    disable_engine: true

to just run the cpd engine and see if that spikes Windows Defender.

Then run with

engines:
  cpd:
    disable_engine: true
  pmd:
    disable_engine: false
  eslint:
    disable_engine: true
  regex:
    disable_engine: true
  retire-js:
    disable_engine: true
  flow:
    disable_engine: true
  sfge:
    disable_engine: true

to just run the pmd engine and see if that spikes Windows Defender.

and do that for all the engines.

Most of us here at Salesforce do not have Windows machines with Windows Defender - so we appreciate the help in seeing what is possibly causing the spike.

I have some hunches (that is just the engines doing their jobs) but I'm curious to see what you find first before I give my hunches.

[SCWells72]

@SCWells72 did you experience the same issue with the (v4) sf scanner commands as well?

I never really did much with v4. I'm in the process of integrating v5 into Illuminated Cloud -- which is going well aside from this spike -- and I noticed it.

See if there is a specific engine that is causing the Windows Defender spike.

Always good to minimize/isolate variables, and that got us to an answer. It's very specifically retire-js. With only that engine enabled, I see the CPU spike. With all engines but that one enable, I do not.

Thoughts on what might need to be excluded for that specific engine?

[stephen-carter-at-sf]

OK yes my hunch was confirmed.

retire-js is a tricky engine in that (in addition to just scanning .js file) it actually inspects text files that may be contained in zip folders that may be copies of known vulnerable js libraries - by first unzipping them and then analyzing them. But this behavior was also around with sf scanner. Can you confirm by trying out the v4 world and running sf scanner to see if it also spikes windows defender.

My guess is that this unzip operation is the reason why Windows Defender isn't super happy. Can you confirm whether or not the code base you are scanning contains zipped folders that either have the extension '.resource' or '.zip'? If so, what happens if you exclude those files from the scan by only targetting .js files for that engine. For example what if you just do:
sf code-analyzer run -r retire-js -t **/*.js

We currently do not have any configuration options (other than disabling the engine) for our retire-js engine. Would it make sense for us to add an option to disable zip/resource file scanning?

--- Update
Looking back at the code - I believe we also process all text files (not just .js files) and we make a copy of them with symlinks to force their extension to be .js so that we are extra thorough in our scan of possible vulnerabilities. This may also be why windows defender gets activated (because we create a ton of symlinks): https://github.com/forcedotcom/code-analyzer-core/blob/dev/packages/code-analyzer-retirejs-engine/src/executor.ts#L202

I've been on the fence of whether or not to add in a configuration option to allow users to switch to simple strategy instead of advanced strategy to avoid all this crazy copy/unizipping. But in doing so it'll only scan the js files (which is what the retireJs tool does natively). See https://github.com/forcedotcom/code-analyzer-core/blob/dev/packages/code-analyzer-retirejs-engine/src/executor.ts#L38 vs https://github.com/forcedotcom/code-analyzer-core/blob/dev/packages/code-analyzer-retirejs-engine/src/executor.ts#L131

So would that make sense for your use case... to allow you to avoid the complex operations and simply make the retire-js do a "fast" scan only?

If so, then we can make that a feature request for you and add it to our backlog. Let us know.

[SCWells72]

Can you confirm by trying out the v4 world and running sf scanner to see if it also spikes windows defender.

Given that v4 is effectively retired and I'm only looking to integrate v5 into IC, I'll probably pass on doing anything with the older version. Sorry.

My guess is that this unzip operation is the reason why Windows Defender isn't super happy. Can you confirm whether or not the
code base you are scanning contains zipped folders that either have the extension '.resource' or '.zip'?

So this is interesting. It occurred to me that this was happening when I would run Code Analyzer without a target directory in which case it's working against the entire project's contents. I specified force-app/main/default as the target directory with retire-js enabled, and I don't see the issue. IC itself does generate a file called OfflineSymbolTable.zip that is effectively an org-specific SDK, and I'm assuming the issue arises when retire-js tries to evaluate the contents of those files.

So perhaps this is more of a special case, but I will say that I've worked on a number of projects that have *.zip, *.jar, etc., files under the project directory, and that could present an issue with this engine. It might be good to have an option to skip archive files.