sonarqube/25.7.0.110598-r0: cve remediation

[octo-sts]

sonarqube/25.7.0.110598-r0: fix GHSA-j288-q9x7-2f5v

Advisory data: https://github.com/wolfi-dev/advisories/blob/main/sonarqube.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

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 step

Root Cause Analysis 🔍

The build is attempting to run pombump on pom.xml, but this file doesn't exist in the repository. This could be because the Sonarqube project is structured differently than expected or the build is not being run from the correct directory.

---

🔍 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.yaml

• remove at line 45 (pipeline section)
  Original:

  - uses: maven/pombump

Click to expand fix analysis

Analysis

The similar fixes show a common pattern when dealing with the "failed to parse the pom file: open pom.xml: no such file or directory" error. In both cases, projects were using build systems other than Maven (Ant for Cassandra and Bazel for Selenium), but the build configuration incorrectly included a maven/pombump step without specifying a custom path to the pom file. The fixes involved either:

1. Specifying a custom path to an existing pom.xml file in the repository (Cassandra fix)
2. Completely removing the maven/pombump step since it wasn't needed (Selenium fix, which used patches instead)

In the current failure, SonarQube uses Gradle as its build system, not Maven, explaining why pom.xml is missing at the root level.

Click to expand fix explanation

Explanation

The build failure is occurring because the SonarQube package configuration is attempting to use the maven/pombump tool on a pom.xml file that doesn't exist. SonarQube is a Gradle-based project, not a Maven project, as evidenced by the build step that runs ./gradlew build.

Removing the maven/pombump step completely is the most appropriate solution because:

1. SonarQube doesn't use Maven - it uses Gradle as its build system
2. There is no pom.xml file in the repository, making the maven/pombump step irrelevant
3. The build already has a patch step for handling security fixes (GHSA-hq9p-pm7w-8p54-remediation.patch)
4. The gradlew build command runs right after the pombump step, which is the actual build mechanism for this project

After removing this step, the build should proceed directly from the git-checkout step to the patch step, and then to the Gradle build process, without attempting to find or modify a non-existent pom.xml file.

Click to expand alternative approaches

Alternative Approaches

• If there are specific dependency version updates needed, create a custom patch file that modifies the appropriate Gradle build files (build.gradle or similar) and apply it using the existing patch step.
• If there is actually a pom.xml file in a subdirectory of the project, modify the maven/pombump step to specify the correct path using the 'pom' parameter similar to the Cassandra fix.
• If dependency version management is crucial, consider writing a custom script that modifies the appropriate Gradle files directly in a 'runs' step instead of using maven/pombump.

---

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

[vishal-chdhry]

superseded by #59061