Images ship /usr/bin/pebble built with Go 1.26.5 (8 fixed HIGH stdlib CVEs); is it needed at runtime?

[AndreyZa]

Summary

ghcr.io/slinkyproject/*:26.05-ubuntu26.04 images ship /usr/bin/pebble (v1.32.1), built with Go 1.26.5. Trivy reports 8 fixed HIGH stdlib CVEs from that binary alone. The Ubuntu package layer is clean (0 findings), so pebble is the only source of HIGH findings in these images.

Scanned

trivy image --scanners vuln --severity HIGH,CRITICAL --ignore-unfixed \
  ghcr.io/slinkyproject/slurmd:26.05-ubuntu26.04

Target	Type	HIGH
ghcr.io/slinkyproject/slurmd:26.05-ubuntu26.04 (ubuntu 26.04)	ubuntu	0
usr/bin/pebble	gobinary	8

Same result for login (and for our images derived from both). CVEs: CVE-2026-33818, CVE-2026-39821, CVE-2026-46600, CVE-2026-56853, CVE-2026-56858, CVE-2026-56859, CVE-2026-56860, CVE-2026-56862 — all fixed in Go 1.25.13 / 1.26.6 / 1.27.0-rc.3.

This is not stale-image drift: the images rebuilt on 2026-09-03 (Slurm 26.05.4) still carry the same pebble build, so rebuilding alone does not clear it.

Observations

• The binary is not owned by any dpkg package (dpkg -S /usr/bin/pebble → no path found) and pebble does not appear in schedmd/slurm/26.05/ubuntu26.04/Dockerfile, so it looks like it arrives from the build toolchain rather than by intent.
• pebble version reports client v1.32.1, no server.
• In our deployment nothing executes it: PID 1 is the image entrypoint (supervisord in the login pod), and pebble never appears in the process tree.

Questions

1. Is pebble required at runtime by any of these images? If it is not, could it be dropped from the final layers?
2. If it is required, could the images be rebuilt against Go 1.26.6+ so the stdlib CVEs clear?

Happy to test a candidate image on our cluster (4 nodes, Slurm 26.05, operator 1.2.1) and report back.