Release 0.8.0 of cheatset, Docker edition

#docker #opensource #cheatset #release

I got a mail report from @snyk, the security scanner indicating a high number of vulnerabilities in my Docker based projects.

I decided to see if I could get the numbers to a more tolerable level. The issue as such it not that the vulnerabilities exist, most of them are not exploited yet, but I do not like the feeling of having too many lurking in the dark.

I started with looking at docker-cheatset, which is a Docker edition of the cheatset Ruby command for all of us, who do not maintain a Ruby tool chain, but still want to create cheat sheets etc. for Zeal or Dash.app.

I had an idea that the base image, a standard Ruby image, was falling behind and I was right. I was able to get the same version of Ruby, but based on a newer Debian version by going from: ruby:3.1.0-buster to ruby:3.1.0-bullseye.

I am not working with Debian on a daily basis so I always have to concentrate when trying to get an understanding of what releases are end of life and which is the newest.

Another thing I noticed is the many names under which these base images come. Since I find this space a bit hard to navigate in and I do not want to waste time, I came up with the following recommendation (for myself).

Use the long names, so you can deduct both operating system and programming language version.

I actually have the somewhat same recommendation for when writing documentation on command line utilities, use the long form, not the short form. The users will adopt the short form when then are ready and comfortable.

For this particular Docker image, this was not a problem, but some of my other Docker images it was since they use references, which require some deciphering. This is not getting you all the way if you want all details, but it is a good starting point, when your Dockerfile is your entry point to investigating issues etc.

Unfortunately the number did not improve:

Status for: ruby.3.1.0-buster

ruby.3.1.0-buster (388 vulnerabilities), by severity
- 6 critical
- 42 high
- 68 medium
- 272 low

Data from Snyk, based on report from Snyk, 29 days old at the time of writing.

ruby:3.1.0-bullseye (196), by severity
- 29 high
- 35 medium
- 132 low

After the update I did a manual scan:

ruby:3.1.0-bullseye (196), by severity
- 11 critical
- 18 high
- 35 medium
- 132 low

So the overall situation improved, but the number of critical issues increased.

Many of the critical issues are released to libexpat and I can see they have been fixed upstream, so fingers crossed they will be sent downstream shortly.

At the same time I am toying with the thought of basing my Docker image on a slim version with less vulnerabilities (less software pre-installed) and then I can add the components I need, it will require more work, but it will be a good learning experience and the artefact should be more secure and slimmer.

Finally as an experiment I have added a Gemspec to the project, it was not necessary since I only rely on the one Gem, cheatset, but this way I can do scans and get notifications from @snyk and @dependabot when dependencies change. I do this for rojopolis/spellcheck-github-action, which is a Python based distribution with a requirements.txt file. I hope this addition will provide me with more information, so I can take the proper actions.

The cheatset gem had actually been updated from 1.4.4. to 1.4.5, but I had not noticed. The repository on GitHub does not uses the releases feature, meaning you cannot subscribe to getting release notification, I hope my Gemfile configuration will let Dependabot inform me of updates in the future, since it is based on the Gem repository.