I’m using version 4.2.6, and the scanner fails with the following error:
2026-09-02T20:53:23.5298641Z 20:53:23.524 ERROR Error during SonarScanner CLI execution 2026-09-02T20:53:23.5298931Z java.lang.NoClassDefFoundError: org/bouncycastle/jcajce/util/SpiUtil 2026-09-02T20:53:23.5299223Z at org.bouncycastle.jcajce.provider.asymmetric.MLKEM$Mappings.configure(Unknown Source) 2026-09-02T20:53:23.5299551Z at org.bouncycastle.jce.provider.BouncyCastleProvider.loadServiceClass(Unknown Source) 2026-09-02T20:53:23.5299865Z at org.bouncycastle.jce.provider.BouncyCastleProvider.loadAlgorithms(Unknown Source) 2026-09-02T20:53:23.5300480Z at org.bouncycastle.jce.provider.BouncyCastleProvider.setup(Unknown Source) 2026-09-02T20:53:23.5300789Z at org.bouncycastle.jce.provider.BouncyCastleProvider.access$000(Unknown Source) 2026-09-02T20:53:23.5301089Z at org.bouncycastle.jce.provider.BouncyCastleProvider$1.run(Unknown Source) 2026-09-02T20:53:23.5301372Z at java.base/java.security.AccessController.doPrivileged(Native Method) 2026-09-02T20:53:23.5301665Z at org.bouncycastle.jce.provider.BouncyCastleProvider.(Unknown Source) 2026-09-02T20:53:23.5302016Z at org.sonarsource.scanner.lib.internal.http.HttpClientFactory.loadTrustStoreWithBouncyCastle(HttpClientFactory.java:131) 2026-09-02T20:53:23.5302512Z at org.sonarsource.scanner.lib.internal.http.HttpClientFactory.configureSsl(HttpClientFactory.java:103) 2026-09-02T20:53:23.5302896Z at org.sonarsource.scanner.lib.internal.http.HttpClientFactory.create(HttpClientFactory.java:65) 2026-09-02T20:53:23.5303256Z at org.sonarsource.scanner.lib.internal.http.ScannerHttpClient.init(ScannerHttpClient.java:53) 2026-09-02T20:53:23.5303640Z at org.sonarsource.scanner.lib.ScannerEngineBootstrapper.bootstrap(ScannerEngineBootstrapper.java:147) 2026-09-02T20:53:23.5303984Z at org.sonarsource.scanner.cli.Main.analyze(Main.java:76) 2026-09-02T20:53:23.5304270Z at org.sonarsource.scanner.cli.Main.main(Main.java:64) 2026-09-02T20:53:23.5304577Z Caused by: java.lang.ClassNotFoundException: org.bouncycastle.jcajce.util.SpiUtil 2026-09-02T20:53:23.5304915Z at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) 2026-09-02T20:53:23.5305258Z at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) 2026-09-02T20:53:23.5305595Z at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:527) 2026-09-02T20:53:23.5305845Z ... 15 common frames omitted
Hey @sebastian.bello, welcome to the Community! A few preliminary questions/troubleshooting ideas:
Could you share the SonarCloudPrepare, SonarCloudAnalyze, and pipeline-agent log lines, plus their YAML, especially any cliVersion, custom scanner installation/path, JAVA_HOME, SONAR_SCANNER_OPTS, or SONAR_SCANNER_JAVA_OPTS overrides?
Is the build agent self-hosted?
Could you clear the scanner download/cache and retry? A partial or mixed cached scanner dependency set is consistent with this missing-class error.
Are you running the scanner with Java 21+? SonarQube Cloud no longer supports scanner Java runtimes below 21.
I’m sharing the raw log with some debugging information (pipeline.txt).
The workflow implemented by the pipeline is as follows:
a Bash task runs some diagnostics (build.txt) and finally builds the application
a SAST task group runs, which includes the following tasks:
Bash
SonarCloud Prepare Analysis
SonarCloud Code Scan
SonarCloud Publish QG Result
Is the build agent self-hosted?
No, this is Azure DevOps.
Could you clear the scanner download/cache and retry? A partial or mixed cached scanner dependency set is consistent with this missing-class error.
I tried this: rm -rf ~/.sonar/cache
Is that what you mean?
Are you running the scanner with Java 21+? SonarQube Cloud no longer supports scanner Java runtimes below 21.
How can I answer this?
Hey @sebastian.bello, I see in the logs that the job runs in a /azp directory, which is typically associated with self-hosted agents. So I suspect you’re using a self-hosted build agent.
However, I don’t think that’s really the cause of the problem here. Something that seems more suspicious to me is this:
Your java -version command prints:
2026-09-08T12:05:29.4321802Z openjdk version "21.0.6" 2025-01-21
This might be a JAVA_HOME issue. The Scanner uses this variable to find the JDK to use, so you have to configure the agent/container or the SonarCloudAnalyze task environment so that its JAVA_HOME points to JDK 21.
You could try printing your JAVA_HOME to double-check what is its value.
Most likely, the manual exporting of JAVA_HOME didn’t work because it only affected that Bash process, not the later SonarCloud task. I would imagine that you would need to edit the default JAVA_HOME somewhere else in your Azure DevOps setup, but I’m no Azure DevOps expert .
However, what I can tell you for sure is that what you have done now is explicitly telling the SonarCloud Code Scan task to run the Scanner on the JRE that JAVA_HOME_17_X64 points to. Most likely, Java 17. Although this is still not Java 21, it works because it’s only used to bootstrap the Scanner. After starting, the scanner can automatically download and use a compatible JRE for the analysis when needed. Java 21 is only absolutely necessary when this automatic JRE provisioning is disabled (sonar.scanner.skipJreProvisioning).
If JAVA_HOME_21_X64 is available, I would recommend that you use that one, for future compatibility (at some point we might require Java 21 even for Scanner bootstrapping, before the JRE auto-provisioning happens).
Most likely that is because the JAVA_HOME_21_X64 env variable is not populated in your environment (no Java 21 installed on the agent) and therefore it falls back to the Java 11 available in the PATH. The logs should allow you to verify this.
.