Summary

scripts/runSonarQube.sh fails with a 300-second timeout when SonarQube's JavaScript/TypeScript sensor tries to start its Node.js "bridge server" inside the sonarsource/sonar-scanner-cli Docker container. This kills the entire scan, including the Java analysis that actually matters.

Root cause: 3 vendored JavaScript files in src/main/webapp/js/ are within the scan scope (sonar.sources="src") but not excluded:

When SonarQube detects .js files, its JS/TS sensor activates and attempts to start a Node.js-based ESLint bridge server. In the scanner Docker container, Node.js is either unavailable or the bridge fails to initialize within the 300s timeout, producing:

org.sonar.plugins.javascript.nodejs.NodeCommandException: Failed to start the bridge server (300s timeout)

Fix: Append ,**/*.js to the existing sonar.exclusions pattern so the JS/TS sensor never activates.

Why JS scanning has zero value for this project

1. Issue filtering: SonarReport.java filters rules with rule.ruleId.startsWith("java:") (line 78) -- JavaScript rules are excluded before the issues query is even sent.

2. Query filtering: The issues/search API call passes rules=<allJavaRules> (lines 43-46), so SonarQube's API never returns JavaScript findings.

3. Hotspot noise prevention: The hotspots/search endpoint (line 49) does NOT filter by language. Without the exclusion, JavaScript security hotspots from vendored jQuery could pollute the Java benchmark results.

4. Vendored code: All 3 JS files are third-party libraries or UI utilities, not project code written for the benchmark.

Changes

1 file changed, 1 line modified:

scripts/runSonarQube.sh (line 78):

-  -Dsonar.exclusions="results/**,scorecard/**,scripts/**,tools/**,VMs/**"
+  -Dsonar.exclusions="results/**,scorecard/**,scripts/**,tools/**,VMs/**,**/*.js"

What was NOT changed (and why)

• Existing exclusion patterns left intact. The results/**,scorecard/**,scripts/**,tools/**,VMs/** patterns reference directories outside sonar.sources="src" and are technically redundant. They were left in place because they are harmless, years old, and removing them is unrelated to this fix.

• .map files not excluded. jquery.min.map is a source map (JSON file) that does not trigger the JS/TS sensor (sonar.javascript.file.suffixes defaults to .js,.jsx,.cjs,.mjs). Excluding it would be solving a non-problem.

• No changes to SonarReport.java. The Java report class is unaffected.

• No changes to testcode. Zero files touched in src/main/java/org/owasp/benchmark/testcode/.

Test plan

• Run scripts/runSonarQube.sh on a machine with Docker -- the scan should complete without the Node.js bridge server timeout
• Verify the generated results/Benchmark_*-sonarqube-v*.json contains Java vulnerabilities (the JS exclusion should not reduce Java findings)
• Confirm no .js files appear in the SonarQube project dashboard after the scan