Sonarqube version: Community Edition v9.9
Deployment: Self Hosted via zip
Product Used: Sonarqube Community Edition
Languag Analysed: Kotlin
Rule affected: Broadcasting intents is security-sensitive (id: kotlin:S5320)
Its false negative because same issue has been reported by google play as an security issue but sonarqube was unable to flag it since above rule was not triggered.
Thanks for your message. In general, our Kotlin analyzer is reporting issues like this. However, there could be some reasons why you don’t see them and I need a bit more information to find it out:
I need to see a complete reproducer with imports, to understand the context. Are you inside the custom implementation of android.content.Context or anything else. For me it’s not clear, from where sendBroadcast function is coming. If it’s coming from android.content.Context or any of it’s children, it should be reported.
Do you see any other issues of the rule S5320? Is Kotlin analyzer reporting anything at all?
Could you please make sure there were no exceptions in the log or provide the full log of the analysis.
Have you changed value of the properties: sonar.java.binaries, sonar.java.libraries?
First of all, let me clear, we have used sonarqube for one big project only, for now, and these answers are based on that analysis.
Multiple occurrences of sendBroadcast exist and this rule was not triggered on any of those.
We were trying developer edition and kotlin analyser didn’t report ine issue there but, as told by sonarqube support team, that was because kotlin language does not have taint analysis support. Apart from that, none of Kotlin issues are reported in the analysis and I am currently not aware of any other issue that exists in the codebase.
We have set value of sonar.java.binaries=.
sonar.log? If yes, no there are no exceptions in it.
I think the issue is happening because you’ve set the property sonar.java.binaries to .. Could you, please, remove that property from your config and re-run the analysis?
Out of curiosity, why are you setting this property? It is extremely important for the analysis to not touch sonar.java.binaries and sonar.java.libraries unless it’s needed and you’re aware of the consequences.
Without proper values of these 2 properties (handled by the Gradle plugin, you don’t have to set them) it’s impossible for the analyzer to generate a proper semantic model, and most of the issues won’t be reported.
Actually, while we were running sonarqube analysis without this property setup, we were getting Invalid value for sonar.java.binaries error and we had to set this up. Can you suggest correct way?
Could you, please, remove setting that property to anything and analyze your project? Then you can share the logs with me and check if the issue is still not reporting.
284org.sonar.java.AnalysisException: Your project contains .java files, please provide compiled classes with sonar.java.binaries property, or exclude them from the analysis with sonar.exclusions property.
Hello @Shubhdeep_Rajput,
Sorry for the late reply, I was off last week. Could you, please, share your configuration of sonar and how you run the analysis?
@Margarita_Nedzelska We use sonarqube image in gitlab ci/cd job and standard configurations are used. Could you please elaborate which configurations would you require?
Are you using Gradle as your build system? In Gradle build file you have a sonarqube plugin. This plugin could have a configuration. So I need to look at it. And also a complete log, to investigate the issue.
@Margarita_Nedzelska We are not using gradle plugin. We are using sonarqube docker and sonarscanner-cli for the scan. I am attaching job yaml below for your reference:
Hi @Margarita_Nedzelska I have checked the second option, its still not flagging the issue. For the first one, since we have already setup project with different configurations, is there a way to reset the project with gradle settings without deleting the project?
Hi,
Could you please share to log of the analysis with Gradle?
As far as I know, if you analyze the same project and pass the same projectKey, it should be fine regardless which scanner you’re using. However, I need logs, to understand, what happened on your side.