We run the official ghcr.io/zammad/zammad image and scan it with Trivy before every deployment. The large majority of the HIGH/CRITICAL findings we currently have to track and periodically re-review are Debian trixie OS packages with no fixed version available yet upstream (util-linux family, curl, gnupg, perl, libglib2.0, libheif/libde265, libxml2, ncurses, etc.) — not Zammad application code, just base-OS noise that comes along with a full Debian userland.
Would the team consider building the image on a smaller, faster-patched base instead of Debian? A couple of options, roughly in order of how big a change they’d be:
- Trim the current Debian image — audit which of these packages (perl, gnupg, ncurses, etc.) the app actually needs at runtime vs. what’s just inherited from the base Debian install and could be removed in the Dockerfile.
- Chainguard Wolfi-based image (
cgr.dev/chainguard/*images / a custom Wolfi build) — a minimal, curated package set that’s rebuilt and re-patched within hours of upstream fixes, instead of waiting on Debian’s release cycle. Still ships anapk-style package manager and a BusyBox shell, sodocker exec/kubectl execdebugging keeps working. Tradeoff: package availability is smaller than Debian’s, so anything not already packaged for Wolfi (we’d guess ImageMagick/libheif/libde265 for attachment thumbnails, and the mysql2/pg native client libs) would need a custom package built for it. - A true “distroless” (no shell, no package manager) base is probably not realistic given Zammad’s actual runtime dependencies — the entrypoint scripts need a shell, and the PGP mail feature shells out to the
gpgbinary directly, not just a Ruby gem.
Happy to help test/verify a candidate image if that’s useful.