问在图像扫描中有900多个漏洞是码头映像的典型吗？

EN

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

第一种情况是，特别是对于具有C扩展的语言解释器，有时预先打包的映像包含一个完整的C构建工具链。其中包括Linux内核头。因为您有Linux内核头，所以您会从安全扫描器发出响亮的警报，说您有一个过时的内核，即使Docker本身没有运行内核。

第二种更可怕。如果你看一下/ruby，你会发现现在有一个MRI2.5.5图像，而不是那里列出的2.5.1图像。一般的做法似乎是为每个小版本构建一个映像版本，但是一旦出现新的补丁版本，就停止发布旧版本的更新。也就是说，您的2.5.1映像可能确实存在一些安全问题，并且永远不会有一个更新的官方映像来修复它们。

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

准确的图像是来自码头枢纽的ruby:2.5.1

正如David提到的，当下一个补丁发布时，您将不再看到一个补丁的构建。在幕后，如果您配置了对接中心来为您进行构建，那么您将看到的是取决于github上的标记的对接器，并且当您标记代码时，构建将被触发。您可以更多地了解他们的这里的自动构建。因此，除非您重新创建一个旧标记，否则它不会自动更新。在这种情况下，2.5.1标记是6个月前最后一次推出的，已经有多个2.5.x版本取代了它。

您可以克隆红宝石回购并根据自己的计划执行自己的构建。通过拉新的基础图像，这将保持您的形象最新。

你也可以使用阿尔卑斯山的红宝石图像，这将有一个小得多的基础图像。缩小的大小意味着有更少的预先安装的应用程序，可能会有潜在的脆弱性。然而，这带来了一些可用性方面的挑战，比如musl而不是libc，另外一些预先安装的应用程序可能也很有用。

最简单的答案是，当您有基于语义的版本号时，不要使用特定的修补程序版本。因此，您可以不使用ruby:2.5.1，而是可以拉出ruby:2.5，当2.5.2发布时，它将更新2.5标记以供下次使用。甚至还有一个简单的ruby:2映像，可以自动将您更新到当前的2.6版本，而不会在任何时候推开3.x版本的更改。

最后，如果您喜欢基于Debian的安装在阿尔卑斯版本上，您仍然可以切换到一个最小化版本的Debian与苗条的图像。在这种情况下，会有一个更小的ruby:2.5-slim，同时还会使用最新的2.5版本进行更新。