读者们，今天我非常激动地发布我在任何网络安全行业中所做的最大报告之一。该报告提供了云安全演变的整体视角，追踪其主要里程碑，详细分析了当前的关键厂商以及市场的变化。它提出了一个重新定义云原生应用保护平台（CNAPP）的新框架，解决其局限性和矛盾，同时提供了一条全面的路线图，以引导云安全的未来。

报告作者：

Francis是软件分析研究平台的创始人，该平台帮助安全领导者了解网络安全中出现的新主题和行业。

James是Latio Tech平台和新闻通讯的创始人，该平台帮助工程师寻找和理解安全工具。

关键摘要

如果你只有5分钟来阅读报告，以下是关键要点：

  1. 本报告探讨了过去14年云安全厂商的发展历程——带您了解我们如何走到这个关键时刻，并利用历史背景为未来构建愿景。

  2. 我们讨论了整合趋势，因为云安全厂商合并相邻解决方案，特别是在应用安全和安全运营中心（SOC）运营方面，并分析了为什么一些厂商表现优于其他厂商。

  3. 我们对 Wiz、CrowdStrike、SentinelOne、Orca、Upwind、Sweet Security、P对Palo Alto Prisma Cloud、Jit、Rad、Armo和Dazz等公司进行了深入分析，作为不断发展的CNAPP市场中的代表性参与者。

  4. 超越仅仅对厂商进行分类，我们讨论了当前将CNAPP视为一体化安全平台的概念的局限性。我们提出了一些新视角，以尝试解决市场上的以下矛盾：

    • 支出增加，满意度下降：尽管云安全预算上升，最终用户仍然感到不满意。

    • 功能过载：最成功的 CNAPP 平台提供的功能较少，尽管对功能的需求有所增长。

    • 无代理与代理：曾经倡导无代理解决方案的公司现在都在构建代理。

    • 开发者与安全分析师角色：尽管这两种角色的需求截然不同，CNAPP工具仍被开发者和分析师使用。

    • 老旧创新的新包装：代码扫描和运行时安全被誉为突破，但它们已经存在多年。市场曾经还没有准备好，现在准备好了吗？

  5. 云安全市场持续增长，成为传统厂商无法回避的现实——他们通过收购不断向市场推进。Wiz在两个季度内增加了1.5亿美元！CrowdStrike在过去两年中增长了一倍。其他大型企业继续收购云初创公司以增强他们的产品，例如SentinelOne和PingSafe，或Tenable和Ermetic。

  6. CNAPP功能集持续扩展，分析师们一方面对其复杂性感到遗憾，同时又推动该类别成为一体化解决方案。CNAPP也很难跨越态势和运行时，因为企业安全公司很难在单一平台上解决安全的所有方面问题。

  7. 仍然对云安全工具有需求，公司将这些解决方案视为其安全计划的基石和起点。然而，实践者和首席信息安全官（CISO）对他们拥有的工具感到沮丧。工具太多，结果太少。

  8. 从业者对缺乏上下文、警报疲劳以及小团队管理规模是其 100 倍的团队的安全测试和检测所带来的普遍痛苦感到沮丧。他们被期望理解无法计数的基础设施配置的细节。

  9. CISO们对浪费的时间和开发者的抱怨感到沮丧，然而几乎没有什么成果。他们的团队不得不花费数小时来排查警报，许多云漏洞完全未被他们的CNAPP检测到。

  10. 这是我们关于市场状况的第一份报告。在我们的下一份报告中，我们将探讨未来的趋势、主题以及我们对市场如何发展的预测。

我们的报告提供了对当前市场状况及其发展方向的诚实评估，帮助您在复杂且不断变化的云安全世界中导航。

云安全简史

云前安全的核心仅有两个解决方案：端点检测与响应（之前称为杀毒软件）和通过防火墙实现的网络安全。这些核心技术催生了最大的市场公司，其领导者为CrowdStrike和Palo Alto Networks。可以肯定的是，除了这些核心功能之外，还有许多其他厂商，从电子邮件安全到漏洞扫描，企业级的SIEM，但大众市场的核心在于EDR和防火墙，这些技术是任何规模的企业都可以合理投资的。即使是中小型企业也会在其服务器前配置防火墙，并运行EDR。

在云计算的早期，厂商们急于将他们现有的解决方案部署到这个新环境中。毕竟，Palo Alto防火墙可以作为虚拟设备部署，而服务器就是服务器——无论是在您的数据中心还是亚马逊云的。只有早期的远见者意识到，向云的过渡实际上打开了数据中心中以前不涉及的安全部分：资源本身的端到端配置。

随着安全团队的发展，问题不再是“我如何将现有工具在云中运行”，而是“我如何弄清楚那里到底发生了什么？”发现和上下文变得比移植那些从未完全正常工作的现有工具更为紧迫。基本的EDR功能和基本的网络保护现在也随GuardDuty、安全组以及AWS中的其他原生功能一起提供。

这次转型真正发生的事情是从传统架构转向容器。安全团队坦率地说，来得有些晚，直到后来才意识到云中的工作负载实际上是从服务器转向容器。现有的参与者在Windows保护方面进行了大量投资，而当时对Linux的支持非常有限，更不用说容器层了。除了需要Linux支持，团队还需要对容器有更深入的可见性。

云安全的演变

创新者在两个领域看到了机会：访问云API以获取可见性和对容器洞察的需求。在过去的10到14年中，云安全发生了巨大的变化，试图发展并最大化这两项看似简单的创新的力量。早期的厂商“CSPM”产品迅速商品化，因为对云API进行错误配置的审查成为了像Prowler或ScoutSuite这样的开源项目的常见内容。

即使在这些早期阶段，态势与运行时之间的分裂是显而易见的，但行业从未完全理解。Sysdig推出了与Falco一起的容器运行时保护，其基于态势的对立面是Aqua的kube-bench。像ScoutSuite这样的CSPM尝试者，专注于审计，拥有更复杂的以工作负载为中心的替代方案，如Cloudmapper。

与其假设这些早期公司的方法背后有某种隐藏的天才，不如说运气、灵活性和人脉的结合更有可能帮助巩固了早期关于云安全的讨论，使其转变为代理与无代理的对比，而不是态势与运行时的对比。当前沿开发者已经准备好容器运行时解决方案时，广泛的安全市场仍在探索一般可见性，并试图赶上他们的开发者同行。与早期不同的是，当人们在2024年听到“CSPM”时，他们假设这其中包含某种程度的工作负载可见性，这正是从第一代云安全到第二代云安全转变的核心，即假设工作负载是随之而来的。

云计算中的关键时刻

2010-2014 年（CSPM 与云转型）

  • Dome9成立于2010年，虽然他们并未直接被称为云安全厂商，但他们专注于云环境的合规检查和治理解决方案。2018年，他们最终被Check Point收购。

  • Evident.io成立于2013年，由Tim Prendergast和Justin Lundy创办。该公司专注于公共云基础设施的合规监控，并帮助组织检测错误配置。

  • RedLock由Varun Badhwar和Gaurav Kumar创立。他们最初专注于提供VPN流日志的可视化和网络可视化。然而，客户开始引入RedLock来帮助识别错误配置并管理云环境的合规性。2018 年，它被Palo Alto收购。

  • Qualys、Tenable和Rapid 7：必须要承认，这些漏洞管理提供商的存在是为了帮助公司发现主要在本地环境中的错误配置，然后再转向云。然而，Tenable在云环境中早期取得了成功，因为Nessus的基于网络扫描比代理部署更具可扩展性。这或许是后来的代理与无代理扫描之争的唯一暗示。

2015 - 2018（工作负载安全的创新）

  • Twistlock：由本·伯恩斯坦和迪玛·斯托佩尔于2015年创立。Twistlock是容器安全领域的早期参与者，专注于保护云原生应用、容器和微服务。它于2019年被Palo Alto收购，即使在功能更新较少的情况下，Prisma Cloud仍保持竞争力。

  • Sysdig安全：虽然Sysdig于2013年正式成立，但该公司在2015年因推出“首个也是唯一的容器原生”解决方案而崭露头角。Sysdig成立时专注于容器运行时安全，使用户能够通过代理监控和保护使用容器化应用的云原生环境。

  • Aqua Security：他们成立于2019年，旨在保护云原生应用，特别关注容器、无服务器计算和Kubernetes环境。Aqua的开源解决方案，尤其是他们的漏洞扫描器Trivy，受到客户和竞争对手的热爱（Trivy在许多漏洞扫描器中默默发挥着作用，尤其是在早期！）。

