Security and update of Containers

I know there were quite a lot of discussions about docker security. I have some question regarding, running docker in rootless mode (this is what I am doing). Also I am connecting to my services (servers) via Nginx Reverse Proxy and SSL / or when I just using internal services, I am not exposing anything to the internet.

I think another issue is whether securityflaws of containerized applications (e.g. images of nextcloud, mediawiki, and a lot of other containerimages) are fixed by the docker-package-devs.

So if you choose a package -better said a Dockerimage - which is not updated continuously, you are running into a constantly growing securityproblem, cause of the not updated image.

If you are not building images yourself, you should only stick to images -lets say at which are in active development. You should not use images, which have not had an update for month, or even years.

Am I right so far, or am I seeing it too critical?

So this leads me to the final question: Should you ever use a not self built image in production?


I assume you mean the maintainer of the image repository. Some maintainers indeed to it manually, while others use pipeline jobs that does that job for them.

Patch mangement for containers is done by creating new oci images. You can use tools like Synk and Trivy to scan images for known vulnerabilities. The older the image, the more likely it comes with known vulnerabilities.

You could actually use an old image as base image and update its os packages in your own image… but the downside is the total image size will grow. But generally using old images is not a good idea, especially if they are exposed to the internet. And of course this will not work, if an old image uses a distro that reached EOL and doesn’t receive updates anymore.

What is the reason to not use official images, or images from a maintainer you trust? Official images and images from Bitnami are often used in corporate context - with extra hardening where necessary.
Every base image used to build your own image would be not a self build image - but they are patched and released on regular base.

1 Like


Thanks I did not know this!

Ok, so it is ok, to just choose a maintainer I trust / who updates on a regular base. (Beside of the update-history I also have an eye on the downloadcounter. I assume the image would not be “evil” if downloads are high and it is updated on a regular base.

Thanks a lot for your answers!

A high download count is generally a good indicator, but not necessarily a guaranty.
A good image description (on Dockerhub or linked to somewhere else) with frequent image updates (on new versions of the application or available fixes for vulnerabilities of the current image) is usually a good sign.

1 Like

Hello again,
just playing around with trivy now. To be honest I am a little shocked. I don’t know how to interpret all of the messages, but if you scan e.g.

trivy image --security-checks vuln --ignore-unfixed jc21/nginx-proxy-manager:latest

you got a lot of HIGH vulnerabilities. If I think about that the “npm” is facing to the internet normally, this can not be good…

What can you do about this? (I use the latest image of the proxy-manager). For sure I just can apt-get update && upgrade to get rid of the “debian-specific” vulnerabilities, but what about the others? (python-pkg… etc)

Chances are high that you can find the source repo on github. You can try to clone the repo and build your own up to date image. Though, it depends on the application itself what needs to be done in order to fix the vulnerabilities. Sometimes the only thing you can do is to raise an issue in the source repo.