很多资深的安全专业人士都知道，许多甚至是大多数正在运行的容器具有高危或严重漏洞。令人更为不解的是，这些漏洞很多都已经有了可用的补丁，因此可以(但尚未)修复。但云不应该是更安全吗?

坏习惯在云上延续

把本地的信息系统迁移到云端，并不可意味着原来的工作环境或流程瞬间就得变得高效易用，安全更是如此。事实上，安全往往是人们最不想解决的问题，因为它往往会拖慢或影响业务。

以多因素身份验证(MFA)为例。太多的人都知道，或者至少听说过，信息系统的安全访问应该实施MFA。安全公司Falcon的Sysdig数据显示，48%的机构没有对root权限的账户启用MFA。此外，27%的机构使用root帐户做管理任务，这明显违反了所有的安全基准的建议。

身份和访问管理(IAM)是最关键的云安全控制之一，我们应该围绕它开发新的、云原生的流程。云团队应该创建适用于特定任务的IAM角色，禁止额外的权限，以及对使用人进行角色培训。不管怎样，启用MFA吧!

不完整的安全左移

复杂的流程转换需要时间，而且通常要分阶段进行。数据显示，48%的镜像首次漏洞扫描是在CI/CD管道中或容器注册表中进行，也就是说，在部署运行之前。

这个数据意味着许多企业已经开始“安全左移”。但另一方面，意味着更多的企业(52%)是在镜像运行时才做第一次扫描，耽误了潜在关键漏洞的发现。

部分原因是我们仍然倾向于推迟安全评估以节省时间。另一种可能的解释是，工作负载的一个子集并未包括在“左移”任务中。具体来说，许多不包含组织创建的自定义代码的第三方应用程序，都属于这一类。例如，Kubernetes组件、Web服务器和负载均衡可能要在软件测试阶段完成后很久才能配置。

这两种情况，虽然 左移”都在发生，但并不完全。最先进的团队正在使用他们的CI/CD管道测试所有工作负载的安全性，包括基础设施组件，如主机、集群、容器等的部署清单。

风险也应该左移

当我们谈论对风险的接受时，通常会认为这是最后的手段。“在这一点上我无能为力，所以我将其记录下来，然后一切交给上帝。”

然而，越早发现风险来源，就越有能力为其制定有效的缓解措施。我们可能最终仍会运行有着关键高危漏洞的容器，但如果我们积极考虑与这些漏洞相关的风险，并实施控制措施来降低风险，安全态势可能就不会那么糟糕。

当大家越来越担心软件供应链的安全性时，有必要考虑一下，那些第三方组件中有多少运行时漏洞，即使这些三方组件我们的软件可能都没有使用。

在软件交付过程的早期，识别易受攻击的依赖关系可以节省大量时间，并极大的降低风险暴露。我们无法修复所有的漏洞，但许多漏洞可以通过额外的安全控制进行管理。至少，应该记录在案，以便于查看。

点评

如今，数以十亿计的容器在云中运行。未来这个数字只会增加，同理，攻击面和潜在风险也一样会增加。事实上，新的工具和新的环境既是创新的机会，也往往会成为“技术欠债”的开始。但既然，我们已经从过去的经验教训中认识到了这个问题，为什么我们不能在一开始就放慢速度，把安全做好，做早?这就是云原生安全的核心推动力。