fix: apply OS security updates to base images at build time

[rickbijkerk]

Background

The node:*-slim based Dockerfiles run apt-get update followed only by apt-get install of a few specific packages — they never run apt-get upgrade. Combined with a pinned base tag, this means OS packages inherited from the base image are frozen at its snapshot and never receive Debian security updates, so published images ship known-fixed CVEs in the base layer.

Bumping the base image tag alone doesn't reliably fix this, since the latest tag can still lag behind Debian's security patches.

Description

Add apt-get upgrade -y to the existing apt-get step in the service, migrations and CLI Dockerfiles so OS packages are patched at build time. Also adds the missing rm -rf /var/lib/apt/lists/* cleanup to migrations.dockerfile for consistency.

No application code changes — affects the published Docker images only.

Checklist

• System configuration

[gemini-code-assist]

Code Review

This pull request updates the CLI, migrations, and services Dockerfiles to run apt-get upgrade during build. To keep the resulting Docker images as small as possible, the --no-install-recommends flag should be added to the apt-get upgrade and apt-get install commands in all three Dockerfiles.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[dotansimha]

Hi @rickbijkerk , thanks for opening the PR, but I have some takeaways from using this approach:

The node:*-slim based Dockerfiles run apt-get update followed only by apt-get install of a few specific packages — they never run apt-get upgrade. Combined with a pinned base tag, this means OS packages inherited from the base image are frozen at its snapshot and never receive Debian security updates, so published images ship known-fixed CVEs in the base layer.

This could also introduce CVEs from zero-days or other packages that we don't control. And since it's not a runtime dependency, but an immutable Docker, it might end up with similar situation.

Bumping the base image tag alone doesn't reliably fix this, since the latest tag can still lag behind Debian's security patches.

I think at the moment we can begin with bumping the base image, and update specific pkg. Do you have specific packages that needs to be updated in the current image? We can use these explicitly.

Description

Add apt-get upgrade -y to the existing apt-get step in the service, migrations and CLI Dockerfiles so OS packages are patched at build time. Also adds the missing rm -rf /var/lib/apt/lists/* cleanup to migrations.dockerfile for consistency.

No application code changes — affects the published Docker images only.

This might also break Docker caching in our CI (because this runs as a first step, and Docker's layered caching is based on the order of the layers...)

[rickbijkerk]

Hey @dotansimha

I think at the moment we can begin with bumping the base image, and update specific pkg. Do you have specific packages that needs to be updated in the current image? We can use these explicitly.

That would indeed already be nice, as for specific packages the "libgnutls30, libgcrypt20" came up on our end which from what i can tell wouldnt be solved by just bumping the base image.

This might also break Docker caching in our CI (because this runs as a first step, and Docker's layered caching is based on the order of the layers...)
i also do understand this argument its a hard balancing act after all

How would you like to continue from here, will you guys take over and we close this MR ?