[joshiste]

The build stage used goreleaser/goreleaser:v2.18.3 (ships go1.27.1) with GOTOOLCHAIN=go1.27.2+auto, which pins Go to 1.27.2 until bumped by hand. That image is currently flagged for CVE-2026-111943 (stdlib, fixed in 1.27.3).

The build stage now uses the floating golang:1.27-alpine image and copies only the goreleaser binary from the same goreleaser image tag. git and make are installed because goreleaser and the licenses-report hook need them; the rest of the goreleaser image's tooling (syft, cosign, docker, …) isn't used by goreleaser build.

Checked locally with extension-azure: old and new builds have identical build settings, dependencies and licenses; only the Go version changes (1.27.2 → 1.27.3). Trivy reports no HIGH/CRITICAL findings for the new image.

🤖 Generated with Claude Code

[claude]

Claude finished @joshiste's task in 14s —— View job

---

PR review

No blocking issues found in the Dockerfile change.

• .goreleaser.yaml sets CGO_ENABLED=0, so building on musl (golang:1.27-alpine) doesn't affect the output binary.
• The before hooks use go mod download and make licenses-report. Both are covered by the Go toolchain and the git and make packages you install.
• Removing GOTOOLCHAIN=go1.27.2+auto is safe. go.mod declares go 1.26.0, which the floating 1.27 image satisfies without a toolchain download.
• Copying /usr/bin/goreleaser from the pinned goreleaser image keeps the goreleaser version reproducible.

One note, not a blocker: the floating golang:1.27-alpine tag trades reproducibility for automatic patch pickup. That is the stated goal. I haven't run the Docker build myself, so the CI build is the check.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud