我通过 gitlab 容器扫描运行了 ruby debian docker 镜像，它返回了一个包含 900 多个 CVE 的列表，其中大部分是 2016 年和 2017 年的。这是官方 ruby docker 镜像的新版本。所有 CVE 都被列为来自 debian 9 映像。这是容器扫描的典型结果吗，我实际上能做些什么吗？我原以为 debian 映像会保持最新并受到保护。
提取的确切图像是来自 dockerhub 的 ruby:2.5.1
【问题讨论】：
根据我的经验，这实际上是典型的，我看到它发生的两个原因。
首先是，特别是对于可以具有 C 扩展的语言解释器，有时，预打包的映像包含完整的 C 构建工具链。这包括 Linux 内核头文件。因为你有 Linux 内核头文件，所以即使 Docker 本身不运行内核，安全扫描器也会发出响亮的警报，表明你有一个过时的内核。
第二个有点可怕。如果您查看https://hub.docker.com/_/ruby，您会看到现在有 MRI 2.5.5 图像，而不是列出的 2.5.1 图像。一般的做法似乎是为每个次要版本构建一个映像版本，但是一旦新的补丁版本发布，就停止发布旧补丁版本的更新。也就是说，您的 2.5.1 镜像可能确实存在一些安全问题，并且永远不会有更新的官方镜像来解决这些问题。
我发现的最佳解决方案是构建我自己的语言解释器基础映像，从您选择的 Linux 发行版开始，并定期自行重建。然后它在您的控制之下，并且您一定会在发布时获得安全更新。
【讨论】：
提取的确切图像是来自 dockerhub 的
ruby:2.5.1
正如 David 所提到的，当下一个补丁发布时，您将不再看到一个补丁的构建。在幕后，如果您配置 docker hub 为您构建，您将看到 docker 取决于您的 github repo 上的标签，并且当您标记代码时，构建会由此触发。你可以阅读更多关于他们的automated builds here。因此，除非您重新推送旧标签，否则它不会自动更新。在这种情况下，2.5.1 标签最后一次推送是在 6 个月前，并且已经有多个 2.5.x 版本取代了它。
您可以克隆ruby repo 并根据您自己的时间表执行您自己的构建。通过提取新的基础映像，可以使您的映像保持最新。
您还可以使用基于 Alpine 的 ruby 映像，该映像的基础映像要小得多。减小的大小意味着可能存在漏洞的预安装应用程序更少。但是，这带来了一些可用性挑战，例如 musl 代替 libc，并且其中一些其他预安装的应用程序可能很有用。
当您拥有基于 semver 的版本号时，最简单的答案是不使用特定的补丁版本。因此，您可以拉取ruby:2.5，而不是ruby:2.5.1，当2.5.2 出来时，它会为您的下一次拉取更新2.5 标签。甚至还有一个简单的ruby:2 映像，它会自动将您更新到当前的 2.6 版本，而不会在发生这种情况时推送 3.x 版本的重大更改。
最后，如果您喜欢基于 Debian 的安装而不是 Alpine 版本，您仍然可以切换到带有 slim 映像的 Debian 最小化版本。在这种情况下，ruby:2.5-slim 会更小，同时仍保持最新 2.5 版本的更新。
【讨论】：