CMP-4716: Bump Go to 1.25.14 to fix stdlib CVEs

[Vincent056]

Description

Same change as #1400 (release-1.9), for release-1.10 so that 1.10.0 does not ship with a vulnerable Go standard library.

Compliance Operator is built with Go 1.25.11, which predates the Go 1.25.13 security release. Trivy on the operator image (the "Security scan for Compliance Operator image" check) reports 8 HIGH stdlib CVEs in usr/local/bin/compliance-operator.

This bumps the toolchain to Go 1.25.14 in the three places that must stay in sync (the images/operator/Dockerfile build fails if go.mod and the builder disagree):

• go.mod: go 1.25.14
• build/Dockerfile: golang:1.25.14 (the image the Trivy scan workflow builds)
• images/operator/Dockerfile: openshift-golang-builder pinned to v1.25.14-202609021839.p0.gedd1cdd.assembly.stream.el9 (Konflux)

The Konflux builder is pinned to the el9 NVR tag on purpose: the floating v1.25.14 and v1.25 tags on brew currently resolve to the RHEL 8 build (golang-1.25.14-1.el8_10), while the v1.25.11 we build with today is el9. There is no v1.25.13 builder; 1.25.14 is the first patch on the 1.25 line that carries the fixes.

CVEs fixed (all Go standard library, fixed in Go 1.25.13): CVE-2026-56860 (net/url), CVE-2026-56859 (encoding/xml), CVE-2026-56853 (net/http), CVE-2026-56858 (html/template), CVE-2026-56862 (crypto/tls), CVE-2026-33818 (encoding/asn1), CVE-2026-39821 (net/http, x/net idna), CVE-2026-39822 (os).

Jira: CMP-4716 (trackers CMP-4580, CMP-4582, CMP-4585, CMP-4588, CMP-4591, CMP-4594, CMP-4387, CMP-4388).

Note: the open mintmaker PR #1393 ("Update golang Docker tag to v1.27.1") moves build/Dockerfile to a different Go minor without touching go.mod, which the Dockerfile version check rejects. It should not be merged on top of this.

Testing

• go mod tidy and go mod vendor with Go 1.25.14: no changes.
• go build, go vet ./... and make test-unit with Go 1.25.14: pass (17 packages).
• govulncheck -mode binary on the operator binary: only GO-2022-0451 in github.com/coreos/ignition@v0.35.0 remains, unrelated to the toolchain.
• Trivy with the workflow's settings (--severity CRITICAL,HIGH --ignore-unfixed) on the operator binary: 0 findings (8 HIGH with 1.25.11).
• go build -tags strictfipsruntime inside the pinned el9 builder image (go1.25.14 (Red Hat 1.25.14-1.el9), CGO_ENABLED=1): builds, the Dockerfile go.mod/builder version check passes, the binary runs.
• Not addressed here: the "Security scan for git repo" check flags dependency CVEs in golang.org/x/crypto, golang.org/x/mod and google.golang.org/grpc. Those need dependency bumps and are out of scope for the toolchain change.

Follow-up: master needs the same change, but its Prow build_root in openshift/release must first move from rhel-9-golang-1.25-openshift-4.21 (Go 1.25.12, GOTOOLCHAIN=local) to rhel-9-golang-1.25-openshift-4.22 (Go 1.25.14), otherwise the unit/verify jobs fail on the go directive.

Generated with Claude Code

[openshift-ci-robot]

@Vincent056: This pull request references CMP-4716 which is a valid jira issue.

Details

In response to this:

Description

Same change as #1400 (release-1.9), for release-1.10 so that 1.10.0 does not ship with a vulnerable Go standard library.

Compliance Operator is built with Go 1.25.11, which predates the Go 1.25.13 security release. Trivy on the operator image (the "Security scan for Compliance Operator image" check) reports 8 HIGH stdlib CVEs in usr/local/bin/compliance-operator.

This bumps the toolchain to Go 1.25.14 in the three places that must stay in sync (the images/operator/Dockerfile build fails if go.mod and the builder disagree):

• go.mod: go 1.25.14
• build/Dockerfile: golang:1.25.14 (the image the Trivy scan workflow builds)
• images/operator/Dockerfile: openshift-golang-builder pinned to v1.25.14-202609021839.p0.gedd1cdd.assembly.stream.el9 (Konflux)

The Konflux builder is pinned to the el9 NVR tag on purpose: the floating v1.25.14 and v1.25 tags on brew currently resolve to the RHEL 8 build (golang-1.25.14-1.el8_10), while the v1.25.11 we build with today is el9. There is no v1.25.13 builder; 1.25.14 is the first patch on the 1.25 line that carries the fixes.

CVEs fixed (all Go standard library, fixed in Go 1.25.13): CVE-2026-56860 (net/url), CVE-2026-56859 (encoding/xml), CVE-2026-56853 (net/http), CVE-2026-56858 (html/template), CVE-2026-56862 (crypto/tls), CVE-2026-33818 (encoding/asn1), CVE-2026-39821 (net/http, x/net idna), CVE-2026-39822 (os).

Jira: CMP-4716 (trackers CMP-4580, CMP-4582, CMP-4585, CMP-4588, CMP-4591, CMP-4594, CMP-4387, CMP-4388).

Note: the open mintmaker PR #1393 ("Update golang Docker tag to v1.27.1") moves build/Dockerfile to a different Go minor without touching go.mod, which the Dockerfile version check rejects. It should not be merged on top of this.

Testing

• go mod tidy and go mod vendor with Go 1.25.14: no changes.
• go build, go vet ./... and make test-unit with Go 1.25.14: pass (17 packages).
• govulncheck -mode binary on the operator binary: only GO-2022-0451 in github.com/coreos/ignition@v0.35.0 remains, unrelated to the toolchain.
• Trivy with the workflow's settings (--severity CRITICAL,HIGH --ignore-unfixed) on the operator binary: 0 findings (8 HIGH with 1.25.11).
• go build -tags strictfipsruntime inside the pinned el9 builder image (go1.25.14 (Red Hat 1.25.14-1.el9), CGO_ENABLED=1): builds, the Dockerfile go.mod/builder version check passes, the binary runs.
• Not addressed here: the "Security scan for git repo" check flags dependency CVEs in golang.org/x/crypto, golang.org/x/mod and google.golang.org/grpc. Those need dependency bumps and are out of scope for the toolchain change.

Follow-up: master needs the same change, but its Prow build_root in openshift/release must first move from rhel-9-golang-1.25-openshift-4.21 (Go 1.25.12, GOTOOLCHAIN=local) to rhel-9-golang-1.25-openshift-4.22 (Go 1.25.14), otherwise the unit/verify jobs fail on the go directive.

Generated with Claude Code

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[github-actions]

🤖 To deploy this PR, run the following command:

make catalog-deploy CATALOG_IMG=ghcr.io/complianceascode/compliance-operator-catalog:1401-712e4135ced56d5e0089ae4337e70038e3d55df1

[yuumasato]

@Vincent056 bump it in master branch as well, please

[yuumasato]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Vincent056, yuumasato

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [Vincent056,yuumasato]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment