Top ten most popular docker images each contain at least 30 vulnerabilities

[wwwampy]

What do you guys think about that:

https://snyk.io/blog/top-ten-most-popular-docker-images-each-contain-at-least-30-vulnerabilities/

 

[WST16]

I don’t know what to think! I’m still struggling trying to run things on Docker

 

[fredbert]

This is probably the biggest issue I have with the Docker respository(ies) ... many applications have multiple containers available and from different sources. It's difficult to know which is the safe(st) one to use and mostly the documentation about a container is very much lacking, and often limited to container 'gFrodod/gandalfsbrother' where there's no link to even say what gFrodod is. And is it better or worse than 'gFrodod/spacemarinereaper'?

 

[itsjasper]

Use watchtower, risk mitigated.

Using Watchtower To Keep Your Containers Up To Date – Linux Academy

Watchtower is an application that monitors your running containers for changes to the image. Here's how to keep containers up to date by using Watchtower.

linuxacademy.com

 

[Telos]

All things are vilne

Use watchtower, risk mitigated.

Disagree. Updated doesn't mean safe. Losing control of updating concerns me more.

 

[one-eyed-king]

Imho, vulnerabilities on the os level can be ignored as long as they are not dependencies for the core service inside the image.

On Docker Hub usualy official images are scannend for vulnerability and a report is available (see TAGS-tab in the repo). Go for images based on alpine if your want less vulnarabilites: usualy they include the bare minimum. Lesser packages mean lesser surface for vulnerabilites.

The realy thread are vulverabilities in the exposed application and the libraries it depends on.

Usualy a Dockerfile repo can be found for images on Github. You can always rebuild the image yourself.
Docker Hub has automated builds, which even allows to trigger a re-build when the upstream image was build - though, this only works, if the upstream image is not an official image (Imagine millions of custom images beeing re-build every time ubuntu, alpine or a debian base images are updated... this would put a lot of stress on Docker Hub)

 

[wwwampy]

I mostly use official images or from linuxserver.

But what to do with for example MariaDB (that has vulnerabilities according to that report) that I need for some other images, I don't know.

 

[wwwampy]

This one seems ok for monitoring Docker images: Docker Hub

But I don't like the option to update them automatically. I just want to monitor my image versions. There is an option for it, but not sure how to add it if I set up this container using Docker UI:

 

[itsjasper]

Disagree. Updated doesn't mean safe. Losing control of updating concerns me more.

That's what the --no-pull option is for, as wwwampy said.

 

[one-eyed-king]

This one seems ok for monitoring Docker images: Docker Hub

When opening the Github repo v2tec/watchtower a forward to containrrr/watchtower is done. I assume containrrr/watchtower is the successor of the unmaintained Dockerhub repo.

 

[one-eyed-king]

But what to do with for example MariaDB (that has vulnerabilities according to that report) that I need for some other images, I don't know.

That's fairly simple: separate each application stack (app+db+whatever) in it's own custom network. If an application in one of the stacks is hacked, worst case it can affect other containers in the same custom network. Each db should be used by a single stack. Unless the database is exposed to the internet directly (who would do that anyway?!), the remaining vector would be an exposed container beeing exploited and used for further attacks in the custom network. One should be more afraid of runing an internet exposed services with known vulnerabilities than of running a database with known vulnerabilities

 

[wwwampy]

When opening the Github repo v2tec/watchtower a forward to containrrr/watchtower is done. I assume containrrr/watchtower is the successor of the unmaintained Dockerhub repo.

Great!

Also in the documentation, I can see this:

So I can add via Docker UI the Environment Variable: WATCHTOWER_NO_PULL and for value I add false. I guess this will work.

One should be more afraid of runing an internet exposed services with known vulnerabilities than of running a database with known vulnerabilities

Agree. I hope my services are ok