CNAPP 满足了云原生应用程序和基础设施从开发到生产的全生命周期保护需求。负责云安全策略的安全和风险管理领导者应利用这项研究来分析和评估新兴的 CNAPP 产品。
主要发现
-
云原生应用和基础设施的攻击面不断扩大，攻击者将攻击重点放在运行时环境，包括网络、计算、存储、身份和权限，以及云管理和控制功能的错误配置。此外，API 和软件供应链本身也成为潜在攻击的目标。
-
云原生应用保护平台 (CNAPP) 市场经历了大幅增长，并伴随着收购和整合的趋势。虽然存在众多提供商，但只有少数提供商提供具有所需功能广度和深度的综合平台，尤其强调通过开发和运营流程实现无缝集成。
-
随着运营职责转向开发人员和云架构师，对高级工具的需求也随之增长，以解决漏洞、部署基础设施即代码和管理生产实施，以适应这一扩大的范围。由于开发人员将安全视为障碍，因此在开发过程中主动识别和确定风险的优先级，同时为开发人员提供足够的背景信息至关重要。
建议
负责云安全策略的安全领导者应该：
-
通过采用 CNAPP 产品来保护云原生应用程序并应对日益增长的攻击面。这些解决方案可防范运行时环境中的威胁、缓解云基础架构中的错误配置，并简化整个开发体验中的安全集成和协作。
-
利用 CNAPP 加强对网络、计算、存储、身份、权限、API 和软件供应链攻击的防御，从而降低潜在风险并保护关键资产。
-
优先考虑全面统一的 CNAPP ，提供广泛的功能以及必要的功能广度和深度，以便无缝集成到整个开发生态系统和云平台环境中。
-
选择短期合同可以灵活适应市场不断变化的动态。这可确保组织始终采用最适合其需求的 CNAPP 解决方案。没有一家供应商能够提供涵盖所有领域的最佳功能。
-
组建一个由安全运营、云安全架构、应用程序安全和开发运营方面的专家组成的跨职能团队来评估和选择 CNAPP 产品。
-
优先考虑那些能够满足开发人员和云架构师日益增加的运营责任的解决方案。强调需要使用先进的工具来有效解决云和应用程序的安全风险、高效管理生产实施，并为开发人员提供足够的背景信息以克服安全障碍，同时促进协作方式以实现安全的应用程序开发。
战略规划假设
-
到 2029 年，60% 未在其云架构中部署统一 CNAPP 解决方案的企业将缺乏对云攻击面的广泛可见性，从而无法实现其期望的零信任目标。
-
到2029 年，超过 80% 的企业将采用集中式平台工程和运营方法，以促进 DevOps 自助服务和扩展，而 2023 年这一比例还不到 30%。
-
到 2029 年，35% 的企业应用程序将在容器中运行，而 2023 年这一比例还不到 15%。
市场定义
云原生应用保护平台 (CNAPP) 是一套统一且紧密集成的安全和合规功能，旨在保护云原生基础设施和应用程序。CNAPP 集成了一套集成的主动和被动安全功能，包括工件扫描、安全护栏、配置和合规性管理、风险检测和优先级排序以及行为分析，提供从代码创建到生产运行时的可见性、治理和控制。
CNAPP 解决方案结合使用与领先云平台提供商的 API 集成、持续集成/持续开发 (CI/CD) 管道集成以及代理和无代理工作负载集成，以提供综合的开发和运行时安全覆盖。
CNAPP 的出现是为了在DevOps风格的框架中为现代云原生应用程序提供增强的可视性、配置和合规性监控以及补救措施。这些产品将一组分布式功能整合到一个集成平台下，与底层超大规模云提供商无关。它们有助于识别、优先处理和补救由云架构部署、应用程序开发和云安全运营的动态和复杂过程导致的风险。
CNAPP主要通过云提供的即服务解决方案销售和交付，旨在保护基础设施即服务 (IaaS) 和平台即服务 (PaaS) 公共云环境以及相关的运行工作负载和应用程序。
CNAPP的组合功能为开发团队、云架构团队、基础设施安全和安全运营团队提供了一个协作平台，用于识别和确定云风险的优先级。它使这些团队能够在云原生应用程序开发过程中在单一的统一平台上进行有效沟通。这可以实现强大、成熟和安全的云原生应用程序开发，同时最大限度地降低与编码和现代应用程序部署相关的业务风险。
强制功能
该市场的强制性特征包括：
-
通过 API 与超大规模云平台（至少包括 AWS、Microsoft Azure 和 Google Cloud Platform [GCP]）和 Kubernetes 集成，以审查和审核配置和身份权限，以发现导致安全漏洞的常见配置错误。
-
开发操作工作流在现代应用程序的开发生命周期中提供风险分析和风险优先级排序。平台至少应提供基础设施即代码扫描和容器注册表扫描。
-
实时或通过时间点分析查看工作负载的运行时状态，以发现安全漏洞以及云工作负载（虚拟机、容器和无服务器）中存在的秘密和异常行为，并使用这些信息为云配置结果添加上下文。
-
解决方案是通过云提供的“即服务”平台提供的，而不是松散耦合的产品组合。
通用功能
该市场的通用功能包括：
-
生成综合报告、仪表板和可视化效果，向相关利益相关者传达安全态势和补救进展。
-
用于根据常见合规性标准进行基准测试的预定义模板。具体示例包括来自互联网安全中心 (CIS)、美国国家标准与技术研究所 (NIST)、国际标准化组织 (ISO)、支付卡行业 (PCI) 和美国健康保险流通与责任法案 (HIPAA) 的标准。
-
与不太常见的通用云和 Kubernetes 平台（如 OCI、IBM、OpenStack 和 OpenShift）集成的选项。
-
集成到基于 Web 的 CI/CD 管道和/或直接与开发人员集成开发环境 (IDE) 集成。
-
与其他常用工具集成，例如服务器终端保护工具和本地云和编排平台，以及与 SIEM/SOAR/TDIR/SOC 平台集成。
-
能够与第三方应用程序安全态势管理 (ASPM) 和应用程序安全测试 (AST) 工具集成以获取背景信息，或将这些工具内置在平台中。
-
提供结构化的开发人员工作流程并提供可随应用程序开发扩展的安全护栏，以适应多云采用的动态特性。
-
软件成分分析、软件物料清单（SBOM）和管道强化。
-
工作负载架构图和攻击路径分析，包括已知漏洞和异常行为的攻击载体映射。
-
运行时工作负载漏洞管理。功能包括虚拟修补和工作负载隔离/分段，以及正在运行的服务/流程的管理。
-
能够提供API 发现、扫描和保护服务，或提供与第三方 API 保护解决方案集成的方法。
-
除了基本工作负载监控之外，还扩展了云检测和响应 (CDR) ，以实现高级关联和补救。
-
集成或自行交付的 ASPM，包括但不限于应用程序安全测试、应用程序漏洞管理、API 安全测试和补救工作流管理。
-
支持AI/ML 集成以丰富策略、提出建议或解释通用语言。
市场描述
保护云原生应用通常需要来自不同供应商的多种工具，这些工具缺乏交叉集成，主要为安全专业人员设计，忽视了与开发人员的协作。因此，这种集成的缺乏导致对风险的看法支离破碎，背景有限，难以有效地确定整体业务风险的优先级。使用分散的工具还会导致过多的告警，浪费开发人员的时间，使补救工作复杂化，并导致目标角色混乱。
在现代 DevSecOps 环境中，一个关键挑战是满足参与开发和保护云原生应用程序的所有利益相关者的期望。传统上，开发团队、云架构团队和安全运营团队彼此独立运作，导致缺乏跨团队沟通。在开发云原生应用程序的复杂过程中，每个团队使用不相连的工具进一步加剧了这种差距。
云原生应用通常具有以下特征：
-
使用容器内的离散代码函数构建，作为松散耦合的微服务运行，通常通过应用程序编程接口进行交互
-
在 DevOps 风格的持续集成 (CI)/持续交付 (CD)管道中开发，支持频繁更新并使工作负载及其微服务更加短暂
-
使用自定义代码库和开源代码库以及来自开源或私有存储库的组合
-
部署到程序化云基础架构上，将应用程序从基础架构依赖关系中抽象出来，并以弹性方式利用云共享基础架构，根据业务需要进行扩展和缩减
-
管理偏向于不变性，因此不允许对生产工作负载进行太多更改或根本不进行更改（生产中的所有更改都通过开发流程来驱动）。
CNAPP 提供一套整合且紧密集成的主动和被动安全功能，旨在确保在云原生应用程序的整个开发和运营阶段的可见性、配置合规性、代码分析和风险评估。理想情况下，这些功能应无缝集成到现代 DevOps 风格的框架中，而不管底层超大规模云平台如何。CNAPP解决方案通过主动解决由已知、未知和意外暴露引起的风险来补充安全态势，而这些风险又源于开发和部署云原生应用程序的动态和复杂性。
CNAPP 旨在对应用程序和云环境的各种元素和特征进行全面分析，重点是让开发人员能够承担应用程序风险（见图 1）。将这些功能整合到统一引擎中，为组织提供了一个集中且有凝聚力的平台，可以在现代云原生应用程序复杂的逻辑边界内主动识别和缓解过度风险。
图 1：CNAPP 简化视图
CNAPP 平台主要通过云提供的即服务产品作为单一集成解决方案进行销售和交付，旨在保护基础设施即服务 (IaaS) 和平台即服务 (PaaS) 平台以及这些环境中正在运行的工作负载。CNAPP 解决方案通过以下方法集成到公有云环境中：
-
通过 AP I进入云服务提供商 (CSP) ，作为 CSP 原生功能进行配置、合规性、身份和风险分析，通常由云安全态势管理 (CSPM)、Kubernetes 安全态势管理 (KSPM) 和云基础设施授权管理 (CIEM) 提供
-
通过 API 或基于代理的部署进入云工作负载运行时环境，进行运行时监控和风险分析，通常由云工作负载保护 ( CWP )提供
-
进入开发流程工具，为编码开发团队和云架构团队提供工作流程和合规性护栏
-
为开发团队进行代码和应用程序测试所需的补充工具集成提供支持
CNAPP 解决方案可解决单云或多云环境中的风险（见图 2）。这种集成促进了开发人员、架构团队和安全运营团队之间的沟通和协作，从而推动了强大而安全的应用程序开发流程，并确保了运行时环境中工作负载的安全（见图 3）。
图 2：云原生应用程序风险面激增
运行时风险可见性只是风险方程式的一部分。开发人员和云架构师越来越多地负责构建图2中所示的更多云基础设施，包括使用基础设施即代码脚本设置的容器和云基础设施（参见图 3 ）。此外，安全运营团队发现，管理已发布工作负载中发现的运行时漏洞具有挑战性。
安全运营团队不负责代码更改，但在某些情况下，他们负责补救工作。因此，需要 SecOps 和负责的开发人员之间进行更好的协作，以确定补救工作的优先级。CNAPP 产品通过整合应用程序开发团队、云架构和配置团队以及安全运营团队（如图3 所示），实质上将三个以前孤立的团队拉近了距离。
图 3：开发人员和架构师对云原生应用程序的责任范围扩大
由于开发人员正在创建容器、无服务器功能和云基础设施，CNAPP 工具已转向开发阶段——除了图 5所示的全面运行时可见性之外。将风险可见性转移到开发需要深入了解开发流程和工件，并在创建这些工件时尽早扩展漏洞扫描（参见图 4 ）。
图 4：代码到云的风险可见性、优先级和补救措施
结合运行时风险可见性、云风险可见性和开发工件风险可见性的需求，形成了完整 CNAPP 平台所需的一套强大的集成功能（见图5 ）。
目前，没有一家供应商能够提供表 2 所示的所有功能。
图 5：CNAPP 详细视图
市场方向
自2022 年中期确定 CSPM、KSPM、CIEM、 CWP与其他云安全技术之间的融合以来，客户兴趣（如Gartner 咨询量增长所示）显著增长。2023 年至 2024年，最终用户对 CNAPP 的反馈增长了 29%，重点关注由合规性和易于 API 部署驱动的 CSPM，并期望运行时可见性和控制。
CNAPP 的预算通常来自首席信息安全官组织，具体购买包括云安全运营、云安全架构师、开发/产品团队、DevSecOps 架构师、云原生应用程序架构师和应用程序安全。Gartner 观察到主要买家格局发生了显著变化，安全/应用安全团队发挥着更具影响力的作用。这一趋势伴随着平台工程团队领导者以及云和应用程序架构师的出现，以及对安全协作的更大重视。这些利益相关者不仅在购买决策中具有影响力，而且对 CNAPP 解决方案提供的功能表现出浓厚的兴趣。
有几个因素推动了客户对 CNAPP 的兴趣。
-
最重要的是需要统一云环境和整个应用程序开发生命周期中的风险可见性。使用单独的、孤立的安全和遗留应用程序测试产品根本无法实现这一点。CNAPP产品通过“连接点”来实现云原生应用程序风险分析，以帮助了解现代云原生应用程序的多个层面上的有效风险。对风险发现进行优先排序至关重要，因为开发人员和安全专业人员被孤立工具的警报和发现所淹没。
-
另一个驱动因素是希望通过将来自不同供应商的多个重叠安全功能整合到一个统一平台中来减少使用多个网络安全供应商和工具所带来的复杂性和盲点。这一过程不仅可以降低总体拥有成本并最大限度地减少技术债务，而且需要更少的人员来运营，改善运营管理，并减少分析整个生态系统风险的工作量。
-
客户还希望将安全性和合规性测试无缝透明地集成到现代 DevOps（称为 DevSecOps）中，以平衡安全性和速度，同时又不会不必要地减慢数字创新的速度。信息安全的角色转变为在整个开发流程中提供护栏，并避免在整个开发过程中限制开发人员。例如，设想一条赛道，驾驶员只有在出现严重问题时才会遇到护栏。同样，除非发现关键风险问题，否则开发人员可以按照自己想要的速度进行创新，而几乎不会受到安全方面的阻碍。CNAPP 产品支持为现代云原生应用程序开发流程构建护栏。
这些驱动因素的存在对买家的决策过程产生了重大影响，迫使 CNAPP 供应商调整其能力并进行重大平台变革。这种调整包括引入本地开发的功能或收购和集成互补平台以满足买家不断变化的需求。
CNAPP 产品主要集中于针对开发工件中已知漏洞、错误配置和硬编码秘密的扫描工作。这是通过结合使用静态和动态技术来实现的。另一方面，传统的静态和动态分析应用程序安全测试工具专注于使用类似的技术发现自定义代码中的未知漏洞。因此，CNAPP 产品和应用程序安全产品相互补充，但它们的功能越来越重叠。
为了获得对风险的最全面了解，请同时使用 CNAPP 和应用程序安全工具。因此，越来越多的 CNAPP 供应商要么开发自己的功能，要么提供具有这些特定功能的第三方集成。旨在提供涵盖云和应用程序风险管理各个方面的全面解决方案。在未来几年中，Gartner 预计几款 CNAPP 产品将扩展到以下领域：
-
应用程序安全测试 (AST)，例如传统静态 AST 和动态 AST (SAST/DAST) 用例
-
应用安全态势管理 (ASPM)
-
API 发现和测试工具以及 API 态势管理
-
用于应用程序保护的分布式 Web 应用程序防火墙 (WAF)
-
云检测与响应 (CDR)
-
针对特定数据管理用例的数据安全态势管理 (DSPM)
所有这些预计将在未来几年内推动 CNAPP 市场大幅增长。虽然 Gartner 尚未确定 CNAPP 市场的规模，但它具有重叠的功能，并将从构成 CNAPP 功能核心的几个独立市场中获取收入（见表 1）。
表1 ：CNAPP 支出将从这些细分市场中拉动
| Gartner 市场预测 | 2023 年底预计市场规模（按固定汇率计算，数十亿美元） | 2024 年市场百分比增长预估（按固定汇率计算） |
| 云安全态势管理 (CSPM) | 1.4 | 26.3 |
| 应用安全测试软件 | 1.8 | 27 |
| 云工作负载保护平台 (CWPP) | 3.9 | 27.9 |
| 漏洞评估 | 2.2 | 14.8 |
| Web 应用程序和 API 保护 | 1.7 | 16.2 |
来源：Gartner（2024 年 5 月）
CNAPP 产品的优势
一个组织可以实施 10 种或更多种工具来充分实现表 2 所示的功能。但是，组织有理由转向 CNAPP 产品中的整合：
-
它通过一个集中统一的平台更好地识别、优先排序和补救云原生应用程序风险，并在多团队结构中提供可操作的见解。
-
CNAPP通过整合供应商、控制台、策略和合同来降低运营复杂性，从而减少配置错误或失误的可能性。这样可以：
o 单一协作平台，在整个开发和运营过程中定义一致的安全策略
o 无论超大规模云环境如何，在所有应用程序构件（代码、容器、虚拟机 (VM) 和无服务器功能）中一致执行安全策略
o 消除不同产品的重叠策略，并实现所有开发工件中应用程序策略和策略对象的标准化
-
CNAPP 供应商应为所有事件日志记录、报告、告警和关系映射实施单一数据湖、数据模型和统一图形数据库。这使供应商能够提供有效的风险分析——找到风险的根本原因，确定负责修复风险的人员/团队，并根据风险优先考虑补救措施。这可以减少攻击面并缩短补救时间。
-
通过始终如一地执行策略并根据风险优先考虑补救措施，统一的CNAPP产品应能减少开发人员的摩擦并改善开发人员的体验。通过在整个生命周期中集成安全测试并将其直接集成到开发人员的工具集中（而不是在生产之前进行一次大型测试），CNAPP 产品可以主动实现以下功能：
o 尽早主动解决问题
o 缩短应用程序部署时间
o 通过监控运行时环境的反应工具集最大限度地减少发现的运行时漏洞
-
CNAPP 消除了冗余功能（例如，大多数云提供商都提供容器漏洞扫描）。
-
这些产品极大地提高了运行时可见性，因此可以将其用作反馈给开发团队的背景。同样，单一平台更容易实现开发可见性，以加强运行时保护（见图 6）。
-
CNAPP 弥合了以前孤立的开发团队、安全架构团队和安全运营团队之间的沟通鸿沟，并对整个云环境的风险有了一致的看法。
图 6：双向协作
采用CNAPP面临的挑战
-
安全组织购买角色：多个团队对云原生应用程序安全负有部分责任，因为这被视为一项共同责任。这些团队分布在数据中心安全、应用程序安全和云架构以及信息安全等各个领域。每个团队都有解决部分云风险难题的工具，但这些团队很少在产品评估和选择方面进行合作。一些团队会更喜欢满足他们迫切需求的特定工具，并会避免改变。
-
开发人员和安全团队之间的对抗关系：开发人员认为安全团队阻碍了现代 DevOps 流程的速度。安全控制并非针对云原生应用程序的速度和规模而设计，也并非以开发人员为中心客户而设计。从历史上看，结果是集成度低的测试，要求开发人员离开他们的开发环境，从而减慢开发速度，并将他们的时间浪费在误报上或要求他们修复低风险漏洞。
-
现有投资：许多组织都存在来自各种小众供应商的技术债务，以涵盖代码、云安全和合规性。大多数组织已经在其虚拟机中拥有某种形式的运行时 CWP，例如现有的传统终端检测和响应 (EDR) 解决方案。许多公有云采用者选择了正在开发的容器扫描工具，并引入了独立的 CSPM 解决方案。大多数组织都有多个供应商提供不同的（或有时类似重叠的）功能，从而造成用户和发现的孤岛，并且很难创建统一的风险图景。随着组织转向基于 CNAPP 的方法，集成平台的协同作用将比难以扩展的最佳策略提供更多好处。
-
思维方式的改变：安全团队必须理解并承认，完美、无风险的应用程序是不可能的。完美是足够好的敌人。相反，安全团队应该专注于识别最高严重性、最高置信度风险的方法，并将风险优先级的补救措施交给负责任的开发人员。同样，从开发人员的角度来看，云原生安全成为一套风险优先级的护栏（取代了开发过程中以前的安全“门”模型），从而将更多的责任放在开发人员身上，这可能会阻碍采用。
-
架构：一些 CNAPP 产品被设计为仅作为 SaaS 产品提供。其他产品则被设计为完全在客户环境中运行。最好的产品将使用分布式云架构，具有云管理控制平面和客户控制下的分散检查（例如，在本地扫描容器或快照，而无需将它们上传到 SaaS 服务）。一些 CNAPP 解决方案不提供扫描数据位置的选项，而是强制最终用户在公共云环境中进行扫描，这只会增加计算成本并阻碍 CNAPP 的采用。
-
成熟度：未来几年，CNAPP 功能将继续存在很大差异，一些供应商在多个领域还不成熟。例如，敏感数据可见性和控制通常是客户的优先能力，但对于许多 CNAPP 供应商来说，这很难解决。了解非结构化和结构化存储库中的数据上下文对于充分了解和解决风险上下文和优先级至关重要，但许多 CNAPP 供应商尚未提供这一点。此外，不提供代理和无代理集成的 CNAPP 供应商限制了其解决方案的采用。
-
遗留应用程序：非完全云原生的旧应用程序可能需要专门的工具，并且更多地依赖传统方法，例如 SAST 和 WAF。
-
成熟的单一供应商产品：某些供应商声称他们能够涵盖 CNAPP 的所有元素和功能。然而，经过仔细研究，虽然这些供应商提供了更广泛的功能，但他们往往缺乏必要的功能成熟度和特定功能的专业化。
-
独立工具集成：一些 CNAPP 解决方案缺乏与其他供应商和独立工具的强大技术合作伙伴关系和全面的集成选项。这种限制可能会导致对风险的看法分散，并可能影响应用程序开发流程。然而，许多 CNAPP 供应商正在通过投资研发来积极应对这一挑战。他们正在努力通过提供与补充服务集成的选项来减轻这些限制。
市场分析
CNAPP 供应商的起源各不相同，其中一些最初专注于通过独立的 CSPM 功能支持开发和云架构。这些供应商通过引入工作负载运行时功能并结合代理和/或无代理工作负载监控来增强被动安全控制，从而扩展了其产品范围，以提供更具被动性的可观察性。另一方面，其他供应商起源于工作负载运行时领域并引入了互补功能，进一步向提供主动安全可见性和控制转变。
市场融合形成了 CNAPP 市场的基础。认识到需要改进编排合规性以及身份和授权管理，两个子市场的供应商都开发或获得了额外的功能来涵盖 Kubernetes 和身份权限管理。最终结果是建立了我们在当今市场上看到的全面 CNAPP。
CNAPP 产品可细分为几个基本来源：
-
最初源自EDR市场专注于运行时工作负载可视性和保护的供应商，或专门为容器安全而构建，并且之前已建立为 CWPP
-
最初专注于将安全性转移到开发领域的供应商，重点为 CSPM 提供云配置扫描、基础设施即代码脚本扫描和编排可视性和控制方面
-
最初专注于开发生命周期早期工件扫描的供应商，例如软件组成分析和 API 安全测试
-
最初提供成熟 CIEM 服务的供应商及其 CSPM 功能，为用户在云基础设施环境中为人力和工作负载实体提供更好的身份访问管理、授权和权限管理保护
与任何新兴技术类别一样，尤其是随着 CNAPP 在多个 Gartner 技术成熟度曲线中经历幻灭低谷，CNAPP在过去两年中受到了大量营销炒作和媒体滥用。CNAPP产品将多种不同的安全和保护功能整合到一个平台中，专注于识别和优先处理整个云原生应用程序及其相关基础设施的过度风险。
我们经常看到销售 CNAPP 的供应商不符合 Gartner 的最低要求。由于 CNAPP 功能的完整列表相当广泛，我们将这些功能分为三类：核心、推荐和可选（见表2 ）。
表2 ：CNAPP 核心、推荐和可选功能
| 核心功能 | 推荐功能 | 可选功能 |
|
|
|
| 与 CNAPP 相关的 DSPM 具体指在 IaaS/PaaS 环境中对非结构化数据存储的扫描和评估。 |
来源：Gartner（2024 年 7 月）
表 2 中的功能应具有一致性。架构良好的单一供应商 CNAPP 产品应具有以下特征：
-
所有核心服务都应完全集成，而不是松散耦合的独立模块（通常由供应商的内部孤岛、集成不良的 OEM组件或通过收购添加的组件造成）。集成应包括前端控制台、跨多个检查点的统一策略和统一的后端数据模型
-
深入了解应用程序元素（虚拟机、容器、服务功能和存储）、安全态势、权限和连接之间的关系，通常由底层图形数据库技术实现。
-
了解开发工件（自定义代码、库、容器映像、VM 和 IaC 脚本）之间的关系，以及谁创建了它们以及何时创建它们、谁部署了它们以及何时部署它们、谁更改了它们以及何时更改了它们。
-
集成高级分析与图形关系相结合，对开发和运行时发现的问题进行风险优先排序。
-
单一统一的管理计划减少了多个控制台之间的切换，而不是通过 API 松散集成的不同管理系统。
-
主要管理控制台通过即服务产品在云端交付。可选择提供对客户托管管理控制台的支持，以应对安全和风险敏感的环境，例如隔离环境或监管域。
-
检查所有工件：容器、虚拟机、无服务器功能和数据存储。
-
基于主要云原生应用程序资产（例如虚拟机、容器主机、无服务器功能和非结构化/结构化存储库）的简单基于消费的定价模型。
-
客户应能够灵活地决定在何处检查工件，无论是在云环境中还是在自己的控制下。这包括适合安全敏感用例的本地检查选项，以及利用云计算资源以降低成本的选择。
-
即使交付是基于云的，也可以选择单一租户（对于安全敏感的用例）。
-
与密钥管理系统集成，允许扫描加密存储对象的风险。
-
集成到 CI/CD 通用开发工具集，包括代码存储库、构建服务器和容器注册表及其审计/日志监控。
-
用于根据常见合规标准（例如 CIS、NIST、PCI、GDPR 和 HIPAA）进行报告的预定义模板。
-
支持所有三大超大规模提供商： AWS 、Microsoft Azure 和Google Cloud Platform ( GCP )。某些组织可能需要与其他云集成，例如Oracle 、IBM 、阿里云、VMware等。
即使在市场的早期阶段，市场上也有多种 CNAPP 产品满足这些核心要求。表 3列出了这些产品的供应商。
由于 CNAPP 市场中供应商的来源各异，因此功能分散，并且所提供的功能堆栈的成熟度级别因每个供应商的基础而异。因此，在评估 CNAPP 产品时，企业必须建立一个由开发、云安全架构和安全运营人员组成的协作团队。在评估不同的 CNAPP 产品时，该团队应优先考虑并排列其对核心、推荐和可选功能的需求。通过让所有相关利益相关者参与并协调他们的需求，组织可以做出明智的决策，并根据其特定需求选择最合适的 CNAPP 解决方案。
这些协作团队更深入地了解云原生应用程序的不同元素之间的关系（见图2 ）以及每个团队的成功重点。协作团队是在整个云生态系统中实现风险缓解愿景的关键一步。换句话说，为了使风险识别和补救措施可行，CNAPP 工具必须能够构建应用程序代码、库、容器、脚本、配置和漏洞的模型，以识别有效风险所在的位置。
由于不可能有无风险的应用程序，信息安全必须根据业务环境对风险发现进行优先排序，找出根本原因，并使开发人员能够首先关注对业务影响有最高信心的最高风险发现。同样，企业需要深入了解应用程序整个生命周期中开发人员/开发团队之间的关系（见图 3 和 4），这对于确定合适的开发人员/开发团队或工程团队来纠正已发现的风险并为这些团队提供足够的背景信息，以便快速有效地了解和补救风险至关重要。
对于云原生应用程序，IT 或信息安全很少负责修复已发现的问题。编写代码的开发人员才是责任人！
对于现代云原生应用程序，使用传统的基于主机操作系统的代理方法可能很困难，甚至不可能。在某些情况下，DevOps 产品团队不会接受它们，而在其他情况下，部署和管理代理的运营开销无法抵消对短暂工作负载的运行时可见性的价值。为了解决这个问题，领先的 CNAPP 产品提供了各种代理和无代理替代方案，以实现对工作负载的运行时可见性，包括：
-
正在运行的工作负载的快照以及对所创建快照的分析
-
特权容器
-
守护进程集
-
Kubernetes Sidecar
-
纳入开发流程的库
-
基于 eBPF 的Linux检测
-
LD_PRELOAD Linux系统调用拦截
-
Envoy或 F5 NG I NX代理集成
-
服务网格集成
-
云控制平面，基于 API 的集成，用于检查配置和活动日志
-
Kubernetes API 控制器集成以检查配置和活动日志
-
在隔离环境（应用程序沙盒）中挂载并动态观察的工作负载副本
-
特定于语言的运行时检测（有时称为 RASP）
-
无服务器函数检测分层技术（例如 AWS Lambda 层）
超大规模提供商正在积极投资生成式人工智能 (GenAI) 技术，并提供云人工智能开发者服务。一些 CNAPP 产品将其覆盖范围扩展到其中一些与 GenAI 相关的服务。
代表性供应商
希望满足云原生应用程序快速开发需求的云安全领导者应将 CNAPP 产品视为以开发人员为中心的集成解决方案。CNAPP可以通过尽可能无缝和透明地集成到其原生开发工具集中来改善开发人员体验。CNAPP 通过减少误报和噪音、通过风险优先级确定其补救措施并提供特定的补救指导来解决已识别的风险来实现这一点。CNAPP产品还可以帮助组织在整个开发生命周期（从代码到云）中在其开发流程中采用更强大的安全态势。
表 3列出了具有代表性的 CNAPP 供应商。为了编制具有代表性的供应商名单，我们使用了本研究的“市场分析”部分中描述的核心和推荐功能和特性。一些供应商销售多个模块来构建全套 CNAPP 功能。在市场的早期阶段，没有一家供应商拥有所有功能。
表3 ：代表性 CNAPP 供应商
| 供应商 | 提供产品 |
| Aqua | Aqua云安全平台 |
| Caveonix | Caveonix 云原生应用保护平台 |
| CrowdStrike | CrowdStrike Falcon 云安全 |
| Cyscale | Cyscale CNAPP |
| Datadog | Datadog CNAPP |
| Data Theorem | Cloud Secure |
| 谷歌云 | Google 安全指挥中心 |
| Lacework | CNAPP Security |
| 微软 | Microsoft Defender for Cloud |
| Orca Security | Orca 云原生应用保护平台 |
| Palo Alto | Prisma Cloud |
| Qualys | Qualys TotalCloud |
| Rapid7 | InsightCloudSec |
| SentinelOne | Singularity 云安全 |
| Sophos | Sophos 云原生安全 |
| Sysdig | Sysdig Secure |
| Tenable | Tenable 云安全 |
| Trend Micro | Trend Micro Cloud One |
| Uptycs | Uptycs CNAPP |
| Wiz | Wiz CNAPP |
来源：Gartner（2024 年 7 月）
市场建议
战略与规划
-
无论是否采用 CNAPP，都要为 DevSecOps 确立一个愿景，将开发人员体验作为首要目标。旨在通过改进安全协作来减少开发人员摩擦、更好地识别风险并减少误报。不要强迫开发团队放弃他们的原生工具，并提供具体的上下文和补救建议。
-
创建一个统一的 CNAPP 策略和评估团队，涵盖云安全、容器安全和应用程序安全、云架构和安全运营。云安全现在是一项共同责任，但开发人员是最终补救已识别风险的人，而 SecOps 团队应包括来自 DevSecOps/开发的代表。盘点组织的 CI/CD 管道工具，因为这将是评估过程的关键输入。
-
采用 CNAPP 产品来整合供应商，以降低复杂性、简化安全策略实施、提供更好的上下文和优先级，并改善开发人员体验。随着 CWP、CSPM、SCA、CIEM 和容器安全产品的合同续签，还有可能减少单点解决方案的重复成本。
评估
-
让联合开发/安全团队在发出信息/购买请求之前确定企业功能需求并将其排序为必需、首选和可选，因为没有任何一个供应商在所有 CNAPP 功能方面都是最好的。
-
利用深厚的关系图分析专业知识对 CNAPP 产品进行优先级排序。要识别云风险并根据风险优先级排序和缓解措施进行交付，就需要能够理解云原生应用程序不同元素之间的关系并了解每个元素的风险。这需要了解云控制平面风险和工件风险，然后将它们结合起来，以了解、确定优先级并补救整个系统的最终风险。
-
评估组织现有的安全 DevSecOps 工具组合，从开发到运行时安全运营。构建每个团队必不可少的矩阵，并找出 CNAPP 中的重叠部分。与团队合作，确定是否可以将工具整合到 CNAPP 中，而不会造成重大运营漏洞或安全漏洞。
-
在选择单一供应商 CNAPP 产品之前，请与真正的开发人员和应用程序一起运行功能试点，以确保功能和开发人员体验满足要求。
部署
-
将 CNAPP 部署重点放在正在开发的云原生应用程序上，而不是按原样迁移到云的应用程序上，开发速度至关重要，风险识别必不可少。即使无法全面部署 CNAPP，也请部署CSPM 和 CIEM 功能（如果尚未部署），因为大多数云原生应用程序风险都是由配置错误、管理不善或权限过多造成的。
-
将软件组成分析和扫描容器、OSS 库和依赖项以查找已知风险（常见漏洞和暴露 [CVE]、硬编码机密、密码、API 密钥等）作为高优先级，因为这是云原生应用程序中的另一个常见风险源。
-
在 CNAPP 部署中要务实，不要教条主义。代理可能提供最佳的可视性，但并非总是可行。尽可能使用由内而外的工作负载运行时可视性，在无法使用代理时使用无代理快照，因为对风险有一定的可视性总比没有好。