2018年后（围绕CNAPP的协同效应）

  • 首个云安全整合：Palo Alto对Twistlock和Redlock的收购是云安全领域的一个关键时刻。Palo Alto因其对CNAPP的愿景以及从一开始就大举进入这一领域而值得高度赞扬。通过在2018年收购RedLock和Evident.io，随后在2019年收购Twistlock，Palo Alto创造了第一个真正整合的云安全产品（即我们现在称之为CNAPP）。通过将RedLock和Twistlock结合在一起，Palo Alto提出了一个尚未得到验证的假设：客户希望有一个平台来处理运行时和态势。由于其规模，Palo Alto迅速定义了他们所做的市场，将讨论从CSPM与CWPP转向整合的CNAPP。他们还可以为其庞大的估值辩护，因为许多公司只想要可见性，但被说服在同一地方购买容器和云的可见性。另一个被忽视的早期销售环节是公司希望将云日志导入其SIEM的惊人高成本砍掉。

  • Orca：引入了无代理侧扫描的概念，使得能够深入了解云环境和工作负载，而无需在每个工作负载上安装代理。CSPM可以通过Orca前后进行定义：无需代理即可查看工作负载数据是一项真正的创新——利用了云API对厂商可访问的特性。

  • Wiz：Wiz将无代理扫描推向了新的极限，最重要的是通过向安全团队引入资产关系的直观图形化，并围绕这一能力构建了他们的整个用户体验。他们还展示了公开可访问的资源，并推动了在没有代理的情况下可能实现的可见性。他们在无代理方法的基础上不断发展，围绕图形构建并提供独特的低价值实现时间。在此期间，其他厂商对无代理扫描作为其能力的主要缺口反应缓慢，而现在几乎每个主要厂商都提供这一能力，且成熟度各不相同。

  • 关于老一代服务提供商如何难以接受无代理扫描成功的对话是值得进行的。他们对这一点持怀疑态度是完全正确的：从安全的角度来看，无代理扫描与他们能够检测和保护的攻击相比简直微不足道。然而，他们忽视了安全团队尚未深入了解这些架构，并不知道自己不知道什么。无代理扫描是安全旅程的第一步，这就是为什么每个人都需要它以保持竞争力。

  • Wiz的真正实力在于他们能够在恰当的时机进入市场，以满足客户的需求。他们并没有因无代理的成功而止步不前，而是在人们开始要求时推出了代理。他们在团队关注的情况下提升了DSPM能力。最近，他们在安全团队开始意识到 ASPM能力的强大时宣布了Wiz Code。Wiz对市场的威胁正是因为他们不仅仅是停留在自己发明的历史教训中，而是继续在恰当的时机推出恰当的功能，以迎合大多数市场的需求。

演变总结

创新阶段：云安全经历了三个明确的阶段：

  1. 云态势和错误配置的时代（2010-2015）。这是一个探索扫描云API以查找错误配置的时代。

  2. 运行时尝试的时代（远超其时代）随着容器和微服务的普及而增长（2013-2018）。

  3. 最终，无代理扫描和整合的时代（2019-2023）

2024年和未来会带来什么？团队对两个相互竞争的想法感到根本上的沮丧：

  1. 他们有太多工具

  2. 他们有糟糕的工具，制造噪音而不是解决他们的问题

云安全的下一个重大问题是询问团队更希望什么——进一步整合还是在更少的功能下获得更好的结果。

云安全的部署选项（有代理与无代理）

关于云安全演变的中心讨论点之一，是代理和无代理在历史上扮演的角色有多重要，以及这个问题在今天的相关性。毫无疑问，关键时刻是Orca和Wiz等公司引入了无代理扫描。无代理扫描是一个转折点——但任何告诉你他们当时就知道的人都是在撒谎。我们足够老，记得这些工具在寻找其信息传递立足点时——尝试从基于风险的优先级到合规扫描。这是一个微妙的行业举动，直到多年后才得到认可，这在很大程度上是因为Wiz利用它来定义CNAPP会话。

我们特别喜欢一位Wiz竞争对手的前营销专业人士的引用：“我们让Wiz定义了关于有代理和无代理扫描的对话，而我们从营销到销售所做的只是捍卫代理的好处。这种关注使我们无法专注于真正的信息和我们实际做得更好的事情：保护云端。”Wiz让每一次销售电话都围绕价值实现的时间和无代理的便利性，而不是试图触及容器化工作负载的复杂性——这是安全团队仍然抵制学习的内容。

让我们设定背景并了解一些基础知识。当组织迁移到云端时，他们面临的第一个问题是可见性——AWS仅向他们展示一堆EC2实例，甚至没有名称来识别它们的功能。他们有两种部署选项来扫描漏洞，并仅获得对这些工作负载的一般洞察：

  1. Agent代理

  2. Agentless无代理

下面的图表展示了在代理和无代理之间决策的复杂性，解决方案根据工作负载类型具有复杂的权衡。许多安全团队没有消化这种复杂性，而是做出了一个更简单的计算：我是否想打扰开发人员？再加上市场上关于“如何保护Kubernetes”的复杂信息，代理变成了“稍后再做的事情”，而不是“我现在需要的东西”。

Source:LatioTech Substack

评估2024年的基于代理的解决方案（代理的回归？）

代理获取客观数据非常具有挑战性。评估的第一步是部署一个Kubernetes集群，因此许多安全团队在PoC中已经无法获得有意义的结果。Latio提供了一个测试库，以帮助安全团队实现这一目标，但在这个不断发展的环境中测试比较代理几乎是闻所未闻的。

对于2024年考虑代理的专业人士来说，以下几点至关重要：性能有所提升，洞察力得到了改善，安装变得更加简单。在艰难的日子里，代理部署需要DevOps团队多次手动执行命令。现在，现代解决方案都采用了Helm图表，允许快速的一行安装或通过 ArgoCD进行部署。需要注意的是，eBPF是安全的但又是新的——它不会崩溃内核，但它是拓荒式的创新，这意味着在性能和可见性方面，没有两个代理是完全相同的。

优点

  • 代理可以实时检测和缓解威胁，使安全团队能够更快地响应事件。它们对于快速响应事件至关重要的行业特别有用，例如金融和医疗保健。如果一个组织在云和本地系统之间有工作负载，这一点也非常相关。

  • 细粒度数据。代理在可达性分析到寻找应用上下文中的非人类身份等方面都很有用。除了可达性数据，云中的事件响应还需要上下文数据才能有效——太多解决方案仍然没有为安全运营中心分析师提供他们需要的数据，以便对云威胁采取有效的响应措施。

  • 深度可见性和控制：基于代理的解决方案提供对底层工作负载、进程和系统文件行为的细粒度可见性。这使得对运行时环境、配置问题和主动威胁有更深入的洞察。

  • 容器时序。容器是云的基础设施，驱动着绝大多数云工作负载。无代理解决方案在展示内容上受到严重限制——它们通过漏洞数据来伪装，但诸如进程执行、文件访问和修复上下文等信息只能通过协调的代理获得。

  • 新兴应用层检测。最具创新性的基于代理的解决方案正在深入到运行在工作负载上的应用程序中，为安全团队提供前所未有的强大可见性。

风险

  • 部署：传统代理在复杂的部署和维护方面面临困难。无论代理部署多么出色，许多厂商现在都提供一行CLI命令来完成这项工作，而安全团队通常很少直接接触到这些命令。展示价值的第一步通常需要安全团队去打扰DevOps团队，而这正是他们已经不愿意做的事情。对于现代厂商来说，这比任何真正的技术问题都更令人担忧。雄心勃勃的安全团队还应该利用这个机会学习容器，而不是害怕学习。

  • 性能问题：容器监控解决方案依赖于对eBPF和其他遥测解决方案的新实践和实验。eBPF非常灵活，但没有保持性能在可接受水平的默认范式。虽然它不会导致系统崩溃，但这种灵活性导致不同厂商之间的性能影响差异巨大，难以评估。

  • 工作负载边缘案例：此时，大多数厂商支持Kubernetes和自托管容器部署解决方案。然而，仍然存在一些工作负载边缘案例，例如无服务器和PaaS，代理在这些情况下难以完成任务。尽管如此，这些案例仍有其应用场景，厂商正在尝试不同的方法来覆盖这些边缘案例。

  • 响应焦虑：许多公司在考虑允许自动响应操作时感到紧张，因为与其他厂商或解决方案（从WAF到EDR）有过不好的历史。没有人信任代理去破坏他们的生产网络应用程序。

无代理扫描的出现

正如之前讨论的，Orca推出了无代理侧扫描的第一个版本，这使得可以深入了解云工作负载，而无需安装代理。随后，Wiz能够通过图形使体验更加直观，并更全面地将这种方法推向市场。没有代理可以做很多事情，而大多数安全团队已经被这些工作压得喘不过气来，很难说他们还在寻找更多的工作。

优点

  • 快速部署和快速价值实现：无代理解决方案更易于部署，因为它们不需要在每个工作负载上安装软件。它们利用云API对底层实例硬盘进行快照，将其复制到安全厂商的账户中，在厂商一侧进行连接和扫描。这创造了一种优雅的“如同魔法”方法——您可以完全了解工作负载，而无需任何仪器。

  • 您可以在没有代理的情况下获得良好的上下文。除了快照扫描，非代理解决方案能够构建完整的云攻击图，查看带流量日志的网络流量，执行秘密扫描，并真正作为完整的资产管理系统运作。虽然没有代理时您获得的总上下文不如有代理时多，但说您什么都得不到是不诚实的。

  • 适用于多云和多操作系统：无代理解决方案特别适合在多个云平台（AWS、Azure、GCP等）上运营并处理多种工作负载类型（Windows和Linux）的组织。它们提供了统一的安全态势视图，而无需在各种平台上管理代理的复杂性。此外，针对所有工作负载类型的一个简单扫描器比针对不同类型工作负载的特定部署更易于管理。Windows是另一个亟待解决的问题，因为大多数 CNAPP厂商选择专注于容器和Linux。

不足

  • 无代理解决方案从根本上来说是工作生成器。无代理解决方案发现各种问题——其中一些是真实的，有些则不是。但最终，它们并不能独立解决任何一个问题。

  • 容器是瞬息的。无代理扫描不太适合容器化的世界，因为许多容器只运行几秒钟。无论无代理扫描多么“实时”，洞察力始终有限。需要明确的是，无代理厂商在伪装某些可见性方面已经做得很好，但他们永远无法详细了解容器的实时活动。

  • 有效性和高误报率：无代理解决方案依赖于从云API收集的数据，这些数据没有工作负载数据，有时完全缺少相关的安全数据。这可能导致不准确或不完整的结果。公司抱怨，虽然他们欣赏无代理解决方案的部署便利性，但在监控更深层次的威胁时，他们仍然经历了比基于代理的系统更高的误报率。

  • 隐藏的支持缺失。无代理扫描底层系统卷真是太棒了！仅当系统有底层卷时。不幸的是，深入挖掘的安全团队会发现相当数量的工作负载类型没有卷——无论是带有NVMe驱动的云工作负载还是RDS集群。

  • 隐藏成本。快照存储和网络传输（取决于配置）并不是免费的！AWS对额外费用毫不在意，安全厂商当然也不会主动告诉你，随着他们的无代理魔法，云成本会有小幅增加。

总体而言，CNAPP的故事是安全团队在寻找无代理可见性解决方案的过程中，逐渐成熟为基于代理的解决方案，因为他们了解到自己的云主要是容器。安全团队开始渴望可见性，并迅速意识到他们并没有想象中的那么多。这正是Wiz不仅“曾经引领”市场，而且仍然在引领市场的原因。他们选择投资于代理，使他们能够继续满足安全团队的需求——根据客户的需求提供适当的可见性。相反，运行时提供商决定构建无代理扫描并没有对他们产生太大影响，因为他们的买家在旅程中已经走得更远。

值得简要提及的是，目前大多数主要参与者都提供无代理扫描和基于代理的解决方案，我们真正讨论的是与这些功能交互的界面、它们能力的深度，以及这些功能如何转化为完整的用户体验。

理解今天云安全的框架

Gartner的CNAPP

我们对CNAPP的起源有一些分歧——Palo Alto假设人们希望将Twistlock和Redlock整合在一个地方，并强加他们的意愿于行业。一个不那么愤世嫉俗的看法是，大多数CISO希望保护他们的云。这种保护始于对云的可见性，以及对容器的可见性。这一基本逻辑是合理的；事实上，这也是促使James决定早期采用Prisma Cloud的原因（尽管他不愿承认）。安全团队需要一些工具来帮助他们应对云——无论是学习他们的容器化环境，还是寻找合规团队询问的未加密数据库。

最近，CNAPP几乎达到了可笑的膨胀程度——我们能想到会谈论“数据中心应用保护平台”吗？企业和分析公司继续推动CNAPP意味着一体化安全的理念。

一个奇妙的对立来自Forrester的文章，我们认为它们相互矛盾。第一篇文章认为CNAPP拥挤且臃肿（我们同意）。第二篇文章认为CDR并不作为一个类别存在，因为它是CNAPP的一部分。这正是第一篇文章所抱怨的创新受阻！如果CNAPP真的是Gartner所描述的，那就没有其他类别。如果我们想要真正的解决方案，我们需要超越CNAPP神秘的“没有更多问题”的承诺。让我们从拆解组成类别开始。

Source: Gartner

云安全态势管理 (CSPM)

Gartner解释说，CSPM作为工具旨在通过将云环境与预定义的最佳实践、政策和已知安全风险进行比较，识别云中的配置错误、安全政策执行的差距和合规风险。一个卖点仍然是为技术水平较低的GRC团队提供合规状态报告。

正如我们在文章的大部分内容中讨论的，CSPM实际上可以分为工作负载前和工作负载后的可见性能力。早期的CSPM仅关注错误配置，而新的CSPM还关注工作负载级别的错误配置。在这一点上，我们认为CSPM可以简化为资产管理和漏洞扫描，并在其上层叠加错误配置检测。尽管这个市场在很大程度上被认为被CNAPP取代，但在市场下游仍然有空间，因为CNAPP的定价已经飙升到不合理的水平，难以满足小型团队的需求。

云工作负载保护平台 (CWPP)

CWPP一直是一个奇怪的类别，因为它只是EDR，但它适用于容器。公平地说，它有一些额外的好处，比如漏洞扫描和网络层可见性的实践。这个类别之所以奇怪，是因为从来没有明确的能力集来定义什么算作CWPP。厂商经常自称为CWPP，但只提供漏洞扫描。其他厂商则自称为CWPP，仅提供运行时防御解决方案。什么算作“工作负载保护”一直不清楚。简单来说，CNAPP = Redlock (CSPM) + Twistlock (CWPP)。CSPM提供云可见性，CWPP提供容器可见性。由于缺乏清晰性，这个术语的使用变得不那么常见。我们更喜欢使用云检测响应(CDR)，意味着在云和工作负载层提供检测和响应。

CNAPP的局限性

James曾形容CNAPP说：“我就是CNAPP，初创公司的毁灭者。我们来做所有事情，但稍微差一点。” CNAPP此时已经膨胀到可笑的地步。我见过一些演示，厂商点击 6个屏幕来深度展示一个巨大的应用层漏洞表。最终，实践者们一直想要的，甚至更多无关紧要的漏洞。目前安全的关键问题是：

  1. Too much noise太多噪音

  2. Not enough value价值不够

James认为CNAPP们带来的问题多于解决的问题，原因如下：

开发人员和安全运营团队的需求并不相同

开发人员希望（或被迫）看到他们代码中的漏洞，以及这些漏洞在生产环境中是如何被发现的。开发人员并不关心运行时漏洞警报，他们太忙于讲故事的点和中午在午睡舱中休息放松，同时抱怨项目经理。开发人员接收工单，他们的绩效是基于工单进行评估的，他们在集成开发环境和拉取请求中工作。

相反，安全运营团队生活在SIEM中。他们查询日志以应对攻击并拼凑事件。他们对攻击者采取响应措施，并确定影响范围。这些是开发人员宁愿不参与的事情。

这些团队唯一的共同点是对上下文的需求；然而，其他一切——从用户界面到工作流程，再到他们关心的数据——都是截然不同的。

Source: Latiotech

定义安全工程师？

没有两个安全工程师是完全相同的。“应用安全”和“云安全”之间的界限正在慢慢消失，变成了“产品安全”，其主要功能是“漏洞管理”，这正逐渐成为一个独立的学科。产品安全开辟了道路，漏洞管理帮助修补，安全运营中心（SOC）响应威胁，治理、风险与合规（GRC）创建和审计政策。云原生应用保护平台（CNAPP）实际上只为云安全工程师提供了资产可见性，但对于那些在应用安全领域深入发展的更全面的从业者来说，将面临很大的挑战。

CNAPP的未来？

CNAPP创建了太多独立产品的糟糕版本，正处于严重的临界点。厂商被迫同时深入运行时保护和ASPM。他们面临被夹在中间而被两者淘汰的风险。

我们对CNAPP能够实现这一点持开放态度，但没有人能同时让SOC和开发人员真正满意的用户体验。Wiz由于其Wiz代码的图形灵活性以及收购Gem和他们的代理，处于良好的位置来做到这一点，但执行将至关重要。

另一个显而易见的问题：Amazon GuardDuty和Inspector不断改进，Inspector现在也支持无代理扫描。作为“AWS成本/力量倍增器”，可能会在漏洞管理方面有所作为。

根据它们的估值和采用情况，目前最成功的CNAPP也是功能最少的一个。围绕用例的执行比Gartner的功能检查更为重要。

我们应该如何看待CNAPP

这是我们对CNAPP心理模型的提议：一系列功能要么与漏洞检测对齐，要么与运行时漏洞利用对齐。CNAPP产品决策是一个复杂的权衡噩梦，这就是为什么许多企业最终会拥有多个产品。在最高层面上，只有两个基本能力——要么你在检测漏洞，要么你在响应威胁。安全团队可以选择尝试将所有这些功能集中在一个地方，但这样做会面临非常现实的可用性权衡。我们认为这两个领域是根本的：

  1. 态势和漏洞扫描：该领域主要集中在主动识别云环境中的错误配置和漏洞，以防止它们被利用。这确保了安全基线，并通过扫描云资源和应用程序的脆弱性来帮助满足合规要求。这些功能的ICP均与产品相关，涉及多个正在变化的职位，如开发人员、DevOps、DevSecOps、云安全或产品安全。

  2. 运行时检测与响应：这主要实时监控云工作负载和应用程序，检测正在发生的主动威胁和异常。这种反应式方法能够迅速采取行动以减轻攻击，但可能会引入复杂性和性能开销。这些功能的关键绩效指标均与安全运营团队相关，拥有像威胁猎人、检测工程师和安全研究员这样的酷炫黑客头衔。

这两种能力对于全面的云安全至关重要——一种侧重于预防，而另一种则应对实时威胁。我们将这些分为态势或运行时的子类别：

在这两个类别中，我们认为在云和应用程序中还有进一步的子市场类别，可以进一步分析这些领域。一般来说，这些平台在每项能力上都有次优版本，实践者在最重要的地方利用单点解决方案。我们在下面提供了这些市场的简要分析：

态势与漏洞扫描

云安全态势管理 (CSPM)

如本报告大部分内容所述，CSPM提供无代理的云工作负载配置和漏洞的可见性。它为您的资产提供广泛的覆盖和可见性。虽然可以提供运行时，但这并不是平台的核心。这将继续是该缩写的核心部分。

应用安全态势管理 (ASPM)

ASPM提供了所有必要的应用程序安全测试工具，以彻底测试和保护应用程序。由于有很多扫描器和语言，因此公司更有可能在这里拥有许多不同的解决方案，这导致厂商也纯粹专注于不同扫描工具的发现的编排和聚合。

统一修复

众所周知，使用这些工具越多，您为团队创造的工作就越多。这些平台提供指导、去重和数据富化，以便更轻松地修复和跟踪问题。

云身份：CIEM（云基础设施权限管理）和非人类身份（NHI）

CIEM已演变为NHI，但两者都专注于追踪不同的权限及其在云中的作用。现实是，CSPM工具对大多数团队来说总是做了足够的身份管理，因此NHI这个缩写使这些厂商能够更好地区分他们在API、SaaS和工作负载身份方面的关注，而CNAPP还未扩展到这些领域。

数据安全态势管理 (DSPM)

团队一直希望通过DSPM实现数据标记，但对这一工具组合的满意度却各不相同。DSPM的核心在于为您的数据平台提供洞察——从像S3这样的对象存储到像RDS这样的关系型存储。然而，这里存在与CIEM类似的问题，因为CSPM也可以做到其中的一些功能，因此问题在于这种差异对特定团队的重要性有多大。

运行时检测与响应

如前所述，运行时检测和响应专注于在云环境和工作负载运行时进行监控，以实时检测活动的威胁、异常或攻击。

每个运行时工具都声称支持容器，但它们的检测能力和为安全团队提供的上下文信息的实际情况差异很大。正如Latio所主张的，通过创建一个新类别CADR，这三种云类别之间的界限正在迅速消失。然而，这是我们对当前存在的不同类别的分析。

传统EDR

这些工具只是运行在云中的EDR。它们最好的定义是专注于静态服务器和基于文件的检测。这个类别与云检测响应之间一个容易识别的特征差距是是否可以制作Kubernetes可视化，而不仅仅是进程树。

云检测与响应 (CDR)

CDR是为云而构建的检测和响应。该市场的一小部分（Gem、Stream和Skyhawk）致力于无代理方法，仅将云视为云API和流日志。然而，由于云运行在Linux和容器上，我们认为CDR的核心包括其工作负载，使容器安全成为真正CDR的基石。为了清晰起见，无代理CDR参与者通常采取集成方法来获取对这些工作负载的可见性。

应用程序检测与响应 (ADR)

ADR是一个快速崛起的市场，充满了炒作。这些厂商正在超越容器，全面扩展到应用上下文。这个市场还很新，每个厂商的方法截然不同，但它们的共同点在于捍卫应用层，而无需任何代码更改。代码更改是RASP未能起飞的原因，端到端的应用检测在没有任何代码更改的情况下，明显将这个市场与EDR区分开来。

厂商格局与生态系统讨论

基于我们上面列出的CNAPP缩写，我们认为市场上有不同的厂商来代表不同的组件。我们在底部包含的厂商列表并不是所有厂商的详尽列表。

厂商纳入和标准的核心部分是基于市场的吸引力和增长。如果CNAPP意味着“云中的每一个安全功能”，我们就必须突出成千上万的厂商。为了选择我们要突出的厂商，我们主要关注覆盖最大的收入参与者，以及一些我们个人因不同原因而感到兴奋的小型厂商。如果您想要完整的列表，可以在Latio的网站上找到。

利用市场上所有可用的来源和收益评估，这些是市场主要参与者的收入指标。Prisma Cloud仍然是最大的厂商。然而，CrowdStrike紧随其后，Wiz也在其后（这将是云计算的下一场大战，目前有许多客户因其不同的历史重点而同时使用这两个平台）。

Source: Public filings, earnings and press releases.

CNAPP主要厂商

Wiz

Wiz于2020年作为最后一个主要进入CNAPP市场的公司推出，解决了最基本但至关重要的云安全需求——通过无代理漏洞扫描实现云可见性。这个简单的需求伴随着复杂的实施挑战，但Wiz在这方面表现出色，超越了当时的竞争对手。

Wiz清楚地理解云安全的核心问题，特别是对云可见性安全的迫切需求，检测和响应随后演变。它将可见性作为基础，优先构建一个专注于快速、清晰洞察云环境的用户体验。

尽管比许多成熟企业晚进入市场，Wiz迅速在寻求快速部署和最小维护的企业中获得了关注。此外，他们的图形数据库的灵活性使他们能够随着发展轻松添加新类型的资产和关系。公司快速增长，在成立四年内收入超过5亿美元。Wiz通过采用基于图形的方法来实现可见性、检测、高保真风险优先级告警以及以客户为中心的执着方式，区别于竞争对手。虽然批评者会将Wiz的快速增长归因于强大的营销和易于实施，但这忽视了使Wiz成为云安全“最低公分母”（即满足大多数市场需求的核心方面）的关键因素。无代理资产和漏洞管理正是早期市场真正想要的。

产品优势

图形用户体验

Wiz成功的核心因素是其基于图形的架构，从实际数据库到用户体验。云环境由许多相互连接的实体组成，如虚拟机、数据库和API。Wiz的图形模型使安全团队能够以高效的方式理解这些复杂关系，为相关团队查询相关信息。

该架构提供了深度可见性，使团队能够比竞争对手更有效地分析错误配置，更重要的是理解云环境。例如，安全团队可以轻松创建搜索，并将这些搜索转化为其他团队使用的保存仪表板，从而推动整个组织的产品采用。我们相信，对图形的基本理解是其产品成功的基础能力。

超越无代理扫描的演进

众所周知，Wiz推出了一种更有效的无代理扫描仪，帮助团队以惊人的快速实现价值和部署识别大型企业的漏洞。其基本前提在于Wiz利用图形构建了更先进的无代理可视化解决方案，使软件开发团队能够轻松地在其网络中可视化威胁（面向互联网的风险与非面向互联网的风险）。

Wiz真正成功的基础在于其在市场演变时恰好按时满足需求。早期，云可见性对安全团队来说并不是一个急迫的问题，因为他们试图将本地工具迁移到云端。这个问题在2020年至2021年间更加普遍，当时公司迅速向云迁移，但必须保护自己免受Log4J和CapitalOne泄露等攻击。这些事件对Wiz的成功至关重要，因为他们在正确的时间拥有了正确的产品。

Wiz提供了一种非侵入式的方法，通过无代理扫描获得相同的可见性，满足安全团队在初期所需的基本需求。现在，市场正在发展，意识到纯无代理方法的缺陷——缺乏代码上下文和缺乏运行时防御。Wiz并没有满足于现状，反而在近两年前创建了一个代理，进行了Github集成，并扩展了他们的DSPM。这些单独的组件虽然不如一些竞争对手先进；然而，他们仍然专注于用户体验而非功能，确保在客户需要时及时提供所需功能。

攻击路径分析

Wiz的基于图形的系统自然支持攻击路径分析。它可以通过评估漏洞的上下文来优先考虑风险，并快速追踪潜在的攻击路径。例如，它可以映射攻击者如何利用一个不太关键的漏洞在环境中横向移动，从而达到更有价值的资产。这种基于上下文的分析帮助安全团队专注于最重要的风险。可以肯定的是，这一功能迅速变得商品化，因为几乎每个CNAPP都可以绘制出他们云资产的漂亮图形；然而，Wiz因其早期实施以及图形搜索的定制化程度而继续获得回报。

有效的优先级引擎

特别是在CSPM方面，安全团队很快就被无意义的告警淹没，这些告警不能带来业务价值。Wiz的优先级引擎是早期解决此问题的尝试。虽然竞争对手通常孤立地扫描单个资产，但Wiz提供了这些资产如何互动以及这些互动带来的风险的完整上下文。通过使用数据聚类技术，并结合其研究团队的云攻击者研究，Wiz对漏洞进行排名，帮助企业优先处理最关键的问题。其低误报率确保团队不会被不必要的警报淹没，这在与CrowdStrike和Palo Alto等竞争对手相比时是一个显著的优势，即使其他厂商现在也有了自己的版本。

定制化与协作的便利性

客户（主要是开发人员和云团队，而非安全团队）经常强调Wiz的用户友好界面和自动化功能，这使得安全团队能够快速优先处理关键问题，并与工程团队创建共同的仪表板。其直观的扫描引擎开箱即用，能够检测漏洞，所需的定制化极少。Wiz的可扩展性是另一个优势，因为它能够轻松适应不断增加的工作负载和复杂的云原生用例。虽然某些定制是可能的，但该平台的设计旨在最小化自定义规则创建和手动干预的需求，能够原生处理常见配置。

品牌化

尽管批评者将Wiz定义为“营销浮夸”，但他们实际上在构建一个与Palo Alto和CrowdStrike相媲美的竞争品牌方面做了令人难以置信的工作，通过提供真实价值和定义对话。首先，从客户的角度来看，Wiz几乎没有仇恨者，这为他们赢得了良好的行业声誉。其次，Wiz的营销团队有效地提供了真实价值——从他们的云安全招聘网站到他们的云漏洞历史。再加上由备受信任的Scott Piper和Alon Schindel主导的真正有帮助的研究，Wiz进行了有意义的社区投资。第三，他们在营销浮夸方面也非常出色，无论是深思熟虑的礼物、定制鞋子还是本地活动，Wiz都在进行高度竞争的营销实战。这为任何与Wiz相关的CNAPP评估提供了框架。再加上一点流行的孩子戏剧（Wiz这周在买谁或被谁收购？），他们始终保持在谈论中。

Wiz围绕合作伙伴、CSP和解锁大型企业账户建立了强大的GTM组织。这与我们在终端安全领域看到的Crowdstrike与SentinelOne的情况类似。

一位前竞争性市场营销者的引用提供了深刻的见解，他们说：“我们让Wiz定义了代理与无代理扫描之间的对话，而我们所做的只是捍卫代理的好处。这种关注使我们无法专注于真正的信息：保护云端。”Wiz正在继续定义他们能力的对话。

关注领域

  1. 代理能力的深度：虽然Wiz在无代理扫描方面表现出色，但根据我们的客户讨论，它尚未完全匹配竞争对手提供的深度工作负载可见性和运行时保护。值得注意的是，Wiz已经有了代理解决方案很长时间。此外，ADR领域也在不断发展，这些竞争对手拥有自己独特的运行时产品。大多数企业云环境也是混合操作系统，而Wiz没有Windows产品，迫使他们与Crowdstrike进行补充。

  2. ASPM和代码扫描：其他厂商推出了自己的SCA和SAST扫描，但这似乎对市场的推动作用不大，因为与完整的应用安全产品相比，这些产品的功能非常有限。此外，许多团队正在转向外部修复平台，以提供代码到云的覆盖和去重。Wiz最近推出了Wiz Code，涵盖了ASPM中的大部分功能。这一开发的加速主要得益于他们在2023年底收购Rafft。Wiz Code利用安全图来扫描代码库、CI/CD管道和云环境。在接下来的几个月中，Wiz Code相对于竞争对手的采用情况将是一个关键关注点。

  3. 服务多个用户角色：大多数CNAPP平台是为云安全工程师构建的，他们通常具有系统工程或DevOps背景。这使得这些平台在扫描和上下文方面偏向较重。然而，随着检测和响应能力的普及，这些警报的用户角色将是安全运营团队，他们通常有非常不同的偏好和需求。目前没有厂商通过用户体验解决这一用户角色分裂的问题，能够同时满足这两种用户角色的需求。尽管Wiz收购了Gem，凭借其作为事前响应者（IR）在SecOps方面的深厚专业知识。

  4. 定价：尽管价格具有竞争力，Wiz不是最便宜的解决方案。早期用户享受了折扣，但新客户发现价格不够灵活。寻求基本云解决方案的中型市场团队将面临价格障碍。

未来趋势与方向

随着Wiz的持续增长，公司采取了多项战略举措以保持其竞争优势。公司通过开发代理、增强其DSPM能力、引入近实时扫描以及与GitHub和云事件规则的集成，扩展了其能力，超越了无代理扫描。这一从最初的“仅无代理”模型的转变，对于应对云安全的新需求至关重要，特别是在云检测和响应（CDR）兴起的背景下。

问题仍然是Wiz能否继续超越其无代理云安全态势管理（CSPM）的优势。随着竞争对手的发展和市场的日益拥挤，Wiz的长期成功将取决于其适应新安全挑战的能力，特别是在API安全、身份、运行时保护和DSPM等领域。虽然它可能不是最便宜的解决方案，但Wiz对自动化、可扩展性和易用性的关注使其成为寻求快速、可靠云安全的企业的一个有吸引力的选择。我们强烈建议访问Gartner的CNAPP指南以获取更多详细信息。

Crowdstrike

Crowdstrike于2020年10月推出了他们的云安全解决方案。在过去的四年中，他们成功地实现了超过5.15亿美元的年度经常性收入（ARR）。CrowdStrike最初作为一个EDR提供商，利用其Falcon传感器，他们进入云计算的方式只是将相同的传感器安装在云环境中。在这段时间里，他们的云/容器能力逐渐发展，但仍远远落后于专业容器公司。尽管如此，许多首席信息安全官（CISO）围绕CrowdStrike组建了安全运营中心（SOC），这使得他们的容器产品在实际能力不论如何的情况下，仍然具有巨大的优势。

产品优势

基于 Windows 的环境

像James这样的从业者亲身体验过“Crowdstrike是行业领导者，我们会选择他们”这句话，尽管有相反的证据——甚至根本没有测试！许多安全团队错误地认为代理就是代理，并且他们现有的CrowdStrike许可证可以轻松扩展到云中。虽然在某些情况下这是真的，特别是在Windows环境中，但我们认为并不总是如此。他们庞大的现有安装基础使用EDR代理与Windows工作负载（这些工作负载不会很快消失）继续是他们成功的核心。除了Sysdig等少数例外，许多CNAPP参与者从运行时的角度忽视了Windows。这使得CrowdStrike或SentinelOne的合同几乎成为大多数企业的默认需求。以这种方式打开市场大门可以轻松扩展到云工作负载。此外，CrowdStrike合同将被许多围绕它构建整个技能集的团队视为不可谈判的。

利用其作为EDR和威胁情报提供商的优势，Crowdstrike能够检测和响应发现的高级攻击行为。因此，一些客户强调了CrowdStrike威胁检测的准确性（基于AI的算法和行为分析），指出其高真实告警率使安全团队更容易优先处理真实威胁。CrowdStrike对全球威胁情报数据库的访问使其在识别新兴威胁，特别是零日漏洞和新兴恶意软件方面具有显著优势。

虽然CrowdStrike在其Falcon CSPM产品中开发了一些API和无代理功能，但CrowdStrike收购了bionic.ai，以构建他们自己版本的ASPM。然而，我们认为它缺乏一些定义该类别的核心能力。明确来说，Bionic给了他们一个很棒的技术——它通过引爆二进制文件来映射应用程序的工作方式；然而，将这种能力称为运行时或ASPM实际上是对这两种能力的误解。Bionic创建了应用程序二进制文件在运行时应该执行的操作的地图——使其成为运行时状态的理论地图。然后，它将漏洞导入该应用程序地图。这个功能集使他们能够声称在ASPM中是有竞争力的产品，但既没有提供真正的应用程序安全测试，也没有提供真正的ADR能力。

折扣

CrowdStrike因提供灵活的许可选项而受到关注，这使得组织能够根据变化的需求进行扩展或缩减。与其他需要大量前期投资的厂商不同，CrowdStrike提供更具动态性的许可，这对安全需求波动的组织具有吸引力。CrowdStrike的按需付费模式使公司能够调整其安全覆盖，而无需进行大规模的前期投资。总体而言，我们注意到，尽管他们为客户提供了许多优惠，但其定价被视为一个劣势，平台的费用比Wiz和Orca等竞争对手更高，尤其是对于寻求更具预算友好选项的组织。

关注领域

不符合云工程师目标

CrowdStrike的整个用户体验是围绕一个非常特定的用户构建的：通过进程树、隔离和类似的启发式方法响应运行时威胁的运营团队。他们的用户界面在提供资产上下文方面不如CSPM，在提供开发者洞察方面不如ASPM，也不如Kubernetes提供商在展示完整Kubernetes上下文方面。真正扩展到这些领域，超越收购行为，将是一项巨大的工作。

代理附带的开销

尽管CrowdStrike有其优势，但其对基于代理的安全解决方案的依赖可能会增加操作复杂性、开销和成本，特别是对于需要管理每个云订阅或工作负载的手动配置的DevOps团队。

有限的云覆盖

CrowdStrik的CSPM也存在云覆盖范围有限的问题，仅支持AWS和Azure。这使得它对需要与Google Cloud或VMware等平台集成的多云环境的组织吸引力降低。

初装流程

CrowdStrike的初装流程被认为复杂且耗时，需进行大量手动配置，这可能会在动态云环境中减缓部署速度。James希望大家知道他对此可以亲自作证。

Palo Alto的Prisma Cloud

Palo Alto首次提出了CNAPP的愿景。他们花费1.73亿美元收购了RedLock，这是一家专注于识别云实例中错误配置的首批云安全厂商之一，并将其与Twistlock这一先进的容器安全解决方案结合，创建了云安全的初步端到端愿景。随后，他们收购了Bridgecrew用于基础设施即代码（IaC）扫描，收购了Dig Security用于数据安全态势管理（DSPM），并收购了Cider以更广泛地扩展到应用扫描。他们采用了以收购驱动的扩展策略来构建一个强大的解决方案。值得一提的是，Palo Alto在选择这些厂商时的每一项收购都是绝对出色的——每个厂商都远远领先于他们的时代。

Source: Felicis

综合解决方案集

Prisma Cloud作为最强大的平台之一（目前在云和应用安全方面有超过13个模块），在多云环境、容器、工作负载和代码安全方面提供安全覆盖，支持代理和无代理解决方案。它的知名品牌和悠久历史使其在对话中容易被提及。它们最适合位于Palo Alto生态系统中的企业。Prisma Cloud非常适合已经利用Palo Alto的防火墙或网络安全产品以及其SOC解决方案的组织，将其整合为统一的安全平台。

基于代理的扫描围绕其终端解决方案在已经安装的组织中取得了成功。与无代理模型相比，他们的代理架构提供了对运行工作负载更深入的安全洞察，尽管Twistlock在更新方面滞后，但仍然能够保持竞争力。Palo Alto利用RedLock查询语言（RQL），使用户能够创建自定义查询和合规性及漏洞检测规则。这使用户能够根据特定需求量身定制安全监控。通过定义独特的政策并调整安全检查以适应公司的云基础设施，企业可以确保遵守内部和外部法规。

这使得安全团队能够根据特定的合规和操作需求定制Prisma Cloud的监控和报告RQL对于具有高度特定安全和治理要求的组织特别有用，例如那些在受监管行业中的组织。这种定制使Prisma Cloud与竞争对手如Wiz区分开来，后者提供更多的自动化但缺乏更细致的威胁狩猎能力。RQL提供了安全意识强的组织通常所需的深度灵活性和可扩展性。

总体而言，Prisma Cloud的表现相当不错，因为它在任何方面都不是特别糟糕，但也没有特别出色。从功能的角度来看，很难对该平台提出反对意见，因为从功能清单来看，它们的功能超过了大多数竞争对手；然而，安全团队常常会告诉你：“我真讨厌 Prisma”，因为其用户界面和功能臃肿。

关注领域

缺乏综合性和以结果为导向的愿景

根据我们从从业者那里听到的反馈，Palo Alto仍然缺乏一个全面集成的风险视图，并且他们的误报率高于Wiz和Orca等竞争对手。一些客户对Prisma复杂的用户界面表示沮丧，并且需要大量定制才能实现预期结果，尤其是在早期版本中。总体而言，平台仍然感觉支离破碎，缺乏实时的综合风险报告。Palo Alto似乎有一个基于追逐Gartner缩写的云安全战略，以获取企业功能。他们倾向于观察市场，并试图通过收购来实现成功。这导致了一个由功能驱动而非用户体验驱动的脱节平台。

定制化的代价

虽然通过RQL（RedLock查询语言）提供的灵活性允许自定义安全策略，但Prisma Cloud对手动规则配置的高度依赖使其资源消耗更大。我们听说，寻求即开即用自动化解决方案的企业可能会发现一些无代理解决方案，如Wiz，更加简化，因其减少了对手动管理的需求。RQL的直观性也远不如图形搜索或简单资产过滤器。

更高的误报率

我们多次听说，Palo Alto的误报率比Wiz或Orca等解决方案更高。Palo Alto没有与新兴厂商相同的代理，因此在Prisma Cloud中部署代理可能会增加资源消耗，无论是在云成本还是运营维护方面，在某些情况下使其成本效益降低。他们的CSPM引擎还覆盖了许多资产类型，当“错误配置”存在争议时，很难将某个发现称为真正的正面发现。

Orca

Orca Security在2019年通过引入其专利的无代理SideScanning技术，在云安全领域取得了重大突破。这一创新在无需安全团队在终端上安装代理或在工作负载上安装软件进行评估的情况下，实现了工作负载的可见性。

它们通过在运行时存储级别访问云工作负载以外的带宽进行操作，通过云提供商的API收集关键数据，同时扫描磁盘快照。它们的技术评估块存储字节并重建文件系统，以只读模式扫描操作系统和应用程序，确保虚拟资产不受影响。这种独特的方法使公司能够在整个云环境中部署Orca，而无需担心性能影响或操作中断。对于安全团队来说，这意味着可以在不打扰工作负载的情况下获得可见性。

Orca的侧扫技术在漏洞评估和扫描方面已被证明非常有效，尤其是针对非容器资产，具有快速统一的攻击路径数据库。虽然Orca在无代理方面的优势仍然是其关键强项，但随着云安全团队开始寻求更多的运行时数据和对其工作负载的可见性，它也显示出一些局限性。关键是，无代理扫描在应用于短暂工作负载时一直存在困难，因为磁盘上的内容每分钟都在变化。

在功能集和用户体验方面，与Wiz的比较是不可避免的。Orca在无代理功能集上继续与Wiz正面竞争。Orca确实有一些优势：他们的数据架构更具可扩展性，他们持续推动无代理能力，并提供非常有竞争力的风险图。然而，与Wiz正面竞争正是我们所谈论的大多数厂商拼命想要避免的地方。

Orca面临的最大挑战有两个方面：品牌和销售相关。在销售方面，Wiz的图形搜索以及将这些搜索保存到每个团队仪表板的能力，提供了一种非常自然的体验，使得在销售交流中很难克服。一旦你深入调查一个警报，Orca和Wiz提供的大部分功能是相同的，但Wiz的图形用户体验使得对首次购买者的亮点非常清晰，尤其是对于来自臃肿平台的用户。在品牌方面，Orca不幸地处于一个直接与无可争议的市场巨头Wiz进行比较的位置。由于他们被迫正面竞争，他们也不得不承受这种持续比较带来的压力。

最近，Orca通过集成对GitHub和GitLab等平台的源代码扫描，扩展了其能力，帮助公司识别风险热点，包括代码错误配置。随着对云检测和响应能力以及容器化工作负载的关注持续增加，我们认为Orca面临的最紧迫挑战是缺乏内部代理。

SentinelOne

通过收购PingSafe，SentinelOne正在大举进入CNAPP。SentinelOne和CrowdStrike在云计算中拥有相同的潜在增长机会，但也面临相同的困难。两者都有强大的EDR平台，安装基础庞大。两者都扩展到了容器安全领域，结果各异，然后又扩展到了更广泛的云环境中。CrowdStrike将其大部分CNAPP产品构建在现有数据结构上，而SentinelOne则采取了大胆的方法，将更多上下文数据纳入其数据湖中。

SentinelOne在CNAPP的未来将完全取决于他们执行数据能力的能力。PingSafe作为一个CNAPP是无害的，具有一些使其与众不同的功能。他们拥有我们所期望的一切 - 漏洞扫描、基础设施即代码（IaC）、态势等。他们与SentinelOne的区别在于能够实际从外部测试漏洞，通过验证资源的可利用性来去除CNAPP的噪音。作为一个CNAPP，它是现有客户可以考虑的竞争性产品，但我不认为在面对面比较中，很多人会选择它而不是Wiz。并不是说它的产品质量差得多，只是它没有达到在这个领域脱颖而出的10倍标准。

为了SentinelOne的长期目标，PingSafe的云和代码资产图形数据库可以用于警报上下文化。SentinelOne在其整体云和资产架构上进行了大量数据投资。如果PingSafe的数据能够完全整合，SentinelOne有潜力实现一个真正创新的端到端数据驱动解决方案。虽然目前CNAPP并不突出，但一旦统一，它将具有很大的潜力。

Sysdig

Sysdig一直是DevOps工程师和爱好者的首选工具。许多CNAPP领域的厂商在扩展其原始用例方面面临困难，但Sysdig仍然保持竞争力。Sysdig的运行时重点无疑部分源于他们的技术联合创始人Loris Degioanni，他共同创建了Wireshark和Falco。如果您熟悉Wireshark并欣赏其实用性，您可能也会欣赏Sysdig对云安全的处理方式。

Falco，开源容器安全运行时代理，超前于时代。尽管如此，它仍然是容器工作负载中 eBPF安全实现的默认选项，这一地位正在迅速获得认可。Sysdig面临着首先开发一个强大的代理的挑战，随后在最初低估市场快速演变后添加无代理的CSPM功能。实践者并未完全理解Sysdig的代理与市场上其他选项相比的价值。不幸的是，许多安全团队首先购买了CSPM解决方案，后来才意识到像Sysdig这样的具有容器洞察的工具才是他们真正想要的。

Sysdig的真正优势在于其实时上下文监控。虽然传统安全解决方案提供静态快照，但 Sysdig使用Falco持续监控关键漏洞和威胁。例如，其检测引擎实时流式传输洞察，允许团队在实践中检测云原生威胁，如风险身份行为或配置漂移。Sysdig在Kubernetes、容器和混合云安全方面的专业知识使其在传统安全提供商中具有显著优势。

随着市场将焦点从无休止的扫描转向主动阻止攻击，Sysdig正处于一个关键的转折点。一方面，eBPF及类似技术的创新迅速发展，使得Falco面临被视为过时的风险。另一方面，Sysdig仍然是最成熟的以运行时为重点的解决方案，使其在不断变化的环境中处于有利位置。

Upwind

Upwind成立于2022年，是最新的云安全厂商之一。尽管之前有许多解决方案，Upwind的价值主张集中在提供实时云安全，利用运行时数据进行威胁检测和响应。他们的产品围绕一个基于eBPF的代理（扩展伯克利包过滤器）构建，允许进行深层内核级监控和洞察，而不会带来传统代理通常相关的性能开销。

Upwind对市场的看法是，CNAPP需要一个面向运行时的改进。随着CNAPP功能的膨胀，Upwind认为以结果为导向的安全本质是面向运行时防御的。对Upwind而言，这意味着利用eBPF技术在内核中监控和过滤系统活动、网络流量和文件访问，而不会对性能产生重大影响或引发内核崩溃。我们应该注意到，Upwind在运行容器和Kubernetes的环境中表现出色，既能可视化这些关系，又能进行威胁检测。它专注于通过建立网络流量、文件操作和进程执行的基线行为，实时检测异常。例如，它可以发现不寻常的活动，如错误加载的库，这可能是系统被攻破的迹象。

与其他CDR厂商不同，Upwind最近宣布了他们的无代理云扫描器。这对于初步接触或获取客户非常有用，特别是对于那些犹豫不决是否部署代理的公司。这对于使用无服务器容器、函数和虚拟机（VM）的客户来说将至关重要。此外，与其他CNAPP不同，他们在API安全方面进行了重大投资，利用他们的网络数据——成为独立运行时API安全的真正竞争者。

现在，Upwind提供无代理和基于代理的解决方案，能够满足多样化的客户需求。他们还通过利用构建时数据在CI/CD流水线中整合安全性，以增强整体云安全性。他们可以自动发现并关联CI/CD事件与运行时数据，提供对漏洞、风险和问题根本原因的端到端视图。

他们的主要关注点是以结果为导向，为中型市场公司提供真正的安全性，这些公司代表了他们的核心客户群。这些客户通常寻求工具整合和成本节约，使得Upwind的综合平台特别具有吸引力。中型市场是Upwind看到最多吸引力和增长的地方，定位为提供整合解决方案的公司，而不是碎片化的工具基础方法。Upwind还在寻找尖端运行时安全的企业买家中找到了吸引力，这些买家通常将Upwind视为更大工具套件的一部分。

总体而言，我们喜欢Upwind在CNAPP领域提供完整解决方案库的方法。下一个关键问题将是他们在中型市场的GTM执行能力如何。几乎每个新的云安全提供商都在纠结“我们是Wiz的竞争者吗”的问题，只有Upwind敢于说：“是的，我们更优秀。”

Sweet Security

Sweet Security专注于云原生运行时安全。他们的主要产品利用eBPF传感器，旨在帮助组织实时检测和主动响应云威胁。

Sweet Security的一个关键差异在于其多层次的云安全方法，该方法在整个云堆栈中集成了保护措施——从基础设施和应用程序到API、身份和网络交互。这种整体覆盖确保了在技术堆栈的不同层面上提供全面的实时保护。结合每个层面内强大的异常检测引擎，Sweet Security承诺在云工作负载中提供全面的运行时安全。

多层次的方法意味着Sweet Security适合多个类别：

  1. 云检测与响应（CDR）：Sweet Security的云检测与响应解决方案监控和分析来自所有主要云服务提供商（AWS、GCP、Azure、Oracle）的日志，以及托管服务和虚拟机，以在私有、公有、混合和多云环境中提供实时攻击防护。

  2. 工作负载保护：Sweet Security使用eBPF传感器监控云资源，如主机和虚拟机，检测任何异常或漏洞。他们通过可达性分析进行漏洞扫描，并有独特的创新将工作负载和云告警结合在一起。

  3. 应用检测与响应（ADR）：应用层检测能力仍在实验中，但Sweet对功能执行和代码上下文有足够的可见性，成为少数几个适合这一类别的以云为中心的公司之一

  4. 网络检测与响应（NDR）和API安全：Sweet Security的行为分析提供了网络活动的基线监控，包括第7层交互，这有助于识别零日攻击和可能被忽视的可疑网络模式

  5. 漏洞管理：Sweet Security提供由eBPF代理驱动的强大可达性数据，用于评估漏洞，依据关键标准——例如它们是否加载到应用程序内存中、是否被执行、是否面向公众、是否可被利用或是否可修复——以聚焦于真正重要的威胁。

Sweet Security特别强调非人类身份（NHI），例如服务账户、API密钥和OAuth令牌，以在运行时检测可疑活动。他们对这些工作负载身份有深入的可见性，这些身份正成为安全领导者日益关注的焦点。

在Sweet Security的安全平台核心是一个信念：运行时是一种更好的云安全方式。他们对竞争对手的关注较少，更多的是关注为大大小小的团队提供真正的安全价值。

ASPM主要厂商

Jit：ASPM的代码示例

在我们的初步报告中，我们讨论ASPM解决方案及其在更广泛的代码到云生态系统中的作用。Jit是一个ASPM（应用安全态势管理）平台，旨在使开发人员能够掌握其代码的安全性。这是“安全左移”背后的方法论，通过将OSS和商业扫描器（用于SAST、DAST、SCA、秘密检测、CSPM等）的能力直接整合到开发人员的工作流程中来实现。简单来说，Jit建立在这样的前提上：开发人员对安全编码实践的掌握只有在他们不需要离开编码环境时才能实现。

在整体安全态势的开发和推进方面，Jit通过其“安全计划”解决软件供应链安全问题，这些计划将安全措施与业务目标和要求对齐。这些计划指导用户实现特定的业务目标，同时确保认证准备就绪。一些显著的计划包括AWS基础技术评审（FTR）、Jit MVS for AppSec和OWASP十大合规框架。

一个关键的差异化因素，特别是对于受监管环境中的组织，Jit不会从客户的SCM环境中提取源代码。相反，Jit直接在客户的SCM中执行所有安全控制（例如，使用 GitHub Actions）。此外，鉴于在当今经济中未来保障的重要性，Jit构建了一个开放且可扩展的平台，允许用户集成自己的安全工具，而不是开发专有工具。这确保了一个针对个体需求量身定制的统一安全体验。

CSPM作为ASPM的一部分

一个新兴趋势是，随着安全左移的兴起，越来越多的公司将CSPM（云安全态势管理）集成到他们的产品中。Jit也不例外。

Jit的CSPM与Wiz、Prowler等集成，通过帮助云安全团队和开发人员维护安全合规的云环境，增强其安全套件。它自动化关键安全任务，持续监控云基础设施中的错误配置、政策违规和合规缺口，覆盖AWS、Azure、GCP及其他云服务提供商。

连接代码到云端

在云原生企业部署多个微服务时，安全团队常常难以确保来自不同开发团队的代码符合安全标准。通过将Jit的自动代码扫描和漏洞检测集成到CI/CD管道中，云安全团队可以确保在所有开发团队中一致地应用安全措施。

与其在部署后等待安全检查和修复，Jit在开发者的工作流程中原生集成，确保在代码开发和推送时进行安全检查、漏洞扫描和配置审计。

在快速发展的DevOps环境中，快速开发周期已成常态，手动安全检查会造成瓶颈。Jit帮助开发人员在推送新功能时自我管理安全检查，通过自动化在代码提交时强制执行的预先批准的安全政策。这种方法减轻了安全团队的负担，同时确保合规性和部署速度。

其他主要厂商包括Cycode、Aikido、Ox、ArmorCode和Apiiro。在早期的文章中，Francis曾撰写关于Cycode和Aikido的内容。

云检测与响应 (CDR)主要厂商

云检测与响应工具能够检测常见云工作负载（容器和Kubernetes）中的恶意活动，并将其与其他云服务进行上下文化，从而在云环境中创建单一的攻击路径。

Armo

ARMO对Kubernetes生态系统的承诺是无与伦比的，他们的开源项目Kubescape已捐赠给云原生计算基金会（CNCF）——它仍然是了解Kubernetes环境安全态势的起点。最近，ARMO在云安全领域取得了重大进展，并扩展了其eBPF代理的功能，以实现可操作的修复和检测能力。虽然ARMO将继续专注于Kubernetes解决方案，但随着云的运行时方面日益重要，他们的定位也非常合适。

Rad Security

Rad Security在CNAPP中是一个令人惊叹的增长故事。联合创始人Jimmy Mesta撰写了Kubernetes的OWASP前10名，只有ARMO对云计算核心的安全承诺与Rad Security一样真诚。现在，从重新品牌到使用eBPF代理进行基线，Rad Security更加全面地关注运行时云安全。Rad Security继续扩展其云运行时保护能力，同时保持DevOps团队长期以来喜爱的Kubernetes创新。随着市场继续寻找与其CSPM的运行时补充，Rad Security在成为该解决方案方面处于良好位置，同时为其基线方法产生了很多关注。

其他主要厂商包括之前提到的Sweet Security和Upwind，以及在无代理方面的 Stream和SkyHawk。

应用程序检测与响应 (ADR)主要厂商

应用检测与响应（ADR）为安全团队提供了对其应用程序的可见性、检测和响应。它向安全团队展示用户如何与其应用程序交互、服务之间的通信、应用程序如何与其托管容器交互，并提供工具，使非开发人员能够调查和响应应用程序威胁。它们检测和关联常见的应用程序攻击，如OWASP前10名、欺诈和滥用，以及利用脆弱库的攻击。请在此阅读Latio对ADR的全面探讨。

Miggo

Miggo是ADR领域中为数不多的产品之一，通过利用分布式追踪来全面审视应用程序。他们使用现有的遥测工具，或利用“无代码”部署方法来收集分布式追踪数据。然后，他们将这些数据应用于安全用例，检测通常对安全运营中心（SOC）不可见的攻击，例如注入或跨站请求伪造尝试。他们的主要差异在于能够向您展示跨应用服务的完整攻击场景。

Oligo Security

Oligo Security采取了一种优雅的方法，将检测能力扩展到应用程序中，而无需任何应用级别的仪器。它们将库活动基准化为所进行的系统调用类型，然后可以在运行时检测偏差，从而实现强大的零日漏洞检测。除了检测，像Oligo这样的工具还具有独特的能力，可以阻止函数级别的执行——及时阻止漏洞攻击。

Raven.io

Raven采取了通过监控应用程序和库活动来寻找应用程序攻击的方法。他们能够检测针对库的应用程序漏洞，并利用运行时执行数据来过滤漏洞噪声。Raven在最大化他们在运行时收集的数据方面采取了更全面的方法，但也可以直接阻止主动攻击，或主动修补漏洞。

Kodem

Kodem在ADR领域构建了自己独特的解决方案，专注于本地应用上下文，但更强调他们的运行时检测机制如何用于减少漏洞误报。他们是唯一将这种可达性方法应用于SCA和SAST的运行时扫描器。

其他主要厂商包括Contrast、Traceable和Datadog。

Remediation

Dazz Security

尽管许多公司在云原生应用保护平台（CNAPP）上进行了大量投资，但他们常常难以管理由云日志或安全工具本身生成的大量告警和问题。Dazz提供了解决方案：一个与厂商无关的平台，旨在映射代码到云的管道，关联安全数据，并在开发者的工作流程中无缝推动修复。

Dazz的核心差异化因素

Dazz的核心是其专利能力：

  1. 数据关联和根本原因分析——Dazz擅长对来自不同开发、基础设施和安全工具的数据进行标准化和关联。通过这些关联数据，Dazz将告警直接链接到其根本原因。

  2. 修复指导和修复方案——Dazz为开发者提供安全问题的洞察、推荐的修复方案和加快修复的行动力。

统一修复与应用安全程序管理

许多企业使用像Wiz和Palo Alto这样的CNAPP工具，这些工具在可见性和检测方面表现出色，但在减少告警噪音和实现高效修复方面往往不足。Dazz与领先的CNAPP 平台无缝集成，并通过来自开发、应用安全测试（AST）和其他工具的额外上下文进一步对其进行上下文化。

Dazz通过其专利的数据关联引擎弥补了这一差距，该引擎专门针对应用安全态势管理（ASPM）量身定制。通过摄取和关联企业云基础设施和应用层的安全数据，Dazz分析大量警报并将其与关键根本原因关联起来，从而使安全团队能够优先处理最关键的漏洞。

根本原因分析：修复重要问题

Dazz的高级根本原因分析能力帮助组织高效地解决漏洞。一个突出的特点是Dazz对Terraform和Docker的根本原因分析，使DevOps团队能够直接追溯云基础设施漏洞到源代码。这显著减少了修复时间，并允许开发人员在常规工作流程中解决问题，最小化干扰。通过专注于修复CVE、错误配置和暴露风险，Dazz确保DevOps团队能够有效修复那些带来最大风险的漏洞。

Dazz正在看到对其ASPM功能的需求不断增加，因为企业寻求能够融入其开发工作流程的工具。Dazz提供去重、修复指导和告警聚合，使其成为希望简化安全操作的组织的首选解决方案。

该领域的其他主要厂商包括面向应用的解决方案，如Phoenix和Armorcode，面向云的解决方案，如Opus、DevOcean和Zafran，以及通用漏洞管理提供商，如Vulcan和Brinqa。

市场其他部分厂商

一些我们没有重点介绍的厂商，但未来肯定会涵盖他们。然而，我们想要承认有一些重要的厂商，如Aqua Security、Lacework（Fortinet）、Datadog、Checkpoint Cloud Guard、Tenable、Qualys 和Caveonix Cloud等，值得一提。

总结思考

我们相信，关于CNAPP的讨论将在未来几年继续发展，本报告的目标是帮助框定这些未来的发展。尽管存在一些挫折感，CNAPP仍然主导着网络安全的讨论：安全团队表示他们希望减少工具，同时抱怨这些庞大臃肿的平台有多嘈杂。大型CNAPP拥有资金和分发渠道，但初创公司则拥有创新。

向前看，我们认为行业面临一些关键问题。

  1. 安全团队真的准备好超越“仅仅可见性”了吗？早期的运行时转变并未赢得市场，但也许安全团队终于准备好认真对待生产安全。

  2. 你能在同一平台上为开发者和SOC设计用户体验吗？开发者和SOC分析师很少在任何事情上达成一致，除了他们都烦恼于必须如此频繁地互相打扰。

  3. 最后，关于平台整合的讨论仍在不断发展。客户是否希望有一个同时具备代理和无代理功能的产品，由同一厂商提供所有的应用安全和安全运营中心工具于一个解决方案中？还是客户对最佳产品的解决方案感到满意？左右两侧的整合，以及应用、云和运营团队的整合正在进行。所有的用例真的可以在一个地方得到覆盖吗？它们应该被覆盖吗？

最终，解决这些问题的厂商将继续赢得市场。无论如何，本报告旨在解释我们是如何走到这一步的，以及那些通过让我们的云变得更加……安全——或者至少更嘈杂——而赚取大量利润的厂商。

原文链接：

https://softwareanalyst.substack.com/p/redefining-cnapp-a-complete-guide

声明：本文来自安全喵喵站，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。