另外，向DevOps模式的转变，开发者开始为他们开发的应用的软件包负责，这意味着现在开发者开始负起了维护软件包的责任。除了操作系统的软件 包，开发者在容器中可以包含应用层面中的模块，如pip（Python）、npm（Node.JS）和maven（Java）等，而这些都在我们的研究之 外，然而它们也可能带来新的安全问题。因为开发者更加关注快速的开发出新的功，这让保持老的镜像更新变得更加困难，正如我们的研究呈现的一样（如官方的与 201年4月发布的CentOS 5.11镜像仍然包含Shellshock漏洞，该漏洞是八个月前，2014年9月被爆出的）。
一个很好的避免这些问题的方式是经常用最新的更新重新构建镜像。重新构建的过程必须使用发布商发布的最新的基础镜像，并且不能使用任何缓存的镜像层（如：使用在apt-get upgrade的时候加上-no-cahce）。 但是在一旦发现漏洞从头重新构建，并且重新部署所有的容器的开销太大，十分不切实际了—— 漏洞出的频率太高，每天都会爆出好几次，并且很难评估每一个安全漏洞的的影响范围。加之，更新容器的软件包很可能给容器中的应用带来负面影响和不稳定性， 而这即使用复杂的测试也未必能捕捉到，这让人更加不情愿经常更新。
结论我们的研究结果鼓励使用严格的运维管理流程，实时的分析镜像中的内容，清楚其中的内容和包含的漏洞。镜像应该经过安全漏洞 的扫描，并且根据漏洞的严重程度来标记是否需要更新。任何重大的漏洞都应该被及时的发现，并且应该可以触发对这些有隐患的镜像进行隔离机制。镜像不仅仅应 只从操作系统层面进行扫描，也应从应用的层面的安全漏洞进行扫描。这些流程应该被集成到持续构建的框架中，这样在享受容器带来的全面福利的同时，仍然保持 着好的安全实践。