随着容器采用的增加，安全自动化将成为每个组织工作流程的关键要素。

1． 数字不会说谎

从每年的的数据来看，报称使用容器和应用程序安全工具的受访者比例翻了一番。2017年，只有23％的公司配备了该工具，而2018年这一比例为56％。容器的安全性正迅速成为标准化和简化的成熟环节。鉴于Kubernetes最近的爆炸性增长和过去一年新的容器运行时的出现，其实这不应令人惊讶。

令人惊讶的是大多数组织机构使用的是一个以上的容器注册中心。大多数使用私有Docker注册中心，其次是AWS ECR和Sonatype Nexus。 RedHat OpenShift和JFrog ArtiFactory也有很好的代表。人们可以想象使用多种方式的容器注册。但有些注册与其他大有不同。使用实施多注册中心的安全工具必须经过深思熟虑，否则可能会变成一个曲折的管道。值得庆幸的是，大多数注册中心都实现了公共API。

2． 容器需要与虚拟机不同的安全性方法

当被问到“您是否利用安全产品来识别容器中的漏洞？”几乎一半的受访者的回答都是肯定的。对于自认为是“成熟DevOps流程”一部分的应答者中，2／3都在扫描容器中的漏洞。另外25％正在评估容器安全工具。然而，四分之一的受访者表示，他们没有办法识别容器的漏洞。鉴于最近的违规行为，这点着实有些可怕。

这里可能有两个阵营：第一个阵营是使用标记为“最新”的容器的团队。第二个阵营是没有办法识别容器的漏洞的组织。考虑到容器的采用，如果没有扫描漏洞将会在安全流程留下一个很大的隐患。

3． 容器安全化

关于容器安全有一些常见的误解，最常见的误解是容器更像虚拟机。然而容器不是虚拟机。使用虚拟机团队会担心hypervisor和运行在下面的操作系统。使用容器团队会关注内核、容器运行时以及每个容器中使用的每个软件包和框架（除了操作系统和hypervisor之外）。有了容器，开发变得更简单更一致。但是，需要解决的安全漏洞数量通常会增加。幸运的是，好的容器安全流程可以快速缓解漏洞。容器需要与虚拟机不同的安全性方法。

4． Processes： 更新image而不是patching

容器的寿命应该比传统的虚拟机短得多。容器应被视为不可改变的基础设施。这既是基础设施的改变，也是思想的转变。容器不应修补而是重建。更新容器image和重新部署所有受影响的容器是应用容器安全性的最佳方法。如果管道构建正确，这个过程可能就像更改配置文件中的标记一样简单。

扫描正在运行的容器中的漏洞至关重要。扫描容器注册表以查找易受攻击的image也是一项关键功能。还应该通过版本控制操作来扫描容器。容器应该足够轻以便在每个接触点进行扫描。如果您可以使用一个工具来检查在开发环境中运行的易受攻击的容器，请使用！早扫描，多扫描。

5． 容器安全和扫描的开源工具

容器安全工具生态系统持续增长。在构建容器安全工具集时记住目前没有一种正确的方法，开发管道须基于业务需求，并思考选择合适的容器安全工具。

有许多开源工具可用来帮助锁定容器，我们无法在此一一讨论的。鼓励大家使用像AppArmor和Seccomp这样的工具。这两个组件都是Linux内核的组件，并提供了正常的默认设置。AppArmor将强制访问控制应用于正在运行的程序（如Docker）。Seccomp限制容器中可用的操作（Syscalls）。当容器被破坏时，AppArmor和seccomp为系统和容器提供最低限度的可行保护。这两种都不会告诉你软件中存在漏洞。

有些容器注册中心提供扫描工具。CoreOS提供了一个名为Clair的工具，这是对漏洞进行静态分析的开源项目。SysdigFalco是一种用于检测应用程序异常的行为监控器。Dagda（合并SysdigdFalco）是一种执行以下操作的工具对Dockerimage／容器中已知的漏洞、特洛伊木马、病毒、恶意软件和其他恶意威胁的静态分析工具。此外，还为Docker和Kubernetes制定了CIS Benchmarks（除操作系统外）。这些只是少数的开源工具，其实有许多工具都可以帮助保护容器和容器环境。

结论

容器的采用将继续增长。随着更多容器进入生态系统，提高能见度的需求也将随之增加。像Kubernetes这样的容器编排工具被更多采用。随着更多的软件被分层到生态系统，更多的自动化将降低管理的难度。把安全工具自动化到基于容器的工作流将成为每个主要组织安全态势的关键部分。