ALM used: Bitbucket Cloud
CI system used: Bitbucket Cloud (Bitbucket Pipelines, 2 CPUs available to the scanner)
Scanner command used:
mvn -B package org.sonarsource.scanner.maven:sonar-maven-plugin:sonar \
-Dsonar.branch.name= \
-Dsonar.host.url=https://sonarcloud.io \
-Dsonar.token=$SONAR_TOKEN \
-Dsonar.projectKey=dgg-devops_microservices-vermittler-ident \
-Dsonar.organization=dgg-devops \
-f application/pom.xml
sonar-maven-plugin 5.8.0.7211, sonar-scanner-java-library 4.1.2.1663, Kotlin
2.4.20, scanner engine on Java 21.0.12.1 Eclipse Adoptium (64-bit).
Client-side versions identical across all three hanging runs.
Languages of the repository Kotlin (plus XML/YAML)
Project URL: private project — organization `dgg-devops`, project `dgg-devops_microservices-vermittler-ident`
Error observed:
The analysis sporadically hangs after this line, with zero further output until
our CI kills the step at its 2-hour limit:
[INFO] Sensor KotlinSecuritySensor [security]
[INFO] 28 taint analysis rules enabled.
[INFO] Analyzing 1271 UCFGs to detect vulnerabilities.
<no further output for ~110 minutes, step killed by CI>
Three occurrences (all UTC, all killed after 2 h): 2026-09-22 ~05:55 on
develop (1185 UCFGs), 2026-09-24 ~12:21 on a PR branch (1271 UCFGs),
2026-09-28 ~12:31 on a PR branch (1272 UCFGs).
A successful analysis two hours after the second hang, with the identical UCFG count (1271) (2026-09-24 14:36 UTC, analysis ID `AaDT2Rv-hVwce8vhPxYL`,
processed on your side in 10 s), completed the entire sensor in 4.978 s:
[INFO] Analyzing 1271 UCFGs to detect vulnerabilities.
[INFO] No entry points found.
[INFO] kotlin security sensor: ... Duration: 00:00:04.978
Load type hierarchy and UCFGs: ... Duration: 00:00:00.871
Check cache: ... Duration: 00:00:00.005
Create runtime call graph: ... Duration: 00:00:00.214
Load config: ... Duration: 00:00:03.751
Compute entry points: ... Duration: 00:00:00.118
So when the analysis completes, there is essentially no taint-analysis workload
in this project (`No entry points found`). We believe this rules out memory/CPU
pressure (no progress output, no GC warnings, no OOM in any hung run) and our
code (three different branches; an analysis with the same UCFG count passes
two hours later). Background Tasks
show no trace of the hung runs — expected, since the report is never uploaded —
and 2–12 s processing for everything that arrives.
Steps to reproduce:
Not deterministically reproducible — it strikes sporadically (3 times in 7 days
on this project, which runs up to ~20 analyses on busy days). The hang window
sits between
`Analyzing N UCFGs…` and the sub-steps listed in the green-run timing above.
Since `Load config` dominates the healthy run (3.75 s) and appears to be a
server fetch, a stalled connection without a read timeout there would look
exactly like what we see. Possibly relevant: your status page shows a deployment
incident on Sept 24 and “elevated errors for CI analyses” on Sept 17.
Potential workaround:
None found that prevents the hang. We’re adding a CI step timeout as damage
control. `sonar.ws.timeout` is untested for this code path — does the security
sensor’s config/cache fetch honor it, or is there a property to time-box the
sensor so a hang fails the analysis instead of eating the CI step’s full
budget? Can you correlate our three windows with engine deployments on your
side?
Full scanner logs of all three hung runs, plus the green run’s sensor timing,
are available — happy to share privately.