Analysis takes a long time to finish

Hi Dinesh,

our build is also failing for the same reasons. we have disabled above mentioned policies and it is still the same. And also we need to enable those policies back as we need vulnerability scan.

15.txt (23.0 KB)

There is a lot of ongoing improvement on the engine running security rules (which is the culprit for the performance issue you are reporting). It should be deployed soon on SonarCloud. In the meantime a workaround is to deactivate the rule.

In order for us to investigate this more deeply owuld you be able to share with us (privately ) the content of the ucfg_cs2 folder ?

Thanks in advance for your help.

can you please give your mail ID to forward the logs.

Hi Nicolas,

Can you please share your email address to share ucfg_cs2 logs.

I just sent you a private message.
You should be able to attach a zip of those file in this private message.

Hi, thanks for sharing those ucfgs. I just run that with the version currently in development which already include quite some improvements and it ran smoothly in 2 minutes.
So you’ll have to be patient and wait for this version (7.8) to be rolled out to Sonarcloud. In the meantime, as a workaround, you could deactivate the culprit rule to have an analysis that finishes (rule S5144 is causing trouble to your project)

1 Like

Seems like it is disabled from beginning but we are still facing the issue.Could you please suggest.

Hi @shravanipandarmish-g . Are you using the SonarWay Quality Profile (the built-in, default one) or a custom Quality Profile?

Could you tell us how many vulnerability rules are enabled on your quality profile? Could you post here a screenshot of the Quality Profile rules summary, like the one I posted below (as an example)?


Hi Andrei, yes we are using the default one for our quality profile as of now.

ok, @shravanipandarmish-g , we are making progress here. The idea is that the default QP contains some special rules which could be, in some edge cases, computationally expensive.

This is why my colleague asked you to deactivate rule S5144 which is slowing your analysis.

Given that you are using SonarWay, it means that S5144 is activated by default

Please read the documentation for Quality Profiles

You can read this tutorial on creating a custom Quality Profile based on the default one (SonarWay), then you must deactivate the rule S5144, and then making this new QP the default one (the tutorial is made for SonarQube :sonarqube: , but the steps are the same for SonarCloud :sonarcloud: ). Then you’ll need to run the analysis again, and you should not have the performance problem anymore.

1 Like

This is what I see for the rule. It does’nt show de-activate option for me.

the other option you would suggest us to make our custom quality profile to avoid this long running of run code analysis.

Thank You.

Are you talking about rule S5144 “Server-side requests should not be vulnerable to forging attacks” ?

This is activated by default in SonarWay, and you should disable it in your custom quality profile.

Andrei, can you suggest how to de-activate.
it is not showing us the option to de-activate as you can see in the screenshot provided by me earlier. We are assuming it is de-activated already which is why that option is not visible.


Your first step will be to create a custom profile, I’ll call it ‘J2’. Then you can copy the rules from Sonar way to J2. Then it’s time to deactivate S5144 from J2.


1 Like

Hi @ganncamp, @Andrei_Epure ,

We seem to be having a similar issue. When running the vulnerabilities (standard Sonar Quality profile), our analysis of 340K lines of code takes 27 minutes on SonarCloud. Disabling the vulnerabilities brings it down to only 2-3 minutes. See log below. Should we now remove the rules taking a long time?
S5131, S3649, S2091, S2631, S2083, S5167, S5144, S5146 all take minute to complete.

In our logging I see the following:
2019-10-09T11:57:48.1297631Z INFO: Reading UCFGs from: d:\a\1.sonarqube\out\ucfg_cs2
2019-10-09T11:57:53.5890811Z INFO: 11:57:53.576 Building Type propagation graph
2019-10-09T11:57:54.3446719Z INFO: 11:57:54.217 Running Tarjan on 156207 nodes
2019-10-09T11:57:54.9767495Z INFO: 11:57:54.654 Tarjan found 155782 components
2019-10-09T11:57:55.4407056Z INFO: 11:57:55.027 Variable type analysis: done
2019-10-09T11:57:55.4407810Z INFO: 11:57:55.03 Building Type propagation graph
2019-10-09T11:57:55.7534364Z INFO: 11:57:55.627 Running Tarjan on 156311 nodes
2019-10-09T11:57:56.1738002Z INFO: 11:57:55.905 Tarjan found 155886 components
2019-10-09T11:57:56.1955903Z INFO: 11:57:56.179 Variable type analysis: done
2019-10-09T11:57:56.1956483Z INFO: Analyzing 11120 ucfgs to detect vulnerabilities.
2019-10-09T11:58:21.0257960Z INFO: All rules entrypoints : 365 Retained UCFGs : 4776
2019-10-09T11:58:22.6701353Z INFO: rule: S5131, entrypoints: 23
2019-10-09T12:00:14.2187945Z INFO: Visited 1785 ucfgs in 111525 ms, 983209 steps
2019-10-09T12:00:14.9990379Z INFO: rule: S5131 done
2019-10-09T12:00:15.0005426Z INFO: rule: S3649, entrypoints: 236
2019-10-09T12:04:41.4147830Z INFO: Visited 3582 ucfgs in 267191 ms, 1905527 steps
2019-10-09T12:04:41.4245043Z ##[error]ERROR: Failed to find InputFile for …

2019-10-09T12:04:41.4423279Z INFO: rule: S3649 done
2019-10-09T12:04:41.4423447Z INFO: rule: S2076, entrypoints: 0
2019-10-09T12:04:41.4423654Z INFO: Visited 0 ucfgs in 0 ms, 0 steps
2019-10-09T12:04:41.4423818Z INFO: rule: S2076 done
2019-10-09T12:04:41.4424016Z INFO: rule: S2091, entrypoints: 131
2019-10-09T12:09:15.4351584Z INFO: Visited 3758 ucfgs in 273990 ms, 2123722 steps
2019-10-09T12:09:15.4356740Z ##[error]ERROR: Failed to find InputFile for

2019-10-09T12:09:15.4358197Z INFO: rule: S2091 done
2019-10-09T12:09:15.4358409Z INFO: rule: S2078, entrypoints: 0
2019-10-09T12:09:15.4447862Z INFO: Visited 0 ucfgs in 0 ms, 0 steps
2019-10-09T12:09:15.4449235Z INFO: rule: S2078 done
2019-10-09T12:09:15.4449622Z INFO: rule: S2631, entrypoints: 110
2019-10-09T12:12:01.7908833Z INFO: Visited 2884 ucfgs in 166355 ms, 1100365 steps
2019-10-09T12:12:01.7912940Z INFO: rule: S2631 done
2019-10-09T12:12:01.7913281Z INFO: rule: S2083, entrypoints: 144
2019-10-09T12:15:50.5342032Z INFO: Visited 3047 ucfgs in 228736 ms, 1708231 steps
2019-10-09T12:15:50.5354189Z ##[error]ERROR: Failed to find InputFile for

2019-10-09T12:15:50.5356203Z INFO: rule: S2083 done
2019-10-09T12:15:50.5356454Z INFO: rule: S5167, entrypoints: 16
2019-10-09T12:18:10.5102112Z INFO: Visited 1521 ucfgs in 139967 ms, 1064337 steps
2019-10-09T12:18:10.5105313Z ##[error]ERROR: Failed to find InputFile for

2019-10-09T12:18:10.5107581Z INFO: rule: S5167 done
2019-10-09T12:18:10.5107725Z INFO: rule: S5144, entrypoints: 38
2019-10-09T12:20:05.7958638Z INFO: Visited 1828 ucfgs in 115291 ms, 1033556 steps
2019-10-09T12:20:05.7959044Z INFO: rule: S5144 done
2019-10-09T12:20:05.7959118Z INFO: rule: S5145, entrypoints: 0
2019-10-09T12:20:05.8078386Z INFO: Visited 0 ucfgs in 0 ms, 0 steps
2019-10-09T12:20:05.8079428Z INFO: rule: S5145 done
2019-10-09T12:20:05.8079999Z INFO: rule: S5146, entrypoints: 65
2019-10-09T12:22:15.9004780Z INFO: Visited 1604 ucfgs in 130088 ms, 1274046 steps
2019-10-09T12:22:15.9013815Z ##[error]ERROR: Failed to find InputFile for

2019-10-09T12:22:15.9014779Z INFO: rule: S5146 done

@zaat would you be able to share (via a private message as it contains some of your code information (method names and calls)) the content of the ucfg_cs2 folder with me ?

We expect a performance decrease when running the taint engine but it seems quite big in your case and I would need to investigate things further to understand what is happening.

Thank in advance for your help.

Hi @Nicolas_Peru, I have the folder, which is roughly 16Mb. How can I best setup a private message?

Hi @Nicolas_Peru,
Have you had a chance to take a closer look at the logging?

Hi @zaat,

I had a closer look but this is quite hard to investigate without the source code. It seems that there are a lot of Objects created with a type eCSLogging.Parameter and keeping track of those objects seems to take its toll on performance.
Could you light me up about what this type refers to a bit more precisely ?


My team are also seeing the same issue. Kotlin codebase primarily, with some nodejs too.

It is rather random.

Anything else you’d like to know ?