Data flow analysis

SonarQube Server / Community Build
,
1

I am looking for information about how SonarQube is doing data flow analysis to determine vulnerabilities for tainted data between the source and the sink.
I found these pages with some information but i am wondering if there are any more details.

We are currently using SonarQube Community Edition Version 7.7 (build 23042)

/Anders

3

Hello Anders,

Thanks for your interest in our data flow analysis. The best way to learn how our data flow analysis is working internally is to join us, we have open positions in our Language Team in charge to develop the analyzers :wink:. The SAST feature doing taint analysis and detecting injection vulnerabilities is close-source and part of the SonarQube Developer Edition.

Maybe you could clarify why you need to know such details? Normally it’s not supposed to be required to use the product.

Thanks

2 Likes
4

Hi Alexandre!

It is not I personally that ask for this but the Security Office of the company I work for.

We have been using two other static code analyzers for the last 5 years to detect vulnerabilities.
Those have produced too many false positives and brought too much overhead.

At the same time we have been using SonarQube for detecting bugs, code smells and so on and for measuring test coverage but not for Security Reports.
Last year we started to do the Security Reports in SonarQube as well.

We now hope to be able to use SonarQube instead of the other tools and have had some meetings with our internal security office and they requested information about the data flow analysis in order to approve this.

Another thing they required was the same amount of rules or the ability to write own rules or to get rules added when needed.
That’s why we requested the new XSS rule (Missing rules to detect XSS and html injection in java servlets) since we saw that was missing.
I did write a custom rule for that myself that we used before you guys implemented it.
We have also written another custom rule since your java reflection hot spot detection is not complete.
It is missing the reflection done via java.beans.PropertyDescriptor.

regards

/Anders

5

Hello,

Thanks Anders for the clarification. I believe you could get the details you are expecting by getting in touch with us privately and talking with our presales engineers => https://www.sonarsource.com/forms/contact-us.html (put a reference to this thread in your comment to give some context).

Regarding “the same amount of rules”, I have feedback:

  • quantity doesn’t matter to me, it’s better to have fewer rules but powerful and fine tune ones with low level of false-positives
  • it’s not possible to write custom rules relying on data flow analysis for the moment - no technical problem here, it was just not identified as a need
  • but it’s possible to tune the behavior of the injection/tainted rules we are providing thanks to https://docs.sonarqube.org/latest/analysis/security_configuration/
  • it’s possible to write custom rules to raise Security Hotspots or Security Vulnerability using SonarJava API: https://docs.sonarqube.org/latest/extend/adding-coding-rules/
  • you should try to avoid to write custom rules and instead raise a Change Request here: https://community.sonarsource.com/c/suggestions/rules - if the rule is accepted by SonarSource, it will be coded and maintained by us and all the community will benefit from it

Alex

6

Hi Alexandre!

You are correct that the number of rules is not the important thing.
When I said “the same amount of rules” I should have said that the issues found in the other tools also should be detected by SonarQube.
That is the important part so if we change to only use SonarQube we will not detect fewer vulnerabilities.

/Anders