我通过gitlab容器扫描运行了红宝石debian docker图像，它已经回来了一个超过900个CVE的列表，其中包含一个可追溯到2016年和2017年的大块。这是官方红宝石码头图像的新版本。所有的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的红宝石图像，该图像的基本图像要小得多。缩小的尺寸意味着预先安装的应用程序可能更容易受到攻击。但是，这会带来一些可用性挑战，例如musl而不是libc，而其他一些预先安装的应用程序可能会有用。
最简单的答案是，如果您有基于semver的版本号，请不要使用特定的补丁版本。所以不是ruby:2.5.1，你可以拉ruby:2.5，当2.5.2出来时，它会为你的下一次拉动更新2.5标签。甚至还有一个简单的ruby:2映像可以自动更新到当前的2.6版本，而不会在发生这种情况时从3.x版本中推断出更改。
最后，如果您喜欢基于Debian的安装而不是Alpine版本，您仍然可以使用纤薄的图像切换到最小化的Debian版本。在这种情况下，有一个较小的ruby:2.5-slim，同时仍然保持最新2.5版本的更新。