I think the note you shared makes sense.

Note that, according to this documentation, the command line arguments have higher priority than environment variables. If we let the analyzer handle the environment variables, it may override the corresponding configuration key passed as command line argument, and that has higher priority.

Thanks , I’m aware of this context and possibilities, thus my last line. However, that will not happen before LTA.

Also, keep in mind that it doesn’t matter to the user where it is handled. If we change it in the future, they won’t have to change it.

I understand why an environment variable would be desirable—and I totally agree. The question that we have is about the component that should handle this environment variable.

mentioned another interesting thing, in my opinion: if we let the analyzer handle the environment variable, we can totally prevent the extraction of the node runtime; but we can’t prevent the multi analyzer artifact to be downloaded by the scanner. On the other hand, if the scanner handles the environment variable, it can decide to download the legacy analyzer (that contains no runtime) when the variable is set to false, saving some bandwidth, solving both issues raised by the customer.

, the provisioning of JRE works differently from what we did for JS. JRE is in the scanner, whereas Node.js is in the analyzer plugin as you know. Also, only ~2% of our users are running the npm scanner.

Please see the motivation for this in the description: we want to make it less painful for customers who want to avoid using our embedded Node.js. Often, they do it as part of their security policy to manually manage the runtimes. Specifically, using environment variables gives them more flexibility to configure many pipelines without going through the affected teams. From their point of view, this would also be more consistent with the JRE provisioning configuration.

In the future, we could change where Node.js is provisioned, but for now, we’re thinking about customers upgrading to the new LTA with the least friction possible.