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.
Since you looked into my other two questions, I guess it might be relevant to ask you here @Loris_Sierra
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!
I am happy to provide the answer to your questions.
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!
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.