VISA的另一位安全主管表示：“安全团队需要保护如此多的新环境，包括多云、无服务器和内部部署，这将极大地增加漏洞、补丁和更新量。有了这么多数据和噪音，很难像现在这样高效，所以你有同样的投资，但你没有那么有效。
就Kubernetes而言，团队必须从“偏离设计标准”的Kubernetes环境中从头开始学习安全性，并且他们还不能“预测攻击者可能的所有行为方式”。
噪音已成为整个云原生安全的普遍问题
作为一家风投支持的初创公司的CEO，我一直在密切关注人才和风投资金的去向。今年反复出现的一个主题是，在解决方案中投入早期种子资金，以减少云原生安全方面的噪音，提高安全团队的整体效率。
“向左转移安全”本应将部分负担从安全从业者转移到开发上，但这也降低了安全在不同环境中的可见性。
Kubernetes具有自我修复特性，可以在中断或用户定义的健康检查失败时自动启动或重新启动容器。但在Kubernetes的案例中，与安全相关的专业知识已经转移到了工程领域，创造了一个罕见的、既不可能找到也不可能聘用到的、对Kubernetes内外都很了解的安全人员。
攻击者现在使用的是与蓝队相同的快速移动、弹性强的基础设施工具，而机器人的速度正在超过自动防御。
‘热词炒作’已经成为一个团队必须应对的问题，导致安全团队浪费时间在不同的方向上奔波。
总之，云原生应用程序开发(使用容器、微服务、Kubernetes和迁移到云)给安全团队造成了名副其实的困境。
CNAPP示例
云本地应用保护平台(CNAPP)是当今云原生安全领域最时髦的术语。CNAPP的吸引力在于工具整合：使用一个平台来整合新应用程序开发生命周期中的图像扫描、CSPM、运行时和所有安全功能。大多数供应商都声称自己是CNAPP，Gartner已经发表了几篇论文，对这个主题提出了初步假设。
听起来很棒，对吧?是的，如果真的能节省一些时间和提高效率的话。最近的Scarleteel攻击表明，攻击者从Kubernetes中一个易受攻击的Web应用程序转移到云中Kubernetes托管的环境，再到云本身，最终试图窃取AWS密钥并危害云账户。
CNAPP用户将在单独的屏幕和区域中显示攻击步骤，不会将它们相互关联，也不会显示任何接近攻击者显示的跨多个环境的流动性。
这只是安全团队可能会说“我们的工具不会变化到外部环境中”的一个例子。
今天，云原生安全是对安全团队效率和生产力的削弱。但是，作为一项顶级的工程计划，向K8的迁移不会很快停止。那么，云原生安全如何才能不再成为将安全团队的工作效率推向错误方向的因素呢?
从业者为供应商提供了一些建议：
1.给我一个真实的信号，而不是噪音
我需要从变形到环境中的工具中获得有意义的见解——可以在一个屏幕上效仿上面的Scarleteel例子。
我的SIEM就像你在云方面的洞察力一样好。
2.和我一起设计你的产品：如果我觉得我的投入正在转化为价值，我会给你时间
你如何推销你的解决方案和你卖什么一样重要，停止推动你的议程，倾听并填补你解决方案中的空白。
3.请允许我把它关掉
“我最近买了一个运行时解决方案，他们一直在向我显示警报，但他们没有考虑到的是，我知道这些警报是什么，我对它们没有意见。我从事的是风险管理业务，而不是‘包治百病’。
4.帮助我在整个企业中创建影响力和伙伴关系的新模式
如果我的主要利益相关者是工程学，那么你的工具需要展示工程学关心的东西。
结论
尽管困难重重，但最具前瞻性的安全团队发现，保护新环境带来的挑战是一项令人兴奋和有益的努力。团队正在整个企业中创建新的影响力和合作模式来应对，但只有时间才能证明云原生安全是否会跟随他们的脚步，与这些安全团队建立真正的合作关系。
