sonarqube-10/25.5.0.107428-r1: cve remediation

[octo-sts]

sonarqube-10/25.5.0.107428-r1: fix GHSA-hq9p-pm7w-8p54

Advisory data: https://github.com/wolfi-dev/advisories/blob/main/sonarqube-10.advisories.yaml

---

"Breadcrumbs" for this automated service

• Source Code: https://go/cve-remedy-automation-source
• Logs: https://go/cve-remedy-automation-logs
• Docs: (not provided yet)

[octo-sts]

⚙️ Build Failed: Configuration

Error: failed to parse the pom file: open pom.xml: no such file or directory

Build Details

Category	Details
Build System	Maven
Failure Point	pombump pom.xml

Root Cause Analysis 🔍

The build process expected to find a pom.xml file in the root directory of the SonarQube source code, but the file was not found. This is likely because the SonarQube project may not use Maven as its primary build system at the root level, or the repository structure is different than what the build script expected.

---

🔍 Build failure fix suggestions

Found similar build failures that have been fixed in the past and analyzed them to suggest a fix:

Similar PRs with fixes

• cassandra-5.0/5.0.3-r0: cve remediation #42330
• selenium/4.28.0-r0: cve remediation #42311

Suggested Changes

File: sonarqube-10.yaml

• replace at line 46-47 (pipeline section)
  Original:

  - uses: maven/pombump

Replacement:

  # SonarQube uses Gradle, not Maven, so pombump is not needed
  # - uses: maven/pombump

Click to expand fix analysis

Analysis

The similar fixed build failures show a consistent pattern: the error "failed to parse the pom file: open pom.xml: no such file or directory" occurs when the build pipeline attempts to use the maven/pombump step on projects that don't have a pom.xml file in the expected location. In both examples (Cassandra and Selenium), the projects were using different build systems (Ant and Bazel respectively) rather than Maven.

The fix pattern generally involves one of two approaches:

1. Removing the maven/pombump step entirely if it's not needed
2. Specifying a custom path to a pom.xml file if one exists elsewhere in the project
3. Creating a custom pom file specifically for dependency management

Click to expand fix explanation

Explanation

The build failure is occurring because the maven/pombump step is looking for a pom.xml file that doesn't exist in the SonarQube repository. This is because SonarQube uses Gradle as its build system, not Maven, which is evident from the build step later in the pipeline that runs ./gradlew build.

By removing or commenting out the maven/pombump step, we allow the build to proceed without trying to process a non-existent Maven configuration. The build will then continue directly to the patching and Gradle build steps, which is the correct approach for this Gradle-based project.

This solution follows the same pattern as the fixes for Cassandra and Selenium, where the key insight was recognizing that the project uses a different build system than Maven. In the Cassandra case, they chose to specify a custom POM file, while in the Selenium case, they addressed dependency versioning through a patch file instead of using pombump.

Click to expand alternative approaches

Alternative Approaches

• If there are specific Java dependencies that need version management, we could create a custom pom.xml file in a subdirectory of the package (similar to the Cassandra fix) and point the pombump step to that file: - uses: maven/pombump with: pom: ./custom-pom.xml
• If dependency version management is needed, another approach would be to create a patch file that updates the Gradle dependency versions directly (similar to the Selenium fix) and apply it using the existing patch step
• If examining the SonarQube repository reveals a pom.xml file in a non-standard location, we could point the pombump step to that specific location using the 'pom' parameter

---

Was this comment helpful? Please use 👍 or 👎 reactions on this comment.

[dnegreira]

Current package update is blocked: #55086

In the meantime while that gets solved, we should merge this PR to remediate the CVE.