为什么Docker Hub上有这么多易受攻击的Nginx镜像？

有技术上的论据来支持你的问题，但我相信最终的问题在于Devops模型，Docker的devise目的是为了帮助'Devs'而不是'Ops'，就是让代码走出门外，很快。 从2017年初起，docker仍然比许多传统的代码部署方法更难操作，我相信随着它的成熟将会发生变化，但是如果你的注意力始终在速度上，你总是会错过那些控制一个好的运营团队可以给你 – 这就是其中之一。

任何更新到所有安全补丁的最新版本的Linux发行版都将具有漏洞。 安全修补程序通常在发现漏洞后创build。 而且，从上游图书馆发布修补程序直至将其整合到发行版中，每个发行版都会有一定的滞后。 当您钻取许多列出的漏洞时，您经常会发现该分发版尚未提供可用的修补程序。

仅仅因为图像包含漏洞并不意味着它是可利用的。 这些漏洞常常与各种包含的库有关，当通过任何已发布的端口访问容器时甚至可能不会调用这些库。

例如，一些允许用户将权限从用户升级到root的列表漏洞，但是因为root用户已经添加了限制并且只能访问单个应用程序，所以许多容器已经以超级用户身份运行。 而其他漏洞利用可能需要一个库来parsing一个文件，如果你的networking服务器没有parsing来自未知来源的图片，那么可能无法对你的容器使用这个漏洞。

就我个人而言，我觉得Docker只是在一直存在但很容易被忽视的问题上发光。 如果没有这些报告，人们认为应用所有可用的安全补丁意味着他们已经修复了每个已知的漏洞。 没有Docker，他们正在这些系统上运行应用程序，而不会在各种应用程序之间进行任何隔离，使得一个应用程序中的漏洞利用易于扩展，并将其他应用程序和包含的数据公开在同一台机器上。

图像与最不安全的组件一样安全。 所有这些图像都是从添加了依赖关系的基础映像构build而来，然后运行应用程序。 如果其中一个依赖关系是脆弱的，那么整个栈就是这样。

通过查看“标签”页面，您可以确切地看到哪些组件易受攻击。 比如官方的nginx镜像 。