Multiple vulnerabilities detected with docker images

[aquddos123]

I've pulled latest docker image into IBM's container registry and it complained about 44 security vulnerabilities. I've tried a few latest versions 5.2.27, 5.2.28, 5.2.29. I guess most of them are due to older packages used in the distribution. Is it possible to upgrade the distribution when creating these images? Something like below in the Dockerfile?

RUN apt-get update && \
 apt-get upgrade -y

Some examples vulnerabilities are given below: https://lists.debian.org/debian-security-announce/2023/msg00010.html https://lists.debian.org/debian-security-announce/2023/msg00020.html https://lists.debian.org/debian-security-announce/2023/msg00032.html https://lists.debian.org/debian-security-announce/2023/msg00006.html

[fhoeben]

I guess the change is easy enough to make (you could even do it yourself by creating a Dockerfile based on the images I provide and only running this command).

I don't really want to do it in the build process I use for the images as it makes the builds non-reproducible (running the same build again at a later point in time gives a different image). I try quite hard to have the build process of all artifacts (jars and docker images alike) create the same binary content when re-run.

I don't really see the risk of the vulnerabilities. In my view the images are only used in containers run in the controlled environment of a CI server and they are not exposed in any way to the outside world. E.g. what risk is posed by sudo not handling something quite correct, how would an attacker get access to a prompt and what access could they get?

Address the issues it is not good enough to just add the line. We would also have to schedule the build process to run regularly (every day at least, maybe even multiple times a day) and publish a new image each time with some form of alias to indicate that it is the latest build based on a particular source version. It is doable, but I see it as extra work without much benefit.

Like I said I believe I do believe you can set this up on a local CI server very easily and then run your actual test jobs based on the images created by that job. This would address the issue completely in your environment if the vulnerabilities are important there. If you were to make a PR to address this in one of our CI pipelines (GitHub actions or GitLab pipeline, probably easiest in GitLab). In such a setup each run's image would get its own unique tag (i.e. older versions remain available, a run would produce 4.29.0-20230209102312) and one 'alias' (e.g. 4.29.0-latest) is updated on each run. I wouldn't mind merging that at all.

[aquddos123]

I agree these are not risky vulnerabilities, but modern cloud infrastructures are taking harder positions on the matter of cyber securities. Unfortunately, same is the case with us, even these containers and regression builds are meant to run internally, there is zero tolerance for risks and vulnerabilities.

As you mentioned, we are already creating an updated image out of your image as a workaround, but I strongly believe this has to be done before it got pushed to Docker Hub. Reason is that this container is meant to run selenium tests. and if the image is not updated and thoroughly "TESTED" on your end, it is very likely to fail for some end users like us depending upon their updates of that time.

At this time, I am not fully familiar with your build process. But I would love to take a look sometime soon and try to create a PR. Worst case scenario, I am thinking use this as dependency and create a fresh image from scratch instead of taking it from docker hub.

By the way, I see a "docker" folder in your https://github.com/fhoeben/hsac-fitnesse-fixtures repo and then there is separate repo https://github.com/fhoeben/hsac-fitnesse-docker. Which one you use to create images like hsac/fitnesse-fixtures-test-jre8-chrome. Please refer to the exact repo where I should be looking to incorporate this change. Thanks.

Lastly, I remember you mentioned in another thread that you are using selenium standalone image to build your images. If that is the case, then this might not be your side issue rather a selenium standalone image issue and must be raised with them. What do you think?

[fhoeben]

The images on docker hub for amd64 are from https://github.com/fhoeben/hsac-fitnesse-fixtures. They are published as part of the GitLab pipeline. The hsac-fitnesse-docker repository should generate exactly the same, but standalone from a published version of the library instead of using the output of a local build process (this one existed before). I don't often use it, but I have used it recently to build arm64 images for my local Mac.

I indeed base my images on Selenium provided base images and so you could raise a similar concern with them so their images would not have the issues either. But even when they would/have addressed it my docker images would still have to be regenerated to use their fully up to date image (but the content of the Dockerfile could remain as-is). Given that I regularly create new versions with the latest webdrivers I believe that would reduce the likelihood and number of vulnerabilities in my images.

Building your own image is not that complex, is it? I'm thinking of a Dockerfile along the lines of:

FROM hsac/fitnesse-fixtures-test-jre8-chrome:5.2.30
RUN apt-get update && apt-get upgrade -y

That should be sufficient to address your concern. You wouldn't have to build it each test run, I would think running it each morning at 1 am and then tagging it with the current date would make it quite easy for all test runs of that day to work based on that image which they could pull from either cache or your local docker registry.