Is using a custom MariaDB docker image advisable?

Question

I found that the official mariadb images on Docker Hub have larger amounts of vulnerabilities (even 3 with severity critical). Most of them are caused by the package golang / stdlib / 1.18.2.

I observed this the stats now for several month and was hoping for a temporary problem (and that the numbers would eventually drop). However, the situation didn't get much better (according to the numbers). This really doesn't feel like I can run this and sleep well at night. Also the official mysql containers have this issue, so that's not an option either. So I was trying, what happens if I create a very basic custom container for MariaDB myself and see what docker scout quickview would report.

I created a very basic Dockerfile:

FROM ubuntu:24.04
RUN apt-get update
RUN apt-get -y upgrade
RUN apt-get -y install --no-install-recommends mariadb-server
CMD [ "/bin/sh", "-c", "sleep", "infinity" ]

did a docker build . and a docker scout quickview:

I wanted to use an OS officially supported by MariaDB (ubuntu 24.04 is supported, 24.10 is not according to MariaDB PLC Engineering Policy, Released on 2025-02-17). But, if we would be even a bit more adventurous we could use Ubuntu 24.10 and have 0 CVEs (same Dockerfile just replacing FROM ubuntu:24.04 with FROM ubuntu:24.10):

Of course the docker container might need some adaptions to the config files to be usable. And the mariadb-port needs to be exposed and so on. But, I believe I would not need any additional packages just to run a mariadb server microservice, that would introduce additional security flaws.

IDEA: I could build my own docker image for mariaDB and monitor it's via docker scout results (automatically each night) and maybe rebuild it from time to time (maybe also test it externally and push it to a docker registry, either self-hosted or private repo on hub.docker.com).

Given MariaDB should have been tested by the maintainers of MariaDB to work with this OS, there should be no real issues with Ubuntu 24.04.

QUESTIONS:

This leaves me with the following questions:

1. Did I overlook something important?
2. Is running this container (instead of the ready-made one) the safer option? Please explain why...
3. Why is the golang / stdlib / 1.18.2 package in the official mariadb image at all? Might we be able to easily modify the image and uninstall this part by uninstalling an optional package?

Thanks for your time and support!

Answer 1

On overlooking something importance, first would be the FAQ:

• Why does my security scanner show that an image has CVEs?

The short version why the vulnerabilities are is that Docker Scout doesn't use govulncheck to validate that the one Go executable in the MariaDB container, gosu is vulnerable, so it just lists every vulnerability in the Go runtime. So for proper check:

$ go install golang.org/x/vuln/cmd/govulncheck@latest
$ go/bin/govulncheck --version
Go: go1.23.2
Scanner: govulncheck@v1.1.4
DB: https://vuln.go.dev
DB updated: 2025-04-02 16:02:03 +0000 UTC
$ podman run -v ~/go/bin/:/exec:z --rm mariadb:lts /exec/govulncheck -mode=binary  /usr/local/bin/gosu
=== Symbol Results ===
Vulnerability #1: GO-2023-1840
    Unsafe behavior in setuid/setgid binaries in runtime
  More info: https://pkg.go.dev/vuln/GO-2023-1840
  Standard library
    Found in: runtime@go1.18.2
    Fixed in: runtime@go1.19.10
    Vulnerable symbols found:
      #1: runtime.Caller
      #2: runtime.CallersFrames
      #3: runtime.Frames.Next
      #4: runtime.Func.Entry
      #5: runtime.Func.Name
      Use '-show traces' to see the other 20 found symbols
Your code is affected by 1 vulnerability from the Go standard library.
This scan also found 3 vulnerabilities in packages you import and 46
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.

Take particular note to the last sentence.

A longer version is this Docker Scout Request to make vendors part of the process, which hasn't had any visible progress yet. Indeed it was raised a very long time ago (in IT terms).

The self maintained container images are a very big time sink and there a so many ways it can fail (as numerous Stack Overflow/StackExchange answers will attest to). Preferred action is to complain very loudly at Docker Scout - loosing sleep for a false alarm that is easily remedied isn't worth it.

Why is the golang / stdlib / 1.18.2 package in the official MariaDB image at all?

The gosu Golang based executable is in the container image so that early root based actions in preparing the permissions on storage VOLUMES (/var/lib/mysql) can occur before switching to a non-root user (which can no longer prepare permissions of storage volumes). Technically can achieve the same results with a script like what SUSE did.

But please:

• Complain to Docker Scout to implement govulncheck and VEX
• Trust your Docker Official Images (and maintainer (me)) to deliver you a good, not vulnerable, working MariaDB image
• Tell me if something isn't right for you.