容器给将安全性融入发展和操作过程中提供了一个千载难逢的机会，让我们把握住这个机会。
当企业开发应用程序时，安全性仍被看做是一个事后考虑项，在应用发布之前才会涉及。软件容器的迅猛发展，为把安全性纳入上游开发过程（或在devops术语中称为“左移”）提供了一个难得的机会，并成为早期综合性和整个软件交付的管道。然而，大多数安全团队不知道容器为何物，更不必说了解它们独特的安全挑战是什么了。
软件容器可以被认为是系统需求更为精简的轻量级虚拟器。在运行时，容器共享主机的操作系统内核，大大减少了信息处理量（只有兆字节），加快了运行速度。容器启动一个虚拟器仅需几秒而不是几分钟。
容器自21世纪初期就出现了，并于2007年被构架到Linux中。因其占用空间小和便携性，与虚拟器相比同样的硬盘可以支持更多的容器，极大的减少了基础设施成本，加快了更多应用程序的运行速度。
然而，由于可用性问题，容器并未流行，直到Docker加入后改善了其可用性和对企业的适用性。如今容器——和Docker——变得炙手可热。今年早些时候，摩根大通和梅隆银行公开表示，他们正在寻求一种基于容器的发展战略，证明了容器对传统企业的发展有巨大的推动力，就像云之于谷歌、优步和Yelp。
就像容器的卓越性一样，它们也带来了独特的新风险。通常情况下，只有在新技术出现时才会发生此类事件，因此安全意识并未构建在容器内部。如果容器不在你的雷达上，那么现在是时候加速了，因为它们很有可能已经在你们公司内部的某个地方开始运行。我列出了在使用容器时会面临的5个独特的问题。
1.容器图像中的漏洞管理
图像是构建容器的基石。开发人员可以轻易地创建自己的图像，或者从Docker 枢纽和其他集中开源注册中心下载公共图像。使容器的使用达到高度自动化，过程灵活。
从安全性和管理方式的角度看，信任容器图像是贯穿整个软件开发生命周期的关键考量。确保图像的签署和来源于一个可信的注册处是保障安全的最佳做法。不过，坚持这些做法并不足以应对审批和验证代码的核心挑战。
在容器环境中，图像被不断地加入到企业的私人注册处和枢纽，容器负责图像的收入和输出。即使列出了图像的漏洞，基于对其公司安全事件和政策的考量，开发团队也很少能提出解决办法。例如，开发人员从一个注册处中选取了一个有1000处漏洞的图像。这个数字本身的上下波动并没有可操作性。有多少诸如此类的漏洞发生呢？为什么？
放大开放源图像的问题相对容易，特别是有多个图层的图像尤其容易。为加速资源配置在图像中创建越多的图层，软件组件就会面临越大的风险，包括开放源组件。风险会在不被扫描、验证或修补的情况下产生。
我们已将发现，由于企业没有一个系统的容器漏洞评估体系，导致容器化措施施行受阻甚至搁浅。因此，一个不断改进的漏洞评估和修复体系要作为完整的一部分被纳入企业的IT风险和治理计划中去。
2.减少容器的攻击面
减少攻击面是保障安全性的基本原则。防止代码漏洞进入环境是减少一个关键攻击面的完美示例，需要注意的是，容器化有特定结构和操作要素。主要是，除了要保障主机的安全性，更要保障容器中潜在的共享内核架构的安全性；这需要维护标准配置和容器配置文件。
不像在虚拟化环境中，虚拟机管理程序作为其控制点，任何用户或服务访问内核根账户能够查看和访问所有所有容器共享Linux内核。安全团队可以依靠验证的方法来强化内核和主机，但这离用成熟和可复验的方式来确保特定于容器环境中操作过程的安全还差得很远。
其中的很多过程是容器化中固有的。例如，容器本身依靠内核以及一系列服务利用Docker防护程序通过系统调用。而Docker在调用开箱seccomp（安全计算模式）配置文件的能力有了显著提高，这些文件只在默认情况下禁用52系统调用，出于X64计算机中的313可用性，仍留下了一些开放的260系统调用。
另一个例子是把Docker防护程序绑定到Unix Docker访问组或TCP端口从而允许容器互相交流，此外，也有提供给所用用户根权限的作用。根开放可以减少运营摩擦，但是可能会使安全部门对违反最小特权访问原则表示不满。