Hi everyone, I’m trying to import a SARIF report (the Semgrep Output with the --sarif option) into SonarCloud, everything good except that the filename and row numbers are not showing on the GUI.
I’m using SonarQube community version 10.2.1.78527 deployed with Docker.
The following is how Sonar is displaying the issues.
Is this feature supported or do I need to resort to another solution?
Thank you in advance
Hi,
Welcome to the community!
It looks like the underlying files aren’t being analyzed…? What language / extension are they in?
Ann
Hey Riccardo did you ever figure this out? I am running into the exact same issue with the same tool (Semgrep OSS).
In my case, I’m running into the issue with both Typescript and YAML files. Sonarqube reports issues in the same Typescript files being linted by Semgrep OSS. Sonarqube issues show output for where the finding is under “Where is the issue?”, but in the SARIF imported finding, I see nothing in “Where is the issue?”.
I testing on Sonarqube 10.4.1 and SonarScanner 5.0.1.3006
Hi @mr-rogers,
Welcome to the community!
Could you provide your analysis log?
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.
This guide will help you find them.
Thx,
Ann
Hey G Ann,
Let me share my findings. The reason I wasn’t able to view imported the SARIF files was due to how SonarQube handles the ‘uri’ of the finding. The uri in the SARIF finding must exactly match the path that SonarScanner detects the corresponding file in during its own scan. A few other things, in the current implementation of SonarQube, uriBaseId is parsed but ultimately ignored and not prepended to the path, so you cannot have relative paths in your SARIF files. Additionally, SonarQube is very picky about rows and colums in your SARIF files. Semgrep has a yet to be reported bug in SARIF files generated by scanning YAML files. It generates an endColumn that is off by 1. SonarQube detects this and will throw an error if the column on the line does not exist.
The uriBaseId behavior did throw me off a bit because my understanding of the SARIF spec is that if the consumer (SonarQube) requires an absolute uri (which it did during my testing) then it needs to resolve uriBaseId to an absolute URI and combine it with the relative path in uri. I believe this is a bug in SonarQube’s handling of SARIF files.
Hi @mr-rogers,
Thanks for the followup. I’m going to refer this internally for the questions on how (whether?) we’ve interpreted the SARIF spec here.
Thx,
Ann
Hi there,
We have know issues around parsing the locations (See this ticket for example).
To help a bit with the investigation, could you provide an example of your SARIF.
Furthemore, it would also be helpful to have the logs as asked by Ann:
Thanks in advance
