fix: remediate console image go vulnerabilities

[plural-copilot]

Summary

• remediate the console image build path in pluralsh/plural-cli
• upgrade Go pins used by the image from 1.26.4 to 1.26.5
• update github.com/google/go-containerregistry to a newer pseudo-version and refresh go.sum
• align helper/test container images with the new Go version

Repo and build path

• repo identified: pluralsh/plural-cli
• affected image build path: .github/workflows/ci.yaml jobs build-image and publish-image
• Dockerfile used: repo root Dockerfile

Files changed

• Dockerfile
• go.mod
• go.sum
• hack/gen-client-mocks.sh
• hack/lib.sh
• test.Dockerfile

Versions before / after

• Go directive: 1.26.4 -> 1.26.5
• Docker builder/final image: golang:1.26.4-alpine3.22 -> golang:1.26.5-alpine
• helper/test image pins: 1.26.4 -> 1.26.5
• github.com/google/go-containerregistry: v0.21.7 -> v0.21.8-0.20260624172245-e8b2b9e51df6
• oras.land/oras-go/v2: remains transitive in the module graph at v2.6.1

oras-go note

oras.land/oras-go/v2 is not directly imported by this repo's application code. It is present transitively in the module graph (for example via Helm-related dependencies). I attempted the minimal direct bump first, but there is no newer tagged oras-go/v2 release available from the Go module registry than v2.6.1, so the PR instead updates the upstream dependency graph that brings it in and documents the remaining upstream constraint.

Validation

• verified GHCR image workflow path in .github/workflows/ci.yaml
• verified module graph in a golang:1.26.5-bookworm container
• attempted go test ./... in container; run was dependency-download heavy and did not complete within the session window
• attempted docker build --load --build-arg APP_VSN=dev --build-arg APP_COMMIT=test --build-arg APP_DATE=2026-07-09T00:00:00Z -t plural-cli:test .; build progressed through dependency download after correcting the base image tag, but did not complete within the session window

Why this is minimal

• only updated the files that control the published image path or related pinned Go helper images
• kept transitive vulnerability remediation as surgical as possible given current upstream release availability

[plural-copilot]

This PR was generated by the codex Plural Agent Runtime. Here's some useful information you might want to know to evaluate the ai's perfomance:

Name	Details
💬 Prompt	Create a PR to remediate vulnerabilities in the Docker image ghcr.io/pluralsh/console:sha-bc28808....
🔗 Run history	View run history

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	github.com/​google/​go-containerregistry@​v0.21.7 ⏵ v0.21.8-0.20260624172245-e8b2b9e51df6

View full report

[greptile-apps]

Greptile Summary

This PR remediates Go vulnerabilities in the console image build path by bumping the Go toolchain from 1.26.4 to 1.26.5 and upgrading github.com/google/go-containerregistry to a security-fix pseudo-version (v0.21.8-0.20260624172245-e8b2b9e51df6). All helper and test container images are aligned to the new version.

• Dockerfile updates both builder and final stages to golang:1.26.5-alpine, but drops the Alpine minor-version pin (alpine3.22 → alpine) that was present before; test.Dockerfile correctly retains its OS variant (-bookworm).
• go.mod bumps the go directive and upgrades go-containerregistry to a pre-release pseudo-version, which is the minimal change needed given no newer tagged release is available upstream.
• hack/lib.sh and hack/gen-client-mocks.sh are consistently updated to golang:1.26.5.

Confidence Score: 4/5

Safe to merge as a vulnerability remediation; the only actionable change is restoring the Alpine minor-version pin in the Dockerfile.

All changes are straightforward version bumps with consistent treatment across files. The one deviation is the Dockerfile dropping the specific Alpine version suffix (alpine3.22 to alpine), which reduces build reproducibility compared to the previous state and the approach used in test.Dockerfile. Everything else is correctly aligned.

Dockerfile — both stages dropped the Alpine minor-version pin.

Important Files Changed

Filename	Overview
Dockerfile	Go version bumped to 1.26.5 but Alpine OS version pin was dropped (from alpine3.22 to unqualified alpine), reducing image reproducibility
go.mod	Go directive bumped to 1.26.5 and go-containerregistry updated to a pseudo-version pre-release commit for vulnerability remediation
go.sum	Checksums updated to match the new go-containerregistry pseudo-version; no issues
hack/lib.sh	Default containerize image version bumped from 1.26.4 to 1.26.5; straightforward and consistent
hack/gen-client-mocks.sh	CONTAINERIZE_IMAGE bumped from golang:1.26.4 to golang:1.26.5; straightforward version pin update
test.Dockerfile	Base image bumped from golang:1.26.4-bookworm to golang:1.26.5-bookworm; consistent OS variant retained

_{Reviews (1): Last reviewed commit: "fix: remediate console image go vulnerab..." | Re-trigger Greptile}

[greptile-apps]

The previous tag golang:1.26.4-alpine3.22 pinned both the Go version and the Alpine minor version, ensuring reproducible builds regardless of when the image is pulled. Dropping to the unqualified alpine tag means the Alpine OS version can silently advance if the tag is updated upstream or the image is pulled fresh in a new environment. test.Dockerfile retained -bookworm for the same reason, so keeping the Alpine minor version here would be consistent. Check Docker Hub to confirm the correct tag (e.g. golang:1.26.5-alpine3.22) and apply it to both stages.

Suggested change

	FROM golang:1.26.5-alpine AS builder
	FROM golang:1.26.5-alpine3.22 AS builder

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Same Alpine version pin concern as the builder stage — the final stage should match.

Suggested change

	FROM golang:1.26.5-alpine AS final
	FROM golang:1.26.5-alpine3.22 AS final

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!