Summary
Security scanners (e.g. Trivy, Grype) often report critical/high CVEs against Alpine OS packages inside the official caddy:*-alpine images. Downstream teams then open issues asking for image rebuilds or Dockerfile changes, even when the finding is not on the Caddy Go binary and may be irrelevant to how Caddy actually runs in the container.
Recent discussion on the main repo already explains that Caddy does not depend on e.g. zlib as a C library, and that Docker image concerns belong here — see caddyserver/caddy#7568 and caddyserver/caddy-docker#455.
This issue is a request for documentation, not a claim of an exploitable flaw in Caddy itself.
Problem for users
- CI/CD gates and container registries often fail builds on any critical OS CVE, regardless of exploitability or whether Caddy uses the affected library.
- The official image Dockerfile does not run
apk upgrade, so scanner results can lag until base layers or rebuilds pick up Alpine fixes.
- It is unclear from published image docs alone what users should do: wait for Official Images rebuilds, derive an image with
RUN apk upgrade --no-cache, switch variant, or accept risk with documented rationale.
Suggested documentation updates
Please add a short section (Docker Hub image description via docker-library/docs, and/or this repo README) covering:
- Scope: Which CVE classes apply to the Alpine userspace vs the Caddy binary, and that many OS-package findings are orthogonal to Caddy’s Go runtime.
- Operational guidance for organizations that must satisfy scanners:
- Deriving from
caddy:*-alpine with RUN apk upgrade --no-cache (rebuild on a schedule), or
- Preferring a minimal/distroless-style workflow if that fits their deployment model.
- Rebuild cadence: That official image refreshes are coordinated with Docker Official Images / base image updates, with a pointer to where rebuild requests belong when appropriate.
References (public)
Thank you for maintaining the official image — clearer docs would save repeated issues and help security teams adopt Caddy without fighting scanner false positives.
Summary
Security scanners (e.g. Trivy, Grype) often report critical/high CVEs against Alpine OS packages inside the official
caddy:*-alpineimages. Downstream teams then open issues asking for image rebuilds or Dockerfile changes, even when the finding is not on the Caddy Go binary and may be irrelevant to how Caddy actually runs in the container.Recent discussion on the main repo already explains that Caddy does not depend on e.g.
zlibas a C library, and that Docker image concerns belong here — see caddyserver/caddy#7568 and caddyserver/caddy-docker#455.This issue is a request for documentation, not a claim of an exploitable flaw in Caddy itself.
Problem for users
apk upgrade, so scanner results can lag until base layers or rebuilds pick up Alpine fixes.RUN apk upgrade --no-cache, switch variant, or accept risk with documented rationale.Suggested documentation updates
Please add a short section (Docker Hub image description via docker-library/docs, and/or this repo README) covering:
caddy:*-alpinewithRUN apk upgrade --no-cache(rebuild on a schedule), orReferences (public)
apk upgradeand scanner differences (Trivy vs Grype).Thank you for maintaining the official image — clearer docs would save repeated issues and help security teams adopt Caddy without fighting scanner false positives.