Clear the stdlib and x/mod CVEs blocking the image scan gate - #464
Clear the stdlib and x/mod CVEs blocking the image scan gate#464LouisParkin wants to merge 1 commit into
Conversation
The image-pipeline evaluator runs in gate mode and reported 18 unmanaged findings (11 distinct CVEs) against both the agent and cluster-agent images, failing every build and so both required CI success checks. Go 1.25.13 fixes seven of them outright: CVE-2026-33818, CVE-2026-39821, CVE-2026-56853, CVE-2026-56858, CVE-2026-56859, CVE-2026-56860 and CVE-2026-56862 are all stdlib issues with 1.25.13 as the first fixed release. Only .go-version moves, because GOTOOLCHAIN is derived from it and the toolchain is fetched at build time - the build image currently ships 1.25.11 and does not need rebuilding for this. The other Go version references in the tree already disagree with each other upstream, so they are left alone rather than dragged into a CVE fix. golang.org/x/mod v0.40.0 clears CVE-2026-56864 and CVE-2026-56865. The accompanying x/crypto, x/net, x/sync, x/sys, x/telemetry, x/term, x/text and x/tools moves are the minimum versions module resolution requires for it, and go work sync propagates the selection across the workspace so that check-mod-tidy stays green. Every changed line in those 239 files is a golang.org/x/* version. The remaining two get dated exceptions rather than fixes: CVE-2026-46600 is a false positive here. GO-2026-5942 affects golang.org/x/net below v0.56.0, which go.mod already pins at v0.56.0, and the stdlib copy only from Go 1.26.0 to 1.26.6 - below the line we build on. The NVD CPE entry carries no version range, so Grype's CPE matcher flags every Go release under 1.26.6 while Trivy, using the Go vulnerability database, does not report it at all. The correction belongs in upstream scanner data. Worth noting this is an argument against moving to the 1.26 line before 1.26.6, which would make the finding genuine. CVE-2026-18503 is a super-linear CPU issue in csv.Sniffer.sniff() with no fix in the CPython 3.13 maintenance line, so it takes the same reason, review date and STAC-25556 tracking as the other embedded-interpreter findings on this image. Fixes #461 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Closing in favour of #463, which was opened first and solves this better. #463 fixes what this PR excepts. Go 1.26.6 clears the seven stdlib CVEs and Two corrections to what this PR claimed, in case they are useful on #463: The warning in my commit message against moving to the 1.26 line only applies The CVE-2026-18503 exception here was wrong. I read OSV's affected-versions |
1 participant
The scan gate reported 18 unmanaged findings (11 distinct CVEs) on the agent and
cluster-agent images, failing every build and both required
CI successchecks.x/net< v0.56.0 (already pinned at v0.56.0) and the stdlib copy only from Go1.26.0 to 1.26.6 — below the line we build on. NVD's CPE entry has no version
range, so Grype flags every Go under 1.26.6 while Trivy does not report it.
date and tracking as the other embedded-interpreter findings.
Two things worth a reviewer's attention:
Only
.go-versionmoves.GOTOOLCHAINis derived from it and the toolchain isfetched at build time, so the build image (currently Go 1.25.11) does not need
rebuilding. The other Go references in
update_go.pyalready disagree with eachother upstream and are deliberately left alone.
The 239-file diff is
go work sync, which CI'scheck-mod-tidyrequires. Everychanged line in it is a
golang.org/x/*version — the x/crypto, x/net, x/sync,x/sys, x/telemetry, x/term, x/text and x/tools moves are the minimum resolution
requires for x/mod v0.40.0.
Validated locally: exceptions pass the published schema, workspace resolves
x/mod v0.40.0,
go build ./cmd/trace-agentsucceeds. The gate itself can only beproven by CI here.
Note this is an argument against moving to the 1.26 line before 1.26.6, which
would turn CVE-2026-46600 into a genuine finding.
Fixes #461