Docker映像在图像扫描中是否具有900多个漏洞是典型的现象？

Question

我通过gitlab容器扫描运行了ruby debian docker镜像，它返回了900多个CVE的列表，其中包含可追溯到2016年和2017年的大块代码。这是ruby docker官方镜像的最新版本。列出的所有CVE均来自debian 9映像。这是容器扫描的典型结果，对此我真的可以做些什么吗？我本以为debian映像将保持最新状态并得到保护。

确切的图像是从dockerhub提取的ruby:2.5.1

Answer 1

根据我的经验，这实际上是很典型的，而且我已经看到了发生这种情况的两个原因。

首先是，特别是对于可以具有C扩展名的语言解释器，有时，预包装的映像包含完整的C构建工具链。其中包括Linux内核标头。由于您具有Linux内核标头，因此即使Docker本身未运行内核，您也会从安全扫描器中发出响亮的警报，告知您内核已过期。

第二个有点吓人。如果您查看https://hub.docker.com/_/ruby，将会看到现在有一​​张MRI 2.5.5图像，而不是那里列出的2.5.1图像。通常的做法是为每个次要版本构建一个映像版本，但是一旦出现新的补丁程序版本，请停止发布较旧的补丁程序版本的更新。也就是说，您的2.5.1映像可能确实存在一些安全问题，并且永远不会有更新的官方映像来解决这些问题。

找到的最佳解决方案是从您选择的Linux发行版开始构建自己的语言解释器基础映像，并定期对其进行重建。然后它就在您的控制之下，发布时一定要确保有安全更新。

Answer 2

  

确切的图像是从dockerhub提取的ruby:2.5.1

正如David所提到的，当下一个补丁发布时，您将不再看到一个补丁的构建。在幕后，如果您配置docker hub来为您做构建，您将看到docker取决于github存储库上的标签，并且当您标记代码时，构建将由此触发。您可以阅读有关其automated builds here的更多信息。因此，除非您重新按下旧标签，否则它将不会自动更新。在这种情况下，2.5.1标签最后一次被推到了6个月前，并且已经有多个2.5.x版本取代了它。

您可以克隆ruby repo并根据自己的计划执行自己的构建。通过提取新的基础图像，可以使图像保持最新状态。

您还可以使用基于阿尔卑斯的红宝石图像，该图像的基础图像要小得多。减小的大小意味着可能容易受到攻击的预安装应用程序更少。但是，这带来了一些可用性挑战，例如用musl代替libc，并且某些其他预装的应用程序可能很有用。

最简单的答案是当您拥有基于semver的版本号时，不使用特定的补丁程序版本。因此，您可以拉ruby:2.5.1来代替ruby:2.5，而当2.5.2发布时，它会为下一次拉取更新2.5标记。甚至还有一个简单的ruby:2映像，它会自动将您更新到当前的2.6版本，而不会在任何情况下都将3.x版本中的重大更改推送给您。

最后，如果您喜欢在Alpine版本上进行基于Debian的安装，则仍可以使用苗条的映像切换到最小化的Debian版本。在这种情况下，ruby:2.5-slim会更小，同时仍保持最新2.5版的更新。