which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
Using SonarScanner .NET Core Global Tool 5.7.2
Also using SonarQube Developer edition 8.9.7.
Our .NET project is .NET 6.0.
We’re using the SonarScanner .NET Global tool to scan our code in a Gitlab CI/CD pipeline. Our scanning script runs inside a Rhel container in our pipeline.
what are you trying to achieve
We want to scan a .NET project in a Gitlab CI/CD pipeline inside a Rhel linux container. Our rhel linux container provides the .NET sdk and open JDK.
what have you tried so far to achieve this
We are able to scan our code successfully on a Windows installation of the .NET Global tool but that solution is not containerized for our Gitlab CI/CD pipeline. It requires a dedicated Gitlab runner.
Using the same script inside the Rhel linux container though leads to errors such as
Sources cannot be empty. Rule roslyn.sonaranalyze.security.cs:S5131
and when we supply soanr.sources we get
**.cs can't be indexed twice. Please check that inclusions/exclusion patterns produce disjoint sets for main and test files.
From everything I’ve read on the SonarQube Github and Community forums, we should NOT supply the sonar.sources property at all since we’re using the SonarScanner for .NET.
The commands are use in our scanning scripts are as follows
dotnet sonarscanner begin /k:"project-key" /d:sonar.host.url="<url>" /d:sonar.login="<token>"
dotnet build
dotnet sonarscanner end /d:sonar.login="<token>"
This is almost verbatim what your your SonarScanner for .NET page suggests we do.This works using the dotnet-sonarscanner while on Windows 10 but not in a Rhel docker container. That set of commands in the Rhel container gives me
Sources cannot be empty. Rule roslyn.sonaranalyze.security.cs:S5131
Any help would be appreciated. I have not seen anything saying that the tool doesn’t work in linux except for much older version going back to 2017-2018.
As a side note, we tested the rhel docker image with the .NET scanner locally with Sonarqube Community edition 8.9.9 in a docker container and it works but when we point at our Sonarqube developer edition 8.9.7 instance on a windows 10 server it doesn’t work.
UPDATE:
Specifically the above sonar.sources error occurs right after this log statement. I saw this post, could my problem be memory limit related?
INFO: Analyzing 507 ucfgs to detect vulnerabilities
INFO: -----------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: -----------------------------------------------------------------------------
INFO: Total time: 9.549s
INFO: Final Memory: 26M/308M
INFO: -----------------------------------------------------------------------------
ERROR: Error during SonarScanner execution
java.lang.IllegalStateException: Sources cannot be empty. Rule roslyn.sonaranalyzer.security.cs:S5131
This looks like the engine is not able to read the configuration for some reason. This could be due to several reasons. Could you please share the following:
Inside the directory that you run the .NET scanner from: Is there a sonar-project.properties file and if yes, what are its contents?
Which version of the OpenJDK is provided by your RHEL container? And could it be a “special” RHEL-patched variant of it? If yes, could you try to use a vanilla OpenJDK 11?
Thank you for your responses so far. I’m unable to share a full log because the issue we’re seeing are on a secured air-gapped system with sensitive information. So we’re unable to copy the log in a reasonable way while also not revealing sensitive info. But I can manually type over the contents anything that’s needed within reason haha.
For our properties we’re using Sonar.Analysis.xml instead of a sonar-project.properties. Its contents are very minimal. Its basically blank
As for the version of OpenJDK 11 I believe it is a RHEL distro of OpenJDK. So that might be the issue.
As a further update to the situation, I turned up the log level to TRACE and it seems that the original error is actually a misnomer for the real problem.
Switching to log level TRACE shows the following error was thrown
DEBUG: Rsource file rslyn.sonaranalyzer.security.cs/sources/common.json was not read
java.security.NoSuchAlgorithmException: PBKDF2WithHmacSHA256 SecretKeyFactory not available
at java.base/javax.crypto.SecretKeyFactory.<init>(SecretKeyFactory.java:122)
at java.base/javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:168)
.......
.......
So this makes me think that maybe our RHEL OpenJDK doesn’t contain the traditional dependencies that Vanilla OpenJDK does? I’ll try your suggestion and report back.
Basically, when the engine starts, it loads some internal encrypted resources. Due to the OpenJDK build that you use, the engine cannot decrypt these resources because your OpenJDK build is missing the needed key derivation function (PBKDF2 with HMAC-SHA256). Without these resources, the engine cannot start and this is why you get the error message that you’re seeing. The message is indeed a bit of a misnomer as it refers to a consequence of that problem: The fact that a particular encrypted resource could not be read. I will see to it that we output a more meaningful error message here. Thank you for that feedback!
Right now, the only way to solve this is to make sure that you use an OpenJDK that supports this key derivation algorithm. I am not an expert on RHEL but there are probably ways to configure RHEL to use another OpenJDK build or even to install the required algorithms for the existing build (it is a shot in the dark but this may help).
TLDR - Make sure FIPS is disabled on the host and in the container.
After much troubleshooting and research, we figured out why it wasn’t working. FIPS was enabled on our host RHEL VM that our docker container runs on. On your docs. its clearly stated that SonarQube does not support FIPS. Docker containers inherit the FIPS settings of the host. Disabling FIPS on the host solved our issues with not being able to access the Cryptographic libraries for vulnerability scans. I guess FIPS was preventing the usage of the crypto libs that were needed to decrypt the json files for the Roslyn scans.
