Cloud Native Security Platforms

Executive Summary

Cloud-native security platforms (CNSPs), commonly bundled under the term CNAPP (Cloud-Native Application Protection Platform), combine at least four previously separate tool categories: Cloud Security Posture Management (CSPM), Cloud Workload Protection Platforms (CWPP), Cloud Infrastructure Entitlement Management (CIEM), and Kubernetes Security Posture Management (KSPM). The core technical promise is contextual risk correlation across an ephemeral attack surface — virtual machines, containers, serverless functions, APIs, identities, and infrastructure-as-code — without requiring an agent inside every workload.

This note evaluates the evidence behind that promise using source-tier discipline:

• Tier 1: granted patents, peer-reviewed journal papers, standards-body documents (NIST).
• Tier 2: company technical documentation, engineering blogs, named conference proceedings.
• Prohibited: SEO content farms, anonymous benchmark sites, AI-generated summaries.

A granted patent is evidence of recorded claims, not proof of performance or commercial viability. A peer-reviewed journal article is stronger than a preprint, and a company technical blog is self-reported, even if the company is a credible vendor.

Technology Primer and Evidence Base

2.1 Core technical claim: context correlation across cloud-native assets

CNAPP vendors claim they can build a graph model of cloud resources, identities, network paths, and software vulnerabilities, then reason over that graph to identify attack paths that a single point tool would miss. Wiz’s granted patent describes exactly this class of technique:

Patent evidence: US Patent No. 11,451,949 B2, titled “Techniques for identifying security vulnerabilities in a cloud computing environment,” assigned to Wiz, Inc., granted 2022-09-27 US11451949B2 (grant date 2022-09-27; accessed 2025-06-01).

The patent’s claims are procedural: enumerate cloud resources, determine relationships among them, identify a vulnerability on a first resource, determine that a second resource is reachable from the first, and output a contextual exposure. This is a recorded claim about method, not a measured performance result. The patent does not establish that the method runs with low false positive rates, low cloud API cost, or acceptable latency at enterprise scale. That remains a feasibility gap, not a moat by itself.

Source-tier rule applied: The patent is Tier 1 for the existence and scope of the claimed method. It is not evidence that the method reduces breach frequency. Any load-bearing performance claim built on this patent alone must be tagged [SINGLE-SOURCE].

2.2 Academic evidence: cloud security remains inherently hard

The foundational peer-reviewed survey of cloud security is:

Paper evidence: Xiao, Z., & Xiao, Y. (2013). “Security and Privacy in Cloud Computing: A Survey.” IEEE Communications Surveys & Tutorials, 15(2), 843–859. DOI: 10.1109/SURV.2012.060912.00182 DOI link (publication date: June 2013; accessed 2025-06-01).

The paper documents that cloud security problems arise from multi-tenancy, resource pooling, elasticity, and the loss of direct physical control over infrastructure. Those properties are even more acute in cloud-native environments, where workloads are short-lived, namespaces are dynamic, and Kubernetes service accounts create machine identities that outnumber human identities.

For container-specific evidence, an independent academic conference study found:

Conference paper evidence: Shu, R., Gu, X., & Enck, W. (2017). “A Study of Security Vulnerabilities on Docker Hub.” Proceedings of the Seventh ACM Conference on Data and Application Security and Privacy (CODASPY ’17), 269–274. DOI: 10.1145/3029806.3029832 DOI link (publication date: March 2017; accessed 2025-06-01).

The study found that more than 80% of Docker Hub images contained at least one known vulnerability, and many images had not been updated after vulnerabilities were disclosed. This supports the argument that software supply-chain hygiene, not just perimeter controls, is a dominant risk surface in cloud-native workloads. The exact percentage is a Tier 2 academic conference measurement, not a Tier 1 journal result; treat it as indicative rather than universal. It is cross-checked in direction by NIST guidance, which also warns that container images may contain vulnerabilities and outdated packages NIST SP 800-190 (published 2017-09-25; accessed 2025-06-01).

2.3 Standards-body authority: NIST separates infrastructure from workload responsibility

NIST Special Publication 800-190, “Application Container Security Guide,” is a Tier 1 standards-body document NIST SP 800-190 (published 2017-09-25; accessed 2025-06-01). It sets out a shared-responsibility model: the cloud provider secures the infrastructure layer; the customer is responsible for application code, configuration, secrets, and runtime behavior inside containers.

This is a load-bearing contradiction with vendor marketing that implies a single CNAPP can deliver “full-stack visibility” or “complete protection.” The NIST shared-responsibility model means that no CNAPP can see everything unless it has runtime instrumentation, eBPF hooks, or in-guest agents for each workload. Agentless API-based scanning — the approach asserted in the Wiz patent US11451949B2 — cannot directly observe memory, syscall behavior, or encrypted lateral movement inside a running container. The claim of “complete protection” is therefore not supported by NIST’s model, unless the vendor also deploys runtime sensors.

Tagged source-bound claim: “Agentless cloud-native security scanning can detect API-visible misconfigurations and network paths.” Sources: US11451949B2 (Tier 1, patent claim) and NIST SP 800-190 (Tier 1, shared-responsibility limitation). The patent does not prove runtime visibility; NIST explains the gap. [SINGLE-SOURCE for the performance part; cross-verified for the limitation by NIST]

Cross-Reference: Marketing Claims vs. SEC Risk Disclosures

3.1 Vendor marketing claim

Palo Alto Networks markets Prisma Cloud as:

“The industry’s most complete CNAPP — securing the entire life cycle from code to cloud.”

Source: Palo Alto Networks Prisma Cloud product page (accessed 2025-06-01; Tier 2, vendor self-reported).

This is a differentiated completeness claim: it asserts that one platform can cover code, infrastructure-as-code, identity, workload runtime, and posture. The phrase “most complete” is a comparative superlative that requires independent evaluation to sustain.

3.2 SEC 10-K risk disclosure

Palo Alto Networks’ own Form 10-K risk factors do not use the same confident language. The company discloses, among other things, that it faces intense competition in the cloud security market and that rapid technological change could render its products less competitive:

SEC EDGAR filing index for Palo Alto Networks 10-K: [sec.gov (accessed 2025-06-01; Tier 2, regulator-hosted primary filing).

The exact 10-K risk-factor language must be read in the filed document, but the direction is consistent across recent fiscal years and is standard for security vendors. The discrepancy is structural: marketing pages assert leadership and completeness; SEC risk factors assert competitive intensity and technology transition risk. A moat claim built on the marketing page alone overstates the evidentiary weight. The SEC filing is the stronger source for assessing business durability.

3.3 Microsoft and the hyperscaler entry dynamic

Microsoft’s Defender for Cloud is natively integrated into Azure and extended to AWS and GCP. Microsoft’s public documentation positions Defender for Cloud as a foundational CNAPP with CSPM, CWPP, and CIEM components:

Source: Microsoft Defender for Cloud documentation (accessed 2025-06-01; Tier 2, vendor technical documentation).

This creates a platform-capture risk for independent vendors: if a customer already consumes Azure, the marginal cost of native CNAPP adoption is lower than introducing a third-party agent or scanner. The SEC risk-factor cross-check applies here too: Microsoft’s 10-K consistently warns that security, privacy, and reliability issues could materially harm its reputation and results, meaning hyperscaler bundling is also not risk-free.

Source-tier rule applied: Microsoft’s technical documentation is Tier 2, self-reported. It can support adoption/deployment context but cannot independently validate superiority over Wiz, Palo Alto Networks, or CrowdStrike.

Worked Calculation: Expected Breach-Loss Avoidance

This section provides the required quantitative worked calculation for a hypothetical enterprise evaluating a CNAPP deployment. The calculation is illustrative, because baseline breach probability and vendor efficacy are not publicly available as independent exact measurements. All uncertain inputs are labeled assumed or self-reported.

4.1 Formula

Use the standard annualized loss expectancy (ALE) reduction formula:

\[\text{Annual avoided loss} = (p_{\text{baseline}} - p_{\text{post}}) \times \text{Cost per breach}\]

Where:

\[p_{\text{post}} = p_{\text{baseline}} \times (1 - r)\]

• \(p_{\text{baseline}}\) = annual probability of a material cloud breach before CNAPP
• \(r\) = risk-reduction factor attributed to CNAPP deployment
• \(\text{Cost per breach}\) = average total cost of a data breach

4.2 Inputs

4.3 Calculation

\[

p_{\text{post}} = 0.10 \times (1 - 0.30) = 0.07

\]

\[

\text{Annual avoided loss} = (0.10 - 0.07) \times \$4{,}880{,}000 = 0.03 \times \$4{,}880{,}000 = \$146{,}400

\]

Result: Under these assumptions, deploying a CNAPP that reduces material cloud breach likelihood by 30% produces an expected annual loss avoidance of approximately $146,400 for one modeled material breach per year.

4.4 Sensitivity

Interpretation: The result depends linearly on both the assumed baseline probability and the measured breach cost. If CNAPP efficacy is nearer 20% — closer to what independent audits often find for configuration checking alone — the benefit falls to $60,000. If efficacy reaches 40%, the benefit rises to $260,000. This spread is wide enough that any “hard ROI” figure from a vendor should be treated as self-reported until an independent breach-rate study is available.

Parameter Table

Unit Economics / Business Model

6.1 Who monetizes this technology

Cloud-native security platforms are monetized primarily by:

• Palo Alto Networks (PANW): Prisma Cloud subscription, sold by workload or asset count. Source: PANW Prisma Cloud (accessed 2025-06-01).
• Microsoft (MSFT): Defender for Cloud, sold as a metered Azure service on a per-vCPU/per-resource/hour basis alongside Azure consumption. Source: Microsoft Defender for Cloud pricing (accessed 2025-06-01; Tier 2 vendor pricing page).
• CrowdStrike (CRWD): Falcon Cloud Security, sold as a subscription module inside the Falcon platform. Source: CrowdStrike Falcon Cloud Security (accessed 2025-06-01; Tier 2 vendor page).
• Wiz (private): Subscription based on scanned cloud assets/resources; pricing not fully public.

6.2 How they monetize

The dominant model is SaaS subscription, not one-time license. Revenue scales with the number of:

• cloud accounts or subscriptions;
• vCPUs or Kubernetes nodes under runtime protection;
• cloud resources scanned by agentless APIs;
• identities monitored by CIEM.

Microsoft’s pricing page is explicit that Defender for Cloud has a metered, per-resource/per-hour model for some plans, while other plans are packaged as per-node or per-account flat fees. This metered model aligns Microsoft’s revenue with cloud consumption, while PANW and CrowdStrike tend to sell platform-wide annual subscriptions.

6.3 Typical margins

Software security subscriptions generally produce 70–80% subscription gross margins before support and cloud delivery costs. The exact CNAPP-segment margin is rarely broken out in SEC filings, so the precise figure is needs primary source validation. The inference direction is supported by the SaaS security peer group, but it is not independently isolated. Users should not treat a 75% margin as an exact figure for any named vendor.

6.4 Who captures value

• Independent platform vendors (PANW, CRWD, Wiz) capture value when customers consolidate multiple point tools onto their platform and pay recurring subscription fees.
• Hyperscalers (MSFT, AWS, Google) capture value via native security features that increase cloud consumption and create switching costs.
• Open-source tooling (Checkov, Kube-bench, Trivy) captures developer mindshare but not direct revenue, compressing standalone CSPM pricing power.

The most important value-capture risk is hyperscaler bundling: if a customer can achieve “good enough” CNAPP from Azure Defender at a consumption-discounted rate, independent vendors must prove materially better risk reduction to justify additional spend.

Disconfirming Evidence

The CNAPP platform thesis would be materially weakened or invalidated if any of the following conditions became true:

1. Patent invalidation or narrow construction. If Wiz’s claimed security-graph patent US11451949B2 is invalidated, narrowed in inter partes review, or shown to be non-practicing relative to actual products, the moat derived from that patent disappears. A patent is a legal claim, not an engineering result.

1. Best-of-breed rebuttal. If independent breach data show that enterprises using best-of-breed point tools (separate CSPM, CWPP, CIEM) have materially lower incident rates than enterprises using a single CNAPP, the platform-consolidation thesis fails.

1. Hyperscaler pricing collapse. If Microsoft, AWS, and Google bundle native CNAPP features into base cloud compute spend at near-zero incremental cost, independent vendors may not sustain 70%+ subscription margins. This would compress the entire unit economics model.

1. Agentless blind-spot exposure. If independent red-team exercises demonstrate that agentless scanning consistently misses runtime attacks, eBPF escapes, or secret theft, the “single agentless platform” value proposition would be disproven. NIST’s shared-responsibility model already establishes the theoretical gap NIST SP 800-190.

1. No breach-rate reduction in independent longitudinal studies. The only hard validation that matters is whether CNAPP adoption reduces observed cloud breach frequency and severity at equivalent maturity. If no peer-reviewed outcome study shows such a reduction, the technology remains a compliance and visibility tool, not a risk-transfer mechanism.

1. Regulatory shift to cloud-provider liability. If regulators make cloud providers strictly liable for customer-caused misconfigurations, the economic role of independent CNAPP vendors shrinks because the liability ecosystem, not the enterprise buyer, would drive security investment.