Disabling JsSecuritySensor on feature branches?

  • ALM used: Azure DevOps
  • CI system used: Azure DevOps
  • Languages of the repository: TypeScript (Angular)

The problem

We noticed that since a couple month the SonarCloud analysis of our frontend project takes a lot of time (around 25-30 minutes). Looking at the logs, it appears that this is caused by the JsSecuritySensor:

17:55:30.832 INFO: Sensor JsSecuritySensor [security] (done) | time=1424049ms

As interesting as those rules are, I would like to disable them on feature branches, and only enable them on Pull Requests and long-lived branches like develop and master (we’re using a GitFlow strategy). Adding 20+ minutes to the analysis of every commit is unacceptable.

What I tried

Disabling the rules in the UI

I tried to disable one of those rules (S3649) using the SonarCloud web UI (Ignore Issues on Multiple Criteria), but it didn’t work, I can still see the rule being executed. Also, it does not meet the “disable only on feature branches” criteria.

Disabling the rules in the config file

I tried to disable the rules through my sonar config file, which would meet the “disable only on feature branches” criteria but isn’t officially supported. It didn’t work either, the rule was still running.

#############################################
# Disable some security rules we don't need #
#############################################
sonar.issue.ignore.multicriteria=e1,e2,e3,e4,e5,e6

# The frontend never accesses databases directly
################################################

# Database queries should not be vulnerable to injection attacks
sonar.issue.ignore.multicriteria.e1.ruleKey=jssecurity:S3649
sonar.issue.ignore.multicriteria.e1.resourceKey=**/*
sonar.issue.ignore.multicriteria.e2.ruleKey=pythonsecurity:S3649
sonar.issue.ignore.multicriteria.e2.resourceKey=**/*
sonar.issue.ignore.multicriteria.e3.ruleKey=roslyn.sonaranalyzer.security.cs:S3649
sonar.issue.ignore.multicriteria.e3.resourceKey=**/*
sonar.issue.ignore.multicriteria.e4.ruleKey=javasecurity:S3649
sonar.issue.ignore.multicriteria.e4.resourceKey=**/*
sonar.issue.ignore.multicriteria.e5.ruleKey=tssecurity:S3649
sonar.issue.ignore.multicriteria.e5.resourceKey=**/*
sonar.issue.ignore.multicriteria.e6.ruleKey=phpsecurity:S3649
sonar.issue.ignore.multicriteria.e6.resourceKey=**/*

As you can see, there are multiple S3649 rules, so I disabled them all just to be sure. But regardless, the rule was still executed.

Here’s why I believe the rule was still running despite the tries above:

17:34:05.060 INFO: rule: S3649, entrypoints: 686
17:34:05.060 DEBUG: Running rule jssecurity:S3649
17:34:05.061 INFO: Running symbolic analysis
17:34:05.063 DEBUG: Resource file jssecurity/sanitizers/S3649.json was not read
17:34:05.063 DEBUG: loaded 3 sanitizers for rule S3649
17:34:05.063 DEBUG: Resource file jssecurity/passthroughs/common.json was not read
17:34:05.064 DEBUG: Resource file jssecurity/passthroughs/S3649.json was not read
17:34:05.064 DEBUG: loaded 0 passthroughs for rule S3649
17:34:05.064 DEBUG: Resource file jssecurity/collectionHandlers/common.json was not read
17:34:05.064 DEBUG: Resource file jssecurity/collectionHandlers/S3649.json was not read
17:34:05.064 DEBUG: loaded 0 collectionHandlers for rule S3649
17:34:05.065 DEBUG: Resource file jssecurity/encoders/common.json was not read
17:34:05.065 DEBUG: Resource file jssecurity/encoders/S3649.json was not read
17:34:05.065 DEBUG: loaded 0 encoders for rule S3649
17:34:05.065 DEBUG: Resource file jssecurity/decoders/common.json was not read
17:34:05.065 DEBUG: Resource file jssecurity/decoders/S3649.json was not read
17:34:05.065 DEBUG: loaded 0 decoders for rule S3649
17:35:03.013 INFO: rule: S3649 done

So basically, is there a simple way (or any way) to disable evey JsSecuritySensor rules while we’re on feature branches, and enable those rules during Pull Requests and on long-lived branches?

Hello,

Thanks for the detailed report.

We are aware of the problem faced by JavaScript or TypeScript developers. The culprit is definitely the JsSecuritySensor as you identified it. We are working to improve the execution time and that should reach SonarCloud during the summer. For more details you can have a look at: https://jira.sonarsource.com/browse/MMF-2432

Alex

Hello Alexandre,

thank you for your answer, it’s good to know that the performance issues are being looked at.

Still, is there a reason disabling rules does not work, neither from the UI nor from the configuration file? There are some rules I’d like to disable anyway, because they make no sense in my context (for example DB-related rules as my frontend does not access any database directly).

When you are using the sonar.issue.ignore property, rules are still executed but just ignore at the end of the scan and issues are not raised according to the configuration you provided.

If you want to disable rules, you need to create a custom Quality Profile where you activate only the rules you want and apply the Quality Profile to your entire Project.
You can’t apply a different Quality Profile by branches but at least with this custom Quality Profile you will only execute the rules you need and same precious minutes because as of now, the execution time is linear according to the number of JS taint rules.

1 Like

Hi @Alexandre_Gigleux,

I can see that https://jira.sonarsource.com/browse/MMF-2432 has now been marked as resolved. Is there an estimated time frame of when this will be released ?

Our company is epxeriencing build times ten fold due the enhanced scanning of JsSecuritySensor. We would be very keen to see how much this update makes a diffrence to our build times.

John

1 Like

Hello,

It is live on SonarCloud (announcement done yesterday) and will be part of SonarQube 9.1 scheduled for the 20th of Sept.

I can’t believe you haven’t notice any improvement.

  1. What do you have today on this step: Sensor JsSecuritySensor [security]?
  2. How many LOCs of JS and TS do you have in this project?
  3. Can you share the entire logs of the scan?

Thanks
Alex

Hi @Alexandre_Gigleux ,

What casued this for us was a recent upgrade to enterprise which does this deep taint rules analysis. (Our previous version I beleive did not run this). Here is some sample logs of a slow run

INFO: Sensor JsSecuritySensor [security]
INFO: Reading type hierarchy from: /home/vsts/work/1/s/.scannerwork/ucfg2/js
INFO: Read 0 type definitions
INFO: Reading UCFGs from: /home/vsts/work/1/s/.scannerwork/ucfg2/js
INFO: 23:39:40.961186 Building Runtime Type propagation graph
INFO: 23:39:41.049589 Running Tarjan on 6945 nodes
INFO: 23:39:41.061159 Tarjan found 6945 components
INFO: 23:39:41.080028 Variable type analysis: done
INFO: 23:39:41.081793 Building Runtime Type propagation graph
INFO: 23:39:41.116195 Running Tarjan on 6945 nodes
INFO: 23:39:41.129621 Tarjan found 6945 components
INFO: 23:39:41.143359 Variable type analysis: done
INFO: Analyzing 432 ucfgs to detect vulnerabilities.
INFO: rule: S5144, entrypoints: 120
INFO: Running symbolic analysis
INFO: rule: S5144 done
INFO: rule: S2083, entrypoints: 120
INFO: Running symbolic analysis
INFO: rule: S2083 done
INFO: rule: S5131, entrypoints: 120
INFO: Running symbolic analysis
INFO: rule: S5131 done
INFO: rule: S6105, entrypoints: 120
INFO: Running symbolic analysis
INFO: rule: S6105 done
INFO: rule: S2076, entrypoints: 120
INFO: Running symbolic analysis
INFO: rule: S2076 done
INFO: rule: S5147, entrypoints: 120
INFO: Running symbolic analysis
INFO: rule: S5147 done
INFO: rule: S6096, entrypoints: 120
INFO: Running symbolic analysis
INFO: rule: S6096 done
INFO: rule: S5696, entrypoints: 120
INFO: Running symbolic analysis
INFO: rule: S5696 done
INFO: rule: S5883, entrypoints: 120
INFO: Running symbolic analysis
INFO: rule: S5883 done
INFO: rule: S3649, entrypoints: 120
INFO: Running symbolic analysis
INFO: rule: S3649 done
INFO: rule: S2631, entrypoints: 120
INFO: Running symbolic analysis
INFO: rule: S2631 done
INFO: rule: S5334, entrypoints: 120
INFO: Running symbolic analysis
INFO: rule: S5334 done
INFO: rule: S5146, entrypoints: 120
INFO: Running symbolic analysis
INFO: rule: S5146 done
INFO: Sensor JsSecuritySensor [security] (done) | time=2723024ms

@jseuren Do you confirm you are using SonarQube Enterprise Edition and no longer SonarCloud?
Which version of SQ EE?

On my side, there’s some noticeable improvement. We moved from a JsSecurity analysis taking between 12 and 25 minutes; to an analysis taking about 8 minutes. It’s still arguably slow, but much better than before!

[Edit] Thanks a lot to the development team! That’s really appreciated, the frontend developers in my team were delighted to hear about it! :slight_smile:

Thanks @marcl for the feedback!

Don’t hesitate to share the number of LOCs by language (you have the info in SonarCloud itself) and your entire logs when sharing your Analysis Duration. This helps to know if SonarCloud is below the thresholds we defined internally.
Also, if you want us to improve things, you should find a way to convince your managers to accept to share your project with us. There is a default NDA coming with SonarCloud. In case you want to participate, raise the hand and I’ll get in touch with you privately.

Hello @jseuren

Can you clarify which version of SonarQube you are using?

Hi Alexander,

We were using I believe 8.9 LTS.

We did attempt an upgrade to 9.1 this week and ran into some issues. Whilst the upgrade seems to have resolve the long build times experienced (as explained in the thread), it caused a lot of issues elsewhere due for the need to upgrade a lot of our JVM from v8 to V11 so we have had to roll back for now.

(There are approx. 30-40 repos across multiple parts of the business that were not yet in a position to upgrade to Java V11.)

Cheers

John

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