trivy-engine-images-master blocking: Go 1.26.5 stdlib, x/mod v0.37.0, rds-refresh alpine openssl
trivy-engine-images-master is blocking on master since pipeline 2792878449 (job 16121930630). All four runtime images report 10 HIGH gobinary findings each; dblab-rds-refresh adds 2 HIGH alpine findings.
Three independent causes:
-
Go toolchain. Binaries are built with
golang:1.26.5, which stamps 8 HIGH stdlib CVEs into every image: CVE-2026-33818, -39821, -46600, -56853, -56858, -56859, -56860, -56862 (fixed in 1.26.6). Pins live inengine/.gitlab-ci.yml(default.imageandbuild-binary-alpine, the latter producing the shipped binaries),engine/Dockerfile.dblab-server-debug, and.gitlab-ci-security.yml(cve-govulncheck, drifted further back to 1.26.4). -
golang.org/x/modv0.37.0 carries CVE-2026-56864/-56865 insumdb/tlog. Onlymod/semveris imported (internal/retrieval/engine/postgres/physical/wal_g.go,internal/retrieval/engine/postgres/tools/db/pg.go), so the tlog code is unreachable — but Trivy matches the module version, and the scan is blocking. -
Dockerfile.rds-refreshis the only runtime image on a floatingalpine:3.23with noapk upgrade, so it shipslibcrypto3/libssl33.5.7-r0 (CVE-2026-14456, fixed in 3.5.8-r0).Dockerfile.dblab-server,Dockerfile.ci-checkerandDockerfile.dblab-clipin a digest and runapk upgrade --no-cache, which is why they report 0 alpine findings.
Fix in !1183 (merged): Go pins to 1.26.7, x/mod to v0.40.0, rds-refresh base aligned with the other three images.
Recurrence: causes 1 and 2 come back with every upstream release. The Go pin is spread across four files, so a bump has to touch all of them; worth consolidating into one variable later.