容器可追溯到1979年的chroot命令，但Docker的出现让该技术的流行度和可用性有了指数级增长。任何技术一旦流传开来，必然也就成了攻击的目标。
容器旨在提供非完整虚拟机之外的隔离环境，但因为往往不像IT环境中其他资产一样受到监视，容器也就成为了攻击者眼中的肥肉。
公司企业有必要对容器进行漏洞评估，就像对环境中其他任何资产所做的那样。有那么几个漏洞扫描器可以扫描运行中的容器并报告漏洞，旦那只是整个评估的一部分。
容器并非全时段运行，只有完成特定任务时调用一下，然后就是暂停挂起或关机，直到下一次需要的时候再运行。如果扫描的时候容器没在运行，传统扫描器就可能会错过漏洞。
我们可以做个类比以更好地理解这种情况。大多数公司都用笔记本电脑，也会对笔记本电脑进行漏洞扫描。如果扫描的时候笔记本电脑正好接入网络，那么其中存在的漏洞就会被扫到并上报，但如果电脑正好关机或休眠了，漏洞扫描就无法评估这台电脑的情况(假设没有局域网唤醒功能)。
容器的情况与之类似：必须正在运行，才可以被漏洞管理产品评估。
不过，如今，情况改变了。
Tripwire漏洞与暴露研究团队(VERT)发布了ASPL-736，增加了非运行Docker容器扫描功能(暂停、停止、创建、退出等等状态均可)。该功能作为运行容器扫描的补充，对生产中的容器状态有了全面的视图。
有人可能会觉得，“好酷!不过，如果在进入生产前就全都扫描过了，为什么我还需要扫描非运行容器呢？”
可以再用笔记本电脑的类比来回答这个问题。公司或许会对所有笔记本电脑采用通用镜像，里面是已知完好的操作系统和经批准的App。在发给员工的时候，确实是在一个良好的状态。然后，员工可以通过安装软件，甚或暴露在恶意软件之下，让该电脑状态发生改变。因为在漏洞扫描的时候，该电脑未必接入网络，因而这些威胁很可能就被漏掉了。
不建议对生产容器进行修改/修复。相反，你应该修复父镜像，测试之，并用已更新的镜像替换掉生产容器。对笔记本电脑或许不会这么做，但我们仍可应用相同的类比，因为正如企业会有很多同样的笔记本电脑，拥有很多同样的容器或容器间共享的组件并不奇怪。
影响笔记本电脑的漏洞有补丁可用时，会执行漏洞扫描以确保所有系统都被更新。那么有大量容器需要打上OpenSSL补丁时呢？
基础镜像会被更新，更新过的容器再被重新部署进生产中。如果漏洞管理解决方案只能扫描运行中的容器，便无法确保所有容器都被更新。这就留下了盲点，容器可能在缺乏真实漏洞状态可见性的情况下被唤醒或启动。
非运行容器扫描功能，赋予了安全管理员超级X光透视能力，可以看清容器状态，清除这些盲点。
(责任编辑：安博涛)
