如果我们只看今年创建的镜像，有高危漏洞的镜像的比例仍然超过1/3，但是含有高和中级危漏洞的镜像接近了75%。换句话说，今年创建的镜像，每四个中就有三个存在较容易被利用的漏洞，并且潜在影响非常大。
如果我们将范围缩小到哪些标注了lastest(最新)的镜像，这比例分别下降到了23%和47%，这比例显然还是很高。这更小的数据说明，Docker的用户和维护者们，倾向于将镜像保持到最新，但是老一些的镜像却被忽略；创建容器数量之大和速度之快，让老的镜像在更新的时候被忽略。
为了理解这些漏洞，特别是排名靠前的，我们做了一个详细的影响Docker Hub的镜像漏洞的分析：
[图二： Docker Hub官方镜像中有高危漏洞的镜像]
图二展示了该分析的主要结果，并且表一列举了跟这些软件包相关的主要的CVE。最近发布的存在于mercuarial的漏洞在很多镜像中都有（大 约20%）。著名的OpenSSL漏洞如Heartbleed和Poodle，在近10%的官方镜像中存在。一些镜像还包含bash的 ShellShock(如Centos5.11镜像中)漏洞，这个漏洞在7个月前就被发布了。即便一些机构不使用这些包，但是如果不手动将这些包从容器中 移除掉也会成为恶意攻击的羔羊。
除了一些官方的仓库，Docker Hub包含了一大部普通仓库（在写本文的时候大约有95000个），并且有数十万不一样的镜像。我们实验中随机选择了1700个镜像，然后对他们的内容的内容进行分析（误差约百分之三）。
[图三：有漏洞的普通镜像]
图三显示了在分析了普通镜像后得到的主要结果。大体上，漏洞的出现概率比官方镜像的相比大很多。这个结果合乎预期，因为目前尚没有措施可以在将镜像上传到Docker Hub前可以过滤并检查这些普通的镜像。
大约40%的普通镜像有高危的漏洞。即便我们只是看今年创建的镜像，并且只看那些有latest标 签的，包含漏洞威胁的镜像的比例仍然在30-40%之前徘徊。如果我们包含那些含有中危漏洞的镜像，比例会迅速升到70%以上，不管哪个时间段都是如此。 尽管你可能会说，这些镜像比起官方镜像下载次数太少了，但是考虑到它们庞大的数量（几十万的规模）可以预想它们跟官方镜像一样使用甚广。
我们又分析了影响普通镜像中的高危漏洞，图4展示了主要的结果：
[图四：普通镜像中含有高危漏洞的软件包]
有趣的是，不同于官方镜像中首要祸源在于mercurial，在这些普通的镜像中，openSSL、bash、和apt成了祸源的榜首。我们怀疑 官方的和普通这种数字上的差异来源于发行版的差异，他们占据了这些镜像的大部分。官方镜像通常基于Debian，并且其中一一大部分包含 mercurial包。而普通的镜像，却通常基于Ubuntu因而有bash、apt和/或openssl相关的漏洞。
延伸容器技术带来软件开发中的变革，它提供了一个十分高效的方法，可以将开发者开发的软件在数分钟或者几小时内搬上生产环境运 行，而传统的方式可能需要几天甚至数月。但是我们的数据显示这种优势有其弊端，没有谨慎的运维和安全管理的措施，我们冒着让我们的软件生态环境更容易被攻 击的危险。
容器为运行于不同容器之间的运行程序提供了一层安全隔离，因而提高了安全性。然而容器还是需要和其他的容器和系统进行通讯，因此，由于镜像中存在 的安全漏洞，它们还是很容易被远程攻击，包含那些我们没有分析到的漏洞。再者，在多种多样的环境中启动大量的容器的轻便与快捷，如在你的共有云上，私有云 上，笔记本上，都让追踪和防护有安全漏洞的容器变得更加困难。部署容器的高效性，大大的加速了部署软件的多样性，结果让环境中的新的漏洞越来越多。
使用容器的另外一个根本点在于，包管理已经被转移到了容器的内部，而传统的方式是仅仅是基于安装在虚拟或者实体机的操作系统层面上。这种改变主要 根源于虚拟机和容器提供的抽象处于不同的层面。虚拟机提供的是以主机为中心的抽象，其特点是长期不停机一直运行，包含的软件包供不同应用所需。与之相对 的，容器提供的是一个更加以进程为主的抽象，其特点是短暂性，可以到处运行，构建后不会改变，仅仅包含运行一个应用所必须的软件包。任何更新都需要重新构 建容器，从而保持容器的不可修改性，这让任何的漏洞同时被复制。