在涉及诸如Docker等应用容器时，多数开发者可能会告诉你容器创新了开发人员完成工作的方式。这种自包容的便携应用功能包，以及与之有关的依赖关系，都有助于开发者和运营团队简化发布过程。
开发人员喜欢应用容器，这是因为他们可以花费更少的时间用于对生产平台进行镜像，从而确保其编写的软件可以如其发布时所期望的那样运行，也不必说在生产过程中真正调试配置问题所花费的更少时间，而容器的便携性意味着当代码在环境之间运动时，适当的配置可以与应用一起“旅行”。
从运营效率和开发速度与市场的角度来看，容器也具有创新性。虽然从安全的观点看，容器可能带来一些挑战。主要的挑战之一就是跟踪并减少漏洞可能极其复杂，尤其是当不同的容器可能使用的依赖软件属于不同版本时，问题尤其严重。
例如，不妨考虑一种运行着两种不同容器化应用的环境。两种容器都可以提供一种更广义应用的一部分的服务。即使这些容器可能由同样的语言编写，例如用Python。它们也有可能使用不同的运行时版本，例如，一个可能用的是Python 2.x版本，而另一个用的是Python 3.x。同样地，所用的支持库也有可能不同，甚至更为糟糕的是，使用同样库的不同版本。
还有可能存在不同的中间件，或者同样中间件的不同版本，或者应用程序运行所需要的不同配置。
这种情况虽然复杂，但在开始阶段是可管理的，直至随着时间的推移，影响到支持组件、库和中间件的漏洞开始出现。
为解决这些问题，开发者和安全团队需要明确地知道哪些应用安装在了什么地方，每个组件的什么版本运行在哪个容器上，以及其相互之间如何交互，还有容器如何用于解决问题等。
当然，这个例子仅仅涉及了两个容器，我们可以设想，一个拥有成千上万容器的公司将面临更为复杂的问题。
容器漏洞扫描
在很多情况下，安全团队可能会求助于传统的安全工具来解决这些问题。但是，使用传统的安全工具解决容器所带来的挑战也会带来新困难。当然，传统的漏洞扫描工具可以有助于标识一些漏洞但有一些问题需要注意。
首先，正如虚拟机一样，这些工具可能是临时性的或短暂运行的，这意味着除非需要，否则它们就可以保持非活动状态。
其次，依赖所扫描的配置，在无需容器的情况下也有不少工具可以发现所安装软件版本。例如，工具可能显示出Web服务器的版本需要更新，却不能指明给定的Python库需要更新。
为解决传统漏洞扫描工具的问题，新的安全工具已经出现。这些工具重视提供正在运行的容器的可见性，并且基于这种可见性，还可以交付运行在容器上可能包含漏洞的软件信息。其目标很简单：发现哪些应用运行在哪个特定容器上，并且标记出任何可能存在的问题。
许多商业工具都提供了这种功能，也有很多其他工具可以使用。Anchore Engine、CoreOS Clair项目和Dagda等开源工具可以确认有漏洞的或易受攻击的容器配置。其核心就是搜索容器中是否具有CVE清单中的项目。根据配置和具体的产品，这些开源工具还可以查找恶意软件、不安全的配置，以及其他的影响安全的问题。
容器可以使得在重新利用来自其它源的软件时容易一些，从而带来更好的效果。但这会导致支离破碎的动态变化的攻击面。而容器扫描工具可以自由获得，这有助于我们理解企业构建和使用的镜像中所包含的内容。
这种工具对于查找和洞察容器中的安全信息是至关重要的。基于所发现的信息，这些工具可以采取进一步的行动。例如，可以标记特定容器用于后续修复，增加对有漏洞的容器的监视直到有可用的修复，隔离一个容器，或者直接向开发者或管理者发出警告。这种工具可以由开发人员使用，或者可以自动集成到发布阶段。
开源容器漏洞扫描的益处
正如多数安全从业者所知道的那样，开源的安全工具可以带来很多好处，即使有时安全团队知道最终可能会过渡到商业工具中，他们也乐此不疲。
开源的首要好处是在预算的讨论阶段可以使团队构建安全武库，同时还可以展示通过开源工具的使用安全团队所获得的价值。在公司决定购买商业软件之前展示公司可以从工具中获得的价值，有助于简化与管理人员的交流过程，因为后者有可能担心这些工具的作用是否真实可靠。
其次，拥有强健的开源选择意味着安全团队不必在预算周期到来之前就可以部署安全工具。获得预算可能会花费很长时间，有时甚至长达一年甚至更长才能获得部署安全措施的资源。开源容器漏洞扫描工具意味着，如果公司拥有内部的技术专家可以支持其部署，安全团队就不必苦苦等待弥补安全差距或减轻风险。作为修复高风险漏洞的一项临时的应急措施，或者为了紧急部署短期安全控制，开源容器漏洞扫描对于快速修补在审核时所发现的漏洞都非常有益。
容器扫描非常有价值，而且我们可以有多种开源选项可以完成这种扫描，其实现成本也非常低。如此一来，安全团队何妨一试？
