fix: [TOOL-1291] upgrade base-image packages so rebuilds clear trixie CVEs

[claude]

Requested by Evan Culver · Slack thread

Context

TOOL-1291 — AWS Inspector (via Vanta) now reports fixed versions available for all 3 CRITICALs on this image:

CVE	Package	Installed	Fixed in
CVE-2026-8376	perl	5.40.1	0:5.40.1-6+deb13u1
CVE-2026-42496	perl	5.40.1	0:5.40.1-6+deb13u1
CVE-2026-5450	glibc	2.41	0:2.41-12+deb13u4

TOOL-1291 proposed a plain rebuild + retag. Reading the Dockerfile, a plain rebuild is not a reliable fix, which is what this PR corrects.

Why a rebuild alone isn't enough

perl and glibc (libc6/perl-base) come from the python:3.12-slim-trixie base image. The runtime stage installs only libpq-dev iputils-ping dnsutils net-tools, and apt-get install does not upgrade packages outside its argument list. There is no apt-get upgrade anywhere in the Dockerfile, and nothing pins a package version or a base-image digest.

So today, a rebuild clears these CVEs only if Docker Hub has already refreshed python:3.12-slim-trixie with the point releases. Two ways that bites:

• If the base digest hasn't moved, release.yml's cache-from: type=gha serves every layer from the GHA cache and the new tag is a byte-identical image with the same findings.
• Even when it has moved, the fix is a side effect of upstream's rebuild cadence rather than something we control — so the finding can re-fire on the next scan.

For reference, the base image currently sits at digest sha256:2f17fc044b579bab302c2e8054d3a686e2cb9a83de48e70534b94cd8ebbe06a9, last pushed 2026-09-19T08:09:26Z, i.e. after the deployed v0.3.0-sfc.4 (commit b308aa5, 2026-09-15). So in this particular instance the base has moved and a rebuild would likely have worked — but by luck, not by construction.

The change

One RUN in the runtime stage gains DEBIAN_FRONTEND=noninteractive apt-get upgrade -y between update and install. The point releases land at build time regardless of the base image's cadence, and next month's rebuild is self-healing.

Same spirit as the existing pip install --upgrade pip line directly below it (added in #2 for exactly this class of base-image CVE).

The builder stage is deliberately left alone: only /app is copied out of it, so its packages are not part of the scanned artifact, and upgrading there would just slow the build.

Verification

I could not build this locally — this environment's egress proxy returns 403 Forbidden on Docker Hub blob fetches (production.cloudfront.docker.com), so docker pull python:3.12-slim-trixie fails before any build starts. Debian's security-tracker.debian.org and deb.debian.org are blocked by the same policy, so I also could not confirm from package metadata that the 2026-09-19 base already carries deb13u1/deb13u4.

build.yml does not build the Dockerfile (it runs ruff/pyright/pytest), so CI on this PR will not exercise the change either.

Please dry-run before merging: release.yml has a workflow_dispatch whose push input defaults to false, which builds both platforms without publishing anything. That is the check this PR needs:

gh workflow run release.yml --repo sfcompute/postgres-mcp \
  --ref fix/tool-1291-apt-upgrade-point-releases

Left as a draft until that dry run is green.

What this unblocks

Tagging v0.3.0-sfc.5 off this commit and bumping image.tag in deployment/helm/postgres-mcp/values.yaml (monorepo) closes TOOL-1291 and TOOL-1292, clears the bind9 half of TOOL-1316, and retires TOOL-1202, TOOL-1135 and 3 of TOOL-1075's 4 CVEs. Known residual no-fix items are unaffected: libxml2 (TOOL-1205/1316), zlib, nghttp2.

Related: #2 (the bookworm → trixie bump this generalizes), #3 (TOOL-838, the release workflow), #9 (TOOL-862, the staging shadow that will mirror the new tag automatically).

🤖 Generated with Claude Code

https://claude.ai/code/session_01Rggiavt7EWATqozS3GUoCh

---

Generated by Claude Code

[semanticdiff-com]

Review changes with