SonarCloud not finding OWASP Top 10 in C++ code

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.

Thanks
Phil

Hi Phil,

Welcome to the community!

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.

This guide will help you find them.

 
Ann

Hi Ann,

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?

Thanks
Phil

Hi Phil,

As I said, build conditions can strongly influence analysis results. That’s why the docs say:

Execute Build Wrapper as a prefix to your usual clean build command. A clean build command should always build the project from scratch.

If it’s not built while the build wrapper is eavesdropping, then it gets overlooked by analysis.

Again, would you like to share your logs and output files?

 
Ann

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

1 Like

Hi Ann,

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

Hi Phil,

We generally say that build and analysis should happen in the same place (but if the paths match up you can maybe get away with it).

Can you confirm that it was a full, clean build both times?

 
Thx,
Ann

Hi Ann,

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?

Thanks
Phil

Hi Phil,

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.

 
:sweat_smile:
Ann

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

Hi Phil,

Just to be explicit, officially Docker isn’t supported for C, C++ analysis. (I think it’s the whole paths thing.)

 
Ann

1 Like

Hi Ann,

Can’t we use sonarscanner cli with SonarCloud per sonarscanner-from-docker-image?
That would having a custom build agent.

Thanks
Phil

Hi 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 C, C++, or Objective-C projects

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):

Important notes

  • 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.

 
HTH,
Ann

Hi Ann,

Yes, I saw the docs are for SonarQube, but it’s basically the same :wink:
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!

Thanks
Phil

Hi Phil,

If the paths stay the same, it should work.

 
Ann

Getting there… One problem you might be able to help with, my azure yaml has:

        - task: SonarCloudPrepare@1
          inputs:
            SonarCloud: "xyzServiceConnection"
            organization: "a"
            scannerMode: "CLI"
            configMode: "file"
...
        - bash: |
            docker run --user "$(build_uid)" --rm \
              -e SONAR_HOST_URL="https://sonarcloud.io" \
              -e SONAR_SCANNER_OPTS="-Dsonar.organization=a \
                                     -Dsonar.projectName=b \
                                     -Dsonar.projectKey=c" \
              -e SONAR_TOKEN="xyz" \
              $(Build.Repository.Name)-$(img):$(Build.SourceBranchName) \
              sh -c 'run-sonar-scanner.sh'

Is there an env var that I can use for SONAR_TOKEN?

Thanks
Phil

Hi Phil,

Not that I’m aware of.

Keep in mind that if you generate a project-specific analysis token, that’s all it has rights to do: analyze that one specific project.

 
HTH,
Ann

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.

Anyway, thanks Ann, you’ve been a great help!

1 Like