许多高级安全专业人士都知道，许多甚至大多数正在运行的容器都有高风险或严重的漏洞。更令人困惑的是，这些漏洞中的许多都有可用的补丁，所以它们可以（但尚未）修复。但云不应该更安全吗？
坏习惯在云上延续
将本地信息系统转移到云并不意味着原始的工作环境或过程必须立即变得高效和易于使用，更不用说安全了。事实上，安全往往是人们最不想解决的问题，因为它往往会减慢或影响业务。
多因素身份验证(MFA)例如太多人知道或至少听说过信息系统的安全访问应该实施MFA。安全公司Falcon的Sysdig数据显示，48%的机构不对root使用权限账户MFA。此外，27%的机构使用它root账户管理任务明显违反了所有安全基准的建议。
身份及访问管理(IAM)是最关键的云安全控制之一，我们应该围绕它开发新的、云原生的流程。云团队应该创建适用于特定任务的IAM角色，禁止额外的权限，并对用户进行角色训练。无论如何，启用MFA吧！
不完整的安全左移
复杂的过程转换需要时间，通常分阶段进行。数据显示，48%的镜像首次扫描漏洞CI/CD在管道或容器注册表中进行，即在部署运行前。
这些数据意味着许多企业已经开始安全左移。但另一方面，这意味着更多的企业(52%)在镜像运行时进行了第一次扫描，耽误了潜在关键漏洞的发现。
部分原因是我们仍然倾向于推迟安全评估以节省时间。另一种可能的解释是，工作负荷的子集不包括在左移动任务中。具体来说，许多不包括组织创建的自定义代码的第三方应用程序都属于这一类。Kubernetes组件、Web软件测试阶段完成后，可能需要很长时间才能配置服务器和负载平衡。
这两种情况，虽然 左移都在发生，但并不完全。最先进的团队正在使用它们CI/CD包括主机、集群、容器等基础设施包括主机、集群、容器等基础设施署清单。
风险也应左移
当我们谈论接受风险时，我们通常认为这是最后的手段。我在这一点上无能为力，所以我把它记录下来，然后把一切都交给上帝。
然而，越早发现风险来源，就越有能力为其制定有效的缓解措施。我们可能最终仍会运行有着关键高危漏洞的容器，但如果我们积极考虑与这些漏洞相关的风险，并实施控制措施来降低风险，安全态势可能就不会那么糟糕。
当人们越来越担心软件供应链的安全时，有必要考虑第三方组件中有多少漏洞，即使我们的软件可能不使用这些三方组件。
在软件交付过程的早期阶段，识别易受攻击的依赖可以节省大量的时间，大大降低风险暴露。我们无法修复所有的漏洞，但许多漏洞可以通过额外的安全控制来管理。至少，它应该记录在案例中，以便查看。
点评
如今，数十亿容器在云中运行。未来，这个数字只会增加，攻击和潜在风险也会增加。事实上，新工具和新环境不仅是创新的机会，也是技术债务的开始。但既然我们已经从过去的经验教训中意识到了这个问题，为什么我们不能在一开始就放慢速度，做好安全工作，做得早呢？这是云本地安全的核心驱动力。