Hi Team, We are deploying GreptimeDB in cluster mode on AWS EKS using the official images (

greptime/greptimedb:v1.2.1

and

greptime/greptimedb-operator:v0.6.1

). Our registry vulnerability scanners caught several

CRITICAL

and

HIGH

CVEs. The current release images surface several critical findings entirely located within base OS packages (

curl

,

libcurl4

,

perl

,

openssl

). Are any of these specific base OS utilities (

curl

or

perl

) actively executed or relied upon at runtime by the database or operator binaries? Do you have plans to publish hardened release tags alongside your standard releases to eliminate base OS vulnerabilities automatically?

Hi, thanks for the report. First, none of these packages (curl, libcurl4, perl, openssl) are used at runtime. They come from the ubuntu:22.04 base image. • greptimedb uses rustls and doesn’t link the system OpenSSL. It never calls curl or perl. curl is in the image only for manual debugging. • greptimedb-operator is a Go binary using Go’s native TLS. It doesn’t exec any external tools, and curl isn’t in its final image. So the findings aren’t reachable from either binary. On hardened images: we already have a distroless Dockerfile (docker/ci/distroless/Dockerfile), but it isn’t published with releases yet.

Thanks for your response and suggestion. Do you have an estimated timeline or a target release version for when you plan to officially publish these distroless/hardened image tags alongside your standard releases?

I think we can do it when 1.3 reaches GA. I’ll discuss it with the team tomorrow.

Also is there a github issue already open for it? If not happy to open one

Not yet. Happy to see it opened. Thanks.

Thanks again. We tried to open a GitHub issue but our corporate GitHub accounts can't post to external repos. Could you open one to track publishing distroless images with releases? Here is the write up

We're running GreptimeDB in cluster mode on Kubernetes and moving it to production. Our registry's scanner flags CRITICAL and HIGH findings in the current release images, all in the ubuntu:22.04 base packages:

  | Image | CRITICAL / HIGH | Packages |
  |---|---|---|
  | `greptime/greptimedb:v1.2.1` | 4 / 8 | `curl`, `libcurl4` |
  | `greptime/greptimedb-operator:v0.6.1` | 8 / 22 | `perl`, `openssl` / `libssl3` |
  | `greptime/greptimedb-initializer:v0.6.1` | 8 / 22 | `perl`, `openssl` / `libssl3` |

As you confirmed on Slack, none of these are reachable (greptimedb uses rustls; the operator uses Go native TLS and execs nothing). But our production  gate, like many organizations', treats CRITICAL findings in a production image as blocking, whatever their reachability. Our only options today are:
  - a security exception that has to be renewed for every release, or
  - building and maintaining our own forked images, which moves us off your official artifacts.
Both slow adoption, and anyone else in a regulated or compliance-gated environment hits the same wall. A published distroless image resolves it for everyone. And since docker/ci/distroless/Dockerfile already exists (from #2115), the remaining work is small: publish what's already built.

Proposal:
  - Publish distroless variants for each release, e.g. greptime/greptimedb:v1.2.1-distroless (or a separate greptime/greptimedb-distroless repository), for
    greptimedb, and equivalents for greptimedb-operator and greptimedb-initializer.
  - For the operator and initializer, which are static Go binaries, <http://gcr.io/distroless/static|gcr.io/distroless/static> would probably be enough.
  - Optionally, drop curl from the default Ubuntu runtime image, since it's only for manual debugging.

Sure

@dennis zhuang - We followed your suggestion and built distroless images ourselves: copied the official binaries onto distroless/cc + libz.so.1 for greptimedb, and distroless/static for the operator and initializer (both binaries are statically linked). All three run fine: greptimedb 1.2.1 starts, /health is OK and queries work; the operator and initializer start normally. That cleared the base-OS findings, but scanning (Trivy) shows the operator and initializer still have CRITICAL/HIGH findings compiled into the Go binaries, so a new base image can't fix them • greptimedb-operatorv0.6.1 2 critical / 35 high • greptimedb-initializerv0.6.1 1 critical / 32 high The criticals: • Go stdlib v1.25.1: CVE-2025-68121 (fixed in 1.25.7) • google.golang.org/grpc v1.68.1: CVE-2026-33186 (fixed in 1.79.3) greptimedb itself is clean on distroless (0 critical). Would it be possible to cut a v0.6.2 operator/initializer release built with Go ≥ 1.25.7 and grpc ≥ 1.79.3? That would let us run the official artifacts?

@dennis zhuang also, the Google Distroless project has removed

cc-debian12

from the distroless builds as it went EOL on July 11, 26, and they do not support or build images once in extended security support. The new latest is

cc-debian13

Sounds great.

Would it be possible to cut a v0.6.2 operator/initializer release built with Go ≥ 1.25.7 and grpc ≥ 1.79.3? That would let us run the official artifacts?

I think we can, let’s try to cut it today.

@Ambika Devarayasamudram ^