kube-arangodb/1.3.0-r1: cve remediation

[octo-sts]

kube-arangodb/1.3.0-r1: fix GHSA-f9f8-9pmf-xv68

Advisory data: https://github.com/wolfi-dev/advisories/blob/main/kube-arangodb.advisories.yaml

⚠️ Deferred 1 Vulnerabilities

The following vulnerabilities are being deferred to future PRs (to avoid merge conflicts):

• GHSA-4vq8-7jfc-9cvp (Low) in github.com/docker/docker@github.com/docker/docker@v28.0.0

---

"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: Missing Dependency

package github.com/docker/docker was not found on the go.mod file. Please remove the package or add it to the list of 'replaces'

Build Details

Category	Details
Build System	Go (gobump)
Failure Point	go/bump pipeline step during dependency update

Root Cause Analysis 🔍

The gobump tool attempted to update the github.com/docker/docker package to version v26.1.5, but this package is not present in the project's go.mod file. The tool requires the package to either exist in go.mod or be explicitly listed in the 'replaces' configuration to handle missing dependencies.

---

🔍 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

• trivy/0.64.1-r2: cve remediation #61154
• gitlab-runner-17.8/17.8.3-r3: cve remediation #44039

Suggested Changes

File: kube-arangodb.yaml

• modification at line 15-18 (go/bump pipeline step)
  Original:

  - uses: go/bump
    with:
      deps: |-
        github.com/docker/docker@v26.1.5
        helm.sh/helm/v3@v3.18.5

Replacement:

  - uses: go/bump
    with:
      deps: |-
        github.com/docker/docker@v26.1.5+incompatible
        helm.sh/helm/v3@v3.18.5

Content:

Add +incompatible suffix to github.com/docker/docker dependency

Click to expand fix analysis

Analysis

All three similar fixes follow the same pattern: when the gobump tool fails because a package like github.com/docker/docker is not found in the go.mod file, the solution is to add the missing package to the deps list in the go/bump pipeline step. In examples #0 and #1, github.com/docker/docker@v28.3.3+incompatible was added to the deps list with the +incompatible suffix. Example #2 shows the same pattern for a different package (github.com/go-jose/go-jose/v3). The key insight is that these packages need to be explicitly declared in the build configuration even if they're not direct dependencies in go.mod, likely because they're transitive dependencies that gobump needs to track for security updates.

Click to expand fix explanation

Explanation

The fix involves adding the +incompatible suffix to the github.com/docker/docker package specification in the deps list. This is necessary because the Docker package uses semantic import versioning that doesn't follow Go modules conventions properly. The +incompatible suffix tells Go that this package doesn't follow semantic versioning for major version changes, which is common for packages that predate Go modules. This matches exactly what was done in the similar fixes for the same package, where github.com/docker/docker@v28.3.3+incompatible was successfully used. The gobump tool requires this explicit declaration to properly track and update the dependency for security purposes, even though it may not be a direct dependency in the go.mod file.

Click to expand alternative approaches

Alternative Approaches

• Remove github.com/docker/docker from the deps list entirely if it's not actually needed for security tracking - this would require verifying that no transitive dependencies actually use this package
• Check if the kube-arangodb project has replaced github.com/docker/docker with a different Docker client library and update the dependency specification accordingly
• Add the package to a 'replaces' configuration section if the gobump tool supports this feature, though this approach wasn't used in the similar fixes

---

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

[kbsteere]

Pull request has a conflict due to two CVEs being remediated at the same time. The simplest solution to this is to delete the proposed branch with conflict and close the PR. This will allow automation to recreate the remediation with a new branch which will not result in conflict.