jitsucom-bulker/2.11.913-r0: cve remediation

[octo-sts]

jitsucom-bulker/2.11.913-r0: fix GHSA-9mj6-hxhv-w67j

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

failed to run update. Error: package github.com/go-viper/mapstructure/v2 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 step during dependency update process

Root Cause Analysis 🔍

The gobump tool is attempting to update the package github.com/go-viper/mapstructure/v2 to version v2.4.0, but this package is not declared as a dependency in the go.mod file. This suggests either the package name is incorrect, it was removed from dependencies, or it needs to be added to the 'replaces' section of the build configuration.

---

🔍 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

• kyverno-notation-aws/1.1-r10: cve remediation #48098
• helm-push/0.10.4-r25: cve remediation #50161

Suggested Changes

File: jitsucom-bulker.yaml

• removal at line 23-24 (kafkabase go/bump deps section)
  Original:

deps: |-
        github.com/go-viper/mapstructure/v2@v2.4.0

Replacement:

deps: |-

Content:

Remove the github.com/go-viper/mapstructure/v2@v2.4.0 dependency from kafkabase modroot

• removal at line 32-33 (ingest go/bump deps section)
  Original:

deps: |-
        github.com/go-viper/mapstructure/v2@v2.4.0

Replacement:

deps: |-

Content:

Remove the github.com/go-viper/mapstructure/v2@v2.4.0 dependency from ingest modroot

• removal at line 38-39 (admin go/bump deps section)
  Original:

deps: |-
        github.com/go-viper/mapstructure/v2@v2.4.0

Replacement:

deps: |-

Content:

Remove the github.com/go-viper/mapstructure/v2@v2.4.0 dependency from admin modroot

• removal at line 44-45 (bulkerapp go/bump deps section)
  Original:

deps: |-
        github.com/go-viper/mapstructure/v2@v2.4.0

Replacement:

deps: |-

Content:

Remove the github.com/go-viper/mapstructure/v2@v2.4.0 dependency from bulkerapp modroot

• modification at line 50-53 (bulkerlib go/bump deps section)
  Original:

deps: |-
        github.com/snowflakedb/gosnowflake@v1.13.3
        github.com/go-viper/mapstructure/v2@v2.4.0
        github.com/dvsekhvalnov/jose2go@v1.7.0

Replacement:

deps: |-
        github.com/snowflakedb/gosnowflake@v1.13.3
        github.com/dvsekhvalnov/jose2go@v1.7.0

Content:

Remove the github.com/go-viper/mapstructure/v2@v2.4.0 dependency from bulkerlib modroot while keeping other dependencies

Click to expand fix analysis

Analysis

The similar build failures all follow the same pattern: the go/bump tool attempts to update a package that doesn't exist in the go.mod file. In all three examples, the fix was to remove the problematic package from the deps list in the go/bump step. This indicates that these packages either don't exist in the project's dependencies, have been renamed/moved, or are no longer needed. The pattern shows that when gobump cannot find a package in go.mod, the solution is typically to remove it from the dependency update list rather than adding it to replaces.

Click to expand fix explanation

Explanation

This fix addresses the root cause of the build failure by removing the problematic package github.com/go-viper/mapstructure/v2 from all go/bump dependency lists. The error indicates this package is not found in any of the go.mod files across the different modules (kafkabase, ingest, admin, bulkerapp, bulkerlib). Based on the patterns from similar fixes, when gobump cannot locate a package in go.mod, it means the package either doesn't exist as a dependency in those modules, has been renamed, or is no longer needed. Rather than trying to force the package into the build through replaces (which would be inappropriate if the package isn't actually used), the correct approach is to remove it from the dependency update list. This allows the build to proceed with the actual dependencies that exist in each module's go.mod file.

Click to expand alternative approaches

Alternative Approaches

• If the package is genuinely needed, check if it has been renamed or moved to a different import path and update the dependency reference accordingly
• Verify if the package exists in a different version (v1 instead of v2) and update the version in the deps list
• Add the package to the replaces section if it needs to be substituted with a different package, though this is less likely given the error message

---

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