DEV Community

Jonas Brømsø
Jonas Brømsø

Posted on

Release 0.10.0 of cheatset, Docker edition

I received a PR from Dependabot, proposing an update of the Ruby base image.

When I announced release 0.8.0 I included a lot of information on the Snyk vulnerability scan of the Docker image. I skipped this for release 0.9.0 announcement, which I regret now.

So to recap, it looked as follows for 0.8.0, not the slim version, by severity:

  • 11 critical
  • 18 high
  • 35 medium
  • 132 low

For the slim version used for release 0.9.0, by severity (restored based on an email report from Snyk):

  • 2 critical
  • 2 high
  • 1 medium
  • 26 low

I hoped that the update of the new Ruby base image would improve the situation and it did, but I am not sure I completely understand what happened.

The report for base image score as follows, by severity:

  • 0 critical
  • 0 high
  • 0 medium
  • 44 low

The Ruby base image is primarily rooted in the Debian Bullseye slim base image, the report from Snyk is public available and demonstrates this, with the 44 vulnerabilities scored as low.

If you check one of the vulnerabilities in the Snyk report (you can click the vulnerabilities, you can get additional details, example: "Buffer Overflow" in glibc).

You can see that it was introduced: 14th. January 2022 (the day before my birthday actually) and it has the Common Vulnerabilities and Exposures (CVE) key: CVE-2022-23219. It also holds following note from Snyk:

Although NVD CVSS Score is: 9.8 (Critical), when available we recommend using the distro's own rating score.

Which indicate that the Debian maintainers have scored the vulnerability as low and Snyk echoes this.

If you check the CVE with Mitre and you can see that it has the score of 9.8 Critical, which also ties back to the information on the Snyk site, so Snyk is just relaying the information.

If we check the Debian release, we can see that it is marked as a minor issue.

We can see that Debian Bullseye (stable) uses the version: 2.31-13+deb11u2 of glibc. It is marked as fixed in Debian Bookworm and Debian Sid, which are upstream to the Debian stable distribution. But it is not fixed in glibc until version: 2.35.

Security reports are surely a rabbit hole and if somebody can enlighten me on how to navigate this and interpreting and understanding the differences in scores, it would be most welcome, for now I am just monitoring and learning and trying to get the most out of the tools available.

I will keep an eye on the development in these security issues, I am looking very much for to the next Debian point release for Bullseye, which should be out every second month and last release was in December, perhaps this addresses some of the known issues, but lets see.

If you run into any issues with the 0.10.0 release, please report this via GitHub.

Change log

This is the change log lifted from GitHub

0.10.0 2022-02-21 Maintenance release

  • Bumped from Ruby 3.1.0-slim-bullseye to 3.1.1-slim-bullseye, via PR #32 from @dependabot

Top comments (0)