GeezerVison

What

One-line pin bump in java-21/java.version:

• 21.0.11-21.50 → 21.0.12.1-21.52

This file pins the Azul Zulu OpenJDK build used by java-21/Dockerfile (FROM azul/zulu-openjdk-debian:${JAVA_VERSION} → jlink'd custom JRE → published as the floating tag hypertrace/java:21).

Why

Snyk container scans flag openjdk-jre 21.0.11 (the current pin) with 2 High CVEs whose fix version on the 21 train is 21.0.12 (July 2026 CPU). The new pin 21.0.12.1-21.52 is Azul's August 2026 build = OpenJDK 21.0.12.1, which includes the July 2026 CPU plus Azul's August 2026 monthly security patch (CSPU).

Every Traceable service image inherits this JRE via the hypertrace/java:21 floating tag (the org.hypertrace.docker-java-application-plugin gradle plugin defaults baseImage to hypertrace/java:<javaMajorVersion>; no service overrides it). Bumping this pin fixes the findings for all consuming services on their next image build — config-service is the immediate blocker (its PRs are gated by a Snyk container scan).

Verification

The target tag is verified to exist on Docker Hub: azul/zulu-openjdk-debian:21.0.12.1-21.52 — multi-arch (amd64 + arm64), published 2026-09-10.

Blast radius / publish flow

• CI (pr-build.yml) reads java-21/java.version and passes it as the JAVA_VERSION build-arg to docker build, then Trivy-scans the built image — so this PR's checks validate the new pin end-to-end.
• Merge does not auto-publish. publish.yml triggers on release creation (or manual workflow_dispatch), building multi-arch and pushing hypertrace/java:21 + hypertrace/java:21.0.12.1. A release must be cut after merge for the floating tag to update.
• Once published, all services on hypertrace/java:21 pick up the fix on their next image rebuild; unblocks the config-service Snyk gate.

Made with Cursor