[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 12s —— View job

---

Review of PR #314

No issues found. Checked the Dockerfile change:

• .goreleaser.yaml sets CGO_ENABLED=0, so the alpine Go image doesn't need a C toolchain.
• git and make are installed, which covers goreleaser and the licenses hook.
• Dropping GOTOOLCHAIN=go1.27.2+auto is correct. The floating golang:1.27-alpine image now supplies the patched Go.
• The goreleaser binary is copied from the pinned v2.18.3 image, so the tool version stays reproducible.

Two things to be aware of. Neither blocks the PR:

• golang:1.27-alpine floats, so builds are no longer bit-for-bit pinned. That is the intent here.
• If goreleaser's go.mod Go directive or toolchain line ever requires a newer Go than the image ships, Go will auto-download it. That is the default GOTOOLCHAIN=local+auto behavior of the image.

I didn't build the image here.

[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