Hi,
We are evaluating SonarQube and SonarCloud on C++ code using Azure DevOps pipelines.
SonarQube detects “OWASP Top 10” issues ok, However, we found SonarCloud did not find the same issues.
Specifically, we tried code with a call to OpenSSL EVP_aes_256_cbc() that should trigger the “Use a secure mode and padding scheme” rule.
Any ideas why it is not flagged? I have checked that this rule is enabled; we have not changed the default rules in SonarCloud.
What’s detected in a C++ analysis can be dependent on the build environment.
Can you share your analysis log, and the build_wrapper_dump.json for both files?
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.
Whilst creating a small test case, I found that SonarCloud detected and reported the OWASP issue!
Then I created a PR which just touched the offending line in the original source file by adding a space, and again SonarCloud detected and report the OWASP issue.
So, why didn’t it detect the issue in existing code in the Main branch?
Is there a way for force SonarCloud to rescan the Main branch?
Hi Ann,
Sorry, I can’t provide the logs & output files at the moment.
However, I did find a workaround/clue to the problem. I was running build-wrapper-linux-x86-64 with parallel make. Once I changed to sequential make, SonarCloud detects the OWASP Top 10 issues. Maybe there are other things that were not being detected as well.
Anyway, thanks for you help.
Phil
I created a test case that I ran through SonarCloud and SonarQube, logs attached.
SonarQube flags “Use stronger SSL and TLS versions” for using curl_easy_init() function, but this is not reported by SonarCloud. However, since both pick up an issue with “Use a secure mode and padding scheme” elsewhere, I know they are being scanned.
The only thing I can think of is that we run the SonarCloud build-wrapper inside a Docker container, but the analysis is done outside the Docker container afterwards, in the Azure DevOps pipeline.
logs.zip (7.6 KB)
Any idea what is going on here?
Thanks
Phil
I had to fix up the paths with sed because they are different in the Docker container vs the Azure build-agent.
Yes, both were with a full clean build.
I wonder if it’s because the Azure build-agent doesn’t have packages required to build the code?
Are you wondering if the build agent has the packages, or do you know it doesn’t and are wondering if that’s the cause? Because if it’s the latter, then yes, that’s the problem.
Hi Ann,
Ah, I know the build agent doesn’t have all the packages. We’ll probably have to run the build agent in a docker container so that we can control the versions of packages installed.
That or run the SonarCloud analysis inside our docker container that is used for building… I couldn’t find any info on how to do that though.
Phil
Let me start by pointing out that you’ve jumped into the SonarQube docs. The information should be basically the same, but in case there’s confusion in the future…
Anyway, right after the section you linked to, it says:
Scanning projects that contain C, C++, or Objective-C code requires some additional analysis steps. You can find full details on the C/C++/Objective-C language page.
Jumping to those docs, and scrolling down a bit, we find (emphasis mine):
The Build Wrapper collects information about the build, including absolute file paths (source files, standard headers, libraries, etc…). Later on, SonarScanner CLI uses this information and needs to access those paths. While this is straightforward when running these two steps on the same host, it is worth considering when using any containerization. A consequence of this is that C/C++/Objective-C analysis is NOT supported by SonarScanner CLI Docker image.
Yes, I saw the docs are for SonarQube, but it’s basically the same
I think I may have mislead you wrt using a docker container… We are not using the SonarScanner CLI Docker image, we are using our own Docker image for building. The hope is that I can run both build-wrapper and sonar-scanner inside our own docker container so there won’t be this path problem and it will just work.
Perhaps I am deluding myself!
I’m just wondering how the SonarCloudAnalyze task interacts without using a token. There most be some way of doing this without putting a token into the azure yaml.