Release 0.8.0 of cheatset, Docker edition
Tags: docker, opensource, cheatset, release
Published: 2022-01-26 21:35:28

---
title: Release 0.8.0 of cheatset, Docker edition
published: true
description: Learning by doing
tags: docker, opensource, cheatset, release
//cover_image: https://direct_url_to_image.jpg
---
I got a mail report from [@snyk](https://snyk.io/), 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**](https://github.com/jonasbn/docker-cheatset), which is a **Docker** edition of the [`cheatset`](https://github.com/Kapeli/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**](https://zealdocs.org/) or [**Dash.app**](https://kapeli.com/dash).

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](http://jonasbn.github.io/til/debian/translate_release_names.html) 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](http://jonasbn.github.io/til/dockerhub/use_long_names_for_your_base_images.html), 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](https://snyk.io/advisor/docker/ruby/3.1.0-bullseye), 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**](https://github.com/rojopolis/spellcheck-github-actions), 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](https://rubygems.org/gems/cheatset) had actually been updated from 1.4.4. to 1.4.5, but I had not noticed. The [repository on GitHub](https://github.com/Kapeli/cheatset) 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.