SonarQube taint analysis in JS dependencies

We are using SonarQube EE for scanning our applications. We recently encountered more cases where vulnerabilities found by a pentest were not detected by SonarQube. We don’t expect SonarQube to find each vulnerability, however in these cases I think taint analysis could have identified the issues.

It was common in both cases that the sink was located in a dependency and since it wasn’t recognized as a sensitive function, taint analysis didn’t find any problems. I know it’s debatable whether it falls within the scope for a SAST or an SCA tool to find these kind of issues, but is there a way to include dependencies in the taint analysis (even at the cost of increasing the LoC usage by including dependencies)? A similar extension is available for a few languages with Security Engine Custom Configuration. Does anything similar exist (or is it planned) for JavaScript?

Since you looked into my other two questions, I guess it might be relevant to ask you here @Loris_Sierra :slight_smile:

Hello there,

I can’t respond to everything and will redirect this to the right team. Thanks a lot for your involvement in our community!

The two different functions you provided in these two posts weren’t recognized as sinks because we didn’t support them, yet.
Still, your feedback has been precious since the work of our AppSec team is to find as many sinks as possible for all languages. We do research and rely on SonarQube/SonarCloud user feedback to find the relevant functions that could introduce vulnerabilities.

I would say that these two cases fall within the scope of SAST - Even if it could be out of scope in certain cases in other products from competitors. It would have fallen in the scope of SCA if known CVEs from the dependencies were involved in the vulnerabilities.

For the other questions, I am assigning this to the right team. Thanks again!



Hello Adam !

I am happy to provide the answer to your questions. :slight_smile:

The security analyzer will not analyze code in the node_modules folder. For one, we don’t want that to count towards your LOC, but even if that code was analyzed, it is absolutely not certain that this would lead to the vulnerabilities being found, due to a variety of technical reasons. The right solution in your case would be to implement explicit support for the OracleDB and Reach Router libraries in the security analyzer. As mentioned by @Loris_Sierra , we value your feedback and we will add support for these libraries in a future release (no ETA yet, but we will keep you posted here). Thank you! :slight_smile:

Is there a way to “force” SonarQube to scan those dependencies? Not officially. In principle, if you could add the library’s source code (ideally the original one, not the one from npm) to your source tree in a way that makes it “look” like this is your own code, then yes, it would be scanned by SonarQube (and count towards your LOC). The criterion here is that you have to essentially convince Node that when you use a require statement for the corresponding module, it would use the code that you copied into your source tree, and not the one from npm: If you manage to do that, you will also “fool” the security analyzer. I am not sure how easy that is, and we have never tried to do that so far. However, if you want to experiment with that, I would be more than happy to hear about your findings. But again: Even if you manage to do it, it is not at all guaranteed that this will end up in your vulnerabilities being found.

Unfortunately, not at the moment. I would really love to add something like this in the future. The reason that this does not exist yet is mainly due to the highly dynamic nature of JavaScript: There are no unique method signatures as in other languages that you could use as keys in your custom configuration. We will have to come up with a slightly different model that is still reasonably user-friendly. Unfortunately, nothing along those lines is planned at the moment.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.