What Is Cloud-Native Security? Risks, Best Practices, Tools & How to Choose a CNAPP (2026)
A container can start, serve traffic and vanish before a quarterly scan ever notices it, and the permissions it used may have been granted by a Terraform file no security engineer reviewed. That is ordinary life in cloud-native systems: infrastructure is created by API calls, identities matter more than network boundaries, and source code, pipelines and production runtimes form one connected attack surface. Securing that environment calls for an operating model built on automation, context and shared ownership. This guide explains what that means, which risks matter most, which controls and tools fit where, and how to choose and test a Cloud-Native Application Protection Platform (CNAPP).
TL;DR
What it is: cloud-native security protects applications built on containers, Kubernetes, serverless functions, APIs, managed services and infrastructure as code across code, build, deployment and runtime. It is broader than container or Kubernetes security.
Main risks: misconfiguration, excessive permissions, exposed secrets, vulnerable images and dependencies, insecure CI/CD pipelines and weak runtime visibility. OWASP's 2025 Kubernetes Top Ten ranks insecure workload configuration and over-permissive authorization first and second.
Shift left is necessary, not sufficient: preventive controls, posture management and runtime detection answer different questions, and none replaces the others.
What a CNAPP is: an integrated platform category that correlates posture, workload, identity and code-to-runtime context so teams can prioritize risk. Depth varies widely by vendor, and no CNAPP covers every capability equally well.
Buying takeaway: score candidates against your own environment with a weighted scorecard and a proof of concept that measures discovery accuracy, risk correlation, noise and remediation routing. Smaller estates may reasonably rely on native cloud controls plus focused tools.
What Is Cloud-Native Security? (Quick Answer)
Cloud-native security is the practice of protecting applications built from containers, Kubernetes, serverless functions, APIs and managed cloud services across their full lifecycle. It combines secure code and supply chains, identity and configuration controls, hardened deployment, and runtime detection, so risk is managed from developer commit to production workload rather than at a perimeter.
Table of contents
What Is Cloud-Native Security?
Cloud-native security is the discipline of protecting applications built from containers, microservices, serverless functions, APIs and managed cloud services across the whole lifecycle, from source code to running workload. It covers the code and dependencies teams write, the pipelines that build and ship them, the cloud accounts and identities that host them, and the runtime behavior of the workloads themselves.
The scope is wider than container or Kubernetes security. Kubernetes is one runtime layer. A cloud-native estate also includes cloud control planes, IAM (identity and access management), virtual machines, managed databases, object storage, API gateways, secrets, infrastructure as code (IaC), Git repositories, CI/CD (continuous integration and continuous delivery) systems, registries, open-source dependencies and observability tooling. A weakness in any of them can become the path to the others.
The Cloud Native Computing Foundation (CNCF) models the lifecycle as four phases: develop, distribute, deploy and runtime. The CNCF Cloud Native Security Whitepaper, version 2 (May 2022) contrasts this with traditional approaches by noting that security can be built into each phase rather than bolted on at the start and end.
Cloud-native security vs. cloud security
Cloud security is the broader field: protecting anything that runs on or connects to cloud platforms, including lifted-and-shifted virtual machines, SaaS configuration and data. Cloud-native security is the part concerned with applications designed for the cloud operating model, where workloads are short-lived, infrastructure is declared in code and delivery is automated. The two overlap heavily, and most programs treat cloud-native security as the application and workload layer of a wider cloud security strategy.
Shared responsibility still applies
Providers secure the underlying platform, and customers secure what they build and configure on it, but the line moves by provider and service. AWS says customer responsibility is determined by the services selected. Microsoft states that customers always keep responsibility for data and identities, whatever the service type. Google Cloud argues that shared responsibility alone falls short and describes a "shared fate" approach. Map responsibilities service by service rather than assuming one model fits every provider.
Why Cloud-Native Security Is Different From Traditional Security
Cloud-native security differs from traditional security because the assets are created, changed and destroyed by code, and because identity and configuration, not network location, decide what an attacker can reach. None of this makes cloud-native architecture inherently less secure. It changes the attack surface, the control model and the operating requirements. For background on the architecture itself, see Articsledge's guides to cloud-native architecture and what cloud-native means.
API-driven infrastructure. Every resource is created through an API, so permission to call that API is as powerful as physical access once was.
Ephemeral workloads and autoscaling. Containers and functions may live for minutes, so a weekly scan describes a system that no longer exists.
Automation and IaC. One flawed template can deploy a misconfiguration to hundreds of environments, and one good guardrail can prevent it everywhere.
Developer self-service. Teams provision their own resources, so ownership is distributed and central review does not scale.
Distributed systems and dynamic networking. Service-to-service traffic and overlapping address ranges weaken the idea of one inspectable perimeter.
Multicloud estates. Each provider has its own identity model, logging and terminology.
Dimension | Traditional approach | Cloud-native approach |
Asset inventory | Periodic scans of stable hosts | Continuous discovery through cloud APIs; assets may exist for minutes |
Perimeter | Network boundary and firewalls | Identity, workload policy and segmentation inside the network |
Change cadence | Scheduled releases and change boards | Frequent deployments with policy enforced automatically in pipelines |
Configuration | Manual server hardening | Declarative IaC, policy as code and drift detection |
Ownership | Central IT and security | Distributed across product and platform teams |
Vulnerability handling | Patch hosts on a cycle | Rebuild and redeploy images; prioritize by exposure and exploitability |
Evidence | Point-in-time assessments | Continuous posture and runtime telemetry |
Manual periodic checks cannot keep pace alone. They still belong in threat modeling and architecture review, but the baseline has to be automated.
What Does Cloud-Native Security Protect?
It protects every layer an attacker could use to reach data or run code in a cloud-native application: development systems, the software supply chain, cloud control planes, identities, workloads, networks, data and the runtime itself. A left-to-right map helps.
Development systems: repositories, developer endpoints and the secrets stored in them.
Software supply chain: open-source and third-party dependencies, build systems, base images, artifacts, registries and signing keys.
Pipelines: CI/CD runners, their credentials and the cloud permissions they hold.
Cloud control plane: accounts, subscriptions and projects, IAM policies, organization-level guardrails and logging configuration.
Compute and orchestration: VMs, Kubernetes clusters, nodes, managed container services and serverless functions.
Identities: human users, service accounts, workload identities, roles, tokens and federated trust.
Network and APIs: ingress, service-to-service traffic, API gateways, DNS and egress.
Data: databases, object storage, queues, backups and the encryption keys behind them.
Runtime and telemetry: process, file and network behavior, plus the logs and audit trails used for detection and response.
The value of the map is in the relationships. A token leaked in a repository can become a CI/CD compromise, then a role assumption in a cloud account, then access to a storage bucket. The MITRE ATT&CK Containers matrix documents adversary techniques against both container and orchestration layers, and the OWASP Kubernetes Top Ten (2025) lists cluster-to-cloud lateral movement as its own risk. Protecting layers in isolation misses these chains.
The Cloud-Native Security Lifecycle: From Code to Runtime
The lifecycle applies controls at each stage from design through runtime and feeds what production teaches back into earlier stages. CNCF groups the stages as develop, distribute, deploy and runtime. This guide splits them slightly more finely.
1. Design and development
Threat modeling comes first: trust boundaries, identity flows, data classification and failure modes. NIST's Secure Software Development Framework (SP 800-218, version 1.1, February 2022) gives a common vocabulary for secure development practices. NIST also published an initial public draft of SSDF version 1.2 (SP 800-218 Rev. 1) on December 17, 2025. A draft is not a final standard, so confirm its status with NIST before citing it.
2. Source and dependencies
Static analysis, dependency analysis and secrets detection run on commits and pull requests. A software bill of materials (SBOM) records what is inside an artifact so that a newly disclosed flaw can be traced to affected builds.
3. Build and CI/CD
Build systems should use least privilege, short-lived credentials, isolated jobs and provenance records. An attacker who controls the pipeline can publish software that every later control treats as trusted.
4. Artifacts and registries
Images should come from controlled registries, be scanned and ideally be signed so that clusters can verify what they run. NIST's Application Container Security Guide (SP 800-190, September 2017) remains a foundational reference on image, registry, orchestrator, container and host risks.
5. Deployment and configuration
IaC scanning and policy as code evaluate changes before they apply. In Kubernetes, admission control decides whether a workload may be created. Preventive guardrails are cheapest to enforce at this stage.
6. Runtime
Workloads run, scale and fail. Runtime controls include workload hardening, network policy, identity enforcement, behavioral detection and logging. Continuous posture checks catch drift, such as a firewall rule opened by hand during an incident.
7. Detection, response and feedback
Detections need context: which workload, which identity, which data and which code change. Findings should return to owners and into templates, base images and policies so the same defect is not reintroduced.
Why shift left alone is insufficient
Shifting left finds problems when they are cheapest to fix, but it cannot see everything. Dependencies gain new disclosed vulnerabilities after release, cloud resources are changed outside pipelines, stolen credentials look legitimate to a scanner, and zero-day exploitation has no build-time signature. Preventive controls, posture management and runtime detection answer different questions.
The Biggest Cloud-Native Security Risks
The biggest cloud-native risks are misconfiguration, excessive permissions, exposed secrets, insecure pipelines, vulnerable and compromised software, weak workload isolation and segmentation, exposed data and APIs, and too little runtime visibility. The table covers what each risk is, why cloud-native environments amplify it, the likely impact and the primary mitigation.
Risk | Why it is pronounced here | Likely impact | Primary control |
Cloud misconfiguration | Resources are created by API and template, so one setting (public storage, open ingress) deploys instantly and repeatedly | Data exposure, unauthorized access | Policy as code in pipelines plus continuous posture monitoring |
Excessive IAM privileges | Roles and service accounts accumulate wildcard permissions as teams move fast | Privilege escalation, wide blast radius | Least privilege, permission analysis, short-lived credentials |
Exposed secrets | Keys end up in repositories, images, CI variables and environment variables | Account takeover, lateral movement | Secrets managers, secret scanning, rotation |
Insecure CI/CD | Pipelines hold deployment credentials and run third-party code | Malicious artifacts reach production | Isolated runners, scoped tokens, protected branches, provenance |
Vulnerable images and dependencies | Images bundle many packages, and new CVEs appear after release | Exploitable workloads | Minimal images, continuous scanning, exposure-based prioritization |
Supply-chain compromise | Third-party packages, base images and build tools are trusted implicitly | Backdoored software at scale | SBOMs, signing and verification, pinned dependencies |
Kubernetes misconfiguration | Permissive RBAC, exposed components and unhardened defaults | Cluster takeover | Benchmarks and hardening guides, RBAC review, private control planes |
Privileged or root workloads | Containers share the host kernel, so privileged mode weakens isolation | Container escape, node compromise | Pod Security Standards enforced by Pod Security Admission |
Weak segmentation | Flat pod and service networks allow free movement | Spread after first compromise | Default-deny network policy, service identity, egress control |
Insecure APIs | APIs are the main interface and are often internet-facing | Data theft, abuse | Strong authentication and authorization, API inventory, validation |
Exposed sensitive data | Data stores, snapshots and backups multiply copies | Breach, compliance failure | Classification, encryption, tight access paths |
Runtime compromise and poor telemetry | Short-lived workloads vanish along with their evidence | Late detection, weak forensics | Central audit and runtime logging, behavioral detection, response runbooks |
Drift and multicloud complexity | Manual changes and differing provider models diverge from intended state | Hidden gaps, inconsistent policy | Drift detection, shared control framework, central inventory |
The OWASP Kubernetes Top Ten (2025) reinforces the pattern. Its ten risks include insecure workload configurations, overly permissive authorization, secrets management failures, missing cluster-level policy enforcement, missing network segmentation, overly exposed components, cluster-to-cloud lateral movement, broken authentication and inadequate logging and monitoring. Few of them are exotic exploits. Most are configuration and governance failures that automation can prevent or detect.
Cloud-Native Security Best Practices
The most effective practices start with ownership and identity, enforce policy before deployment, harden the platform, and add runtime detection and risk-based prioritization. Roughly in priority order:
Inventory everything and assign owners. You cannot protect or route what you cannot see. Map every account, cluster, repository and service to a team.
Threat model critical services. Identify trust boundaries and abuse paths before choosing controls.
Make identity the control plane. Apply least privilege, prefer workload identity and short-lived credentials over static keys, and review entitlements. Kubernetes' RBAC good practices are a practical reference.
Manage secrets centrally. Keep them out of code, images and plain environment variables, scan for leaks and rotate. See Kubernetes' secrets good practices.
Scan IaC and enforce policy as code. Use the same rules in pipelines and at admission so developers see problems early and the cluster enforces them regardless.
Harden CI/CD. Use scoped tokens, ephemeral runners, protected branches and review of pipeline changes.
Secure the supply chain. Pin and verify dependencies, generate SBOMs, sign artifacts and verify signatures at deploy time, following NIST SSDF practices.
Minimize images. Use minimal base images, run as non-root and rebuild routinely. See our guide to containerization.
Harden Kubernetes. Work through the Kubernetes Security Checklist, the NSA and CISA Kubernetes Hardening Guide (version 1.2, August 2022) and the CIS Kubernetes Benchmark, which is tied to specific Kubernetes releases. Our Kubernetes guide covers the basics.
Enforce Pod Security Standards. The Pod Security Standards define Privileged, Baseline and Restricted profiles, and Pod Security Admission enforces them. PodSecurityPolicy was removed in Kubernetes 1.25 and is not a modern default. Start in audit or warn mode, then enforce.
Segment networks. Apply default-deny network policies, noting that enforcement depends on the network plugin.
Protect data. Classify it, encrypt it at rest and in transit, and restrict access paths.
Prioritize vulnerabilities by risk. Severity scores alone are not enough, and a detected CVE does not prove exploitability. Weigh exposure, reachability, known exploitation and the privileges the workload holds.
Add runtime detection and telemetry. Collect audit, flow and runtime signals, tune detections and rehearse response.
Patch and upgrade on a schedule. Unsupported Kubernetes versions stop receiving fixes.
Measure risk reduction. Track time to fix exposed critical risk, owner coverage and drift, not raw finding counts.
Cloud-Native Security Tools and Where They Fit
Cloud-native security tools fall into categories defined by the job they do and the lifecycle stage they cover, and the categories overlap. Examples below are illustrative, not endorsements, and capabilities change, so verify current documentation before shortlisting.
Category | Primary job | Stage | Example tools | Main blind spot |
CSPM | Find cloud misconfigurations and compliance gaps | Deploy, runtime | AWS Security Hub, Microsoft Defender for Cloud, Google Security Command Center | Little workload or code context |
CNAPP | Correlate posture, workload, identity and code risk | Code to runtime | Wiz, Prisma Cloud, Microsoft Defender for Cloud | Depth varies by capability |
CWPP | Protect workloads: vulnerabilities, runtime | Runtime | Defender for Cloud workload plans, agent-based runtime products | Weak on configuration and identity |
CIEM | Analyze entitlements and excess permissions | Runtime | Usually a CNAPP module or standalone product | Limited workload context |
KSPM / Kubernetes security | Assess cluster configuration against benchmarks | Deploy, runtime | Kubescape, kube-bench | Terminology is not standardized |
Image scanners | Find known vulnerabilities in images and packages | Build, registry | Trivy, Grype | Findings lack exposure context |
IaC scanners | Check templates before apply | Source, build | Checkov, Trivy | Cannot see out-of-band changes |
Policy and admission | Allow or deny changes by rule | Deploy | Pod Security Admission, Kyverno, OPA Gatekeeper | Rules need ownership and tuning |
Runtime detection | Detect suspicious behavior in workloads | Runtime | Falco | Detects, rarely prevents; needs tuning |
SBOM and supply chain | Record and verify software contents and origin | Build, deploy | Syft, Sigstore cosign | Only as good as adoption |
Secrets management | Store, issue and rotate credentials | All | Cloud secret managers, HashiCorp Vault | Does not find leaked secrets |
DSPM | Locate and classify sensitive data | Runtime | CNAPP modules, standalone products | Limited code and workload context |
API security | Discover and protect APIs | Deploy, runtime | API gateways, WAAP products | Misses non-API paths |
SIEM / SOAR | Aggregate logs, investigate, automate response | Runtime | See our SIEM guide | Needs good inputs |
Two examples show how fast the landscape moves. Wiz joined Google Cloud on March 11, 2026 after Google completed its acquisition, and Microsoft's documentation now describes Defender for Cloud as a CNAPP. Falco, a runtime detection project, graduated within CNCF in February 2024.
What Is a CNAPP?
A Cloud-Native Application Protection Platform (CNAPP) is an integrated security platform that combines capabilities such as posture management, workload protection, identity analysis and code scanning to assess and prioritize risk across cloud-native applications, from development to production. Gartner's public descriptions of the category, including its March 2023 and July 2024 market guides, frame it as consolidating previously siloed capabilities into one platform focused on identifying and prioritizing excessive risk in the application and its infrastructure. Gartner's full reports are paywalled, so this article relies on excerpts that vendors host publicly and treats the category as evolving.
The category emerged because teams accumulated separate tools for cloud posture, workload protection, image scanning, IaC scanning and entitlements, each with its own findings and no shared model of which issues combine into real exposure. A CNAPP tries to put those findings on one map. A vulnerable workload that is internet-exposed, holds an over-permissive role and touches sensitive data should rank above one that is none of those.
Three ideas define the approach: code-to-cloud context, which traces a runtime issue back to its repository and owner; correlated risk, which presents attack paths instead of isolated alerts; and proactive plus reactive controls, which pair preventive checks with runtime detection.
A genuine platform differs from a bundle sold under one contract. A platform shares an inventory, data model and policy engine. A bundle may still need separate consoles, agents and rules. Not every CNAPP includes every capability, and one cloud-security feature does not make a product a complete CNAPP.
What Capabilities Should a CNAPP Include?
A CNAPP should cover discovery, posture, workload and vulnerability protection, identity, code and pipeline integration, correlation and remediation workflow, with depth that matches your environment. Vendor depth varies substantially, so the right question for each row is how well, not whether.
Capability | What good looks like | Depth question |
Discovery and inventory | Continuous discovery of accounts, clusters, workloads, data stores and identities | How quickly are new resources found, and what is missed? |
CSPM | Misconfiguration detection against benchmarks and custom policy | How flexible is custom policy and drift handling? |
Vulnerability and workload protection | Findings for hosts, images and packages with exposure context | Are packages loaded at runtime covered? |
Runtime detection | Behavioral detection with response options | Which signals, which sensor, how much tuning? |
Kubernetes and containers | Cluster configuration, admission integration, workload visibility | Are managed and self-managed clusters equal? |
IaC, repositories, CI/CD | Scanning in pull requests and pipelines tied to deployed resources | Can code be mapped to running assets? |
Supply chain and secrets | SBOMs, provenance and leaked-secret detection | Is verification enforced at deploy time? |
Identity and entitlements | Effective permissions, unused access and trust paths | Does it work across accounts and providers? |
Attack paths and exposure | Graph linking exposure, vulnerabilities, identities and data | Is reachability computed or inferred? |
Data context | Sensitive data location linked to risk paths | How deep is classification? |
Compliance | Framework mapping with evidence | Evidence supports audits but does not guarantee compliance |
Remediation and workflow | Owner routing, tickets, ChatOps, guided fixes | Can automation be made safe? |
APIs and reporting | Query, export and integration | Can all data be extracted? |
Multicloud and governance | RBAC, multitenancy, data residency | Is provider coverage equal? |
CNAPP vs. CSPM, CWPP, CIEM, DSPM, ASPM, and Other Cloud Security Tools
CSPM, CWPP and CIEM are specialist categories that a CNAPP typically absorbs, while KSPM, DSPM, ASPM and SIEM/SOAR overlap with it to varying degrees. Industry terminology is not standardized, vendors define categories differently and the boundaries are converging, so treat the table as a working guide.
Category | Purpose | Scope | CNAPP overlap | Relationship |
CNAPP | Correlate and prioritize risk from code to runtime | Cloud, workloads, identities, code | Not applicable | Platform that may consolidate others |
CSPM | Find misconfigurations and compliance gaps | Cloud control plane and services | Core component | Usually consolidated |
CWPP | Protect workloads from vulnerabilities and runtime threats | VMs, containers, serverless | Core component | Usually consolidated |
CIEM | Analyze and reduce excess entitlements | Cloud identities and permissions | Frequent module | Consolidated or complementary |
KSPM | Assess Kubernetes configuration posture | Clusters and workloads | Often included | Term used inconsistently |
DSPM | Discover and secure sensitive data | Data stores | Sometimes a module | Complementary when data is central |
ASPM | Aggregate and prioritize application security findings | Code, build, test results | Overlaps on code-to-cloud | Complementary or converging |
SIEM / SOAR | Collect telemetry, investigate, automate response | Enterprise-wide logs | Not a replacement | Complementary; CNAPP feeds it |
Benefits and Limitations of CNAPP
A CNAPP's main benefit is shared context: one inventory and risk model replaces several disconnected views. Typical gains include:
consolidated visibility across accounts and clouds
risk prioritization that combines exposure, identity and vulnerability
fewer tools and consoles to run
tracing of runtime issues back to code and owners
better remediation routing and faster investigation
consistent governance and compliance reporting
The tradeoffs are real. Platform breadth can mean less depth than a specialist tool in a given area. Onboarding takes permissions, sometimes agents, and integration work. Telemetry adds data volume and cost. Alert quality depends on tuning, developers may resist new gates, and coverage gaps appear for unsupported services. Lock-in and migration cost grow over time. Consolidation does not always save money, and a CNAPP neither replaces security expertise nor guarantees compliance or eliminates cloud risk.
Do You Need a CNAPP?
Not every organization needs a CNAPP. It becomes compelling when tool fragmentation, scale and prioritization problems cost more than the platform and its operating effort. It is more compelling when you have:
a large or multi-account footprint, or more than one cloud
significant Kubernetes or container use
many teams provisioning their own resources
separate posture, image, IaC and identity tools producing duplicate findings
heavy compliance obligations and difficulty prioritizing findings
a wish to trace runtime risk back to code, perhaps on a cloud-native platform shared by many teams
A small, single-cloud estate with a handful of accounts can reasonably rely on native cloud security services, open-source scanners and policy tools, and good IAM hygiene. Revisit the decision when accounts multiply, clusters spread, findings pile up unowned or audits become hard to support.
How to Choose a CNAPP
Choose a CNAPP by testing how well it finds, connects and routes the risks in your own environment, not by counting features. Evaluate these areas:
Coverage: supported clouds and services, Kubernetes distributions, serverless and multi-account scale.
Depth: posture, vulnerability, identity, data and attack-path analysis, and whether exposure and reachability are computed rather than assumed.
Code-to-cloud: IaC, repository and CI/CD integrations, supply-chain context and mapping findings to owners.
Runtime: detection quality, response options and performance overhead.
Workflow: ticketing, ChatOps, SIEM/SOAR, APIs, reporting, custom policy and exceptions with audit history.
Governance and operations: RBAC, multitenancy, data residency and privacy, scale, administration effort, support, roadmap, exportability and lock-in.
Commercial: licensing model, data and telemetry charges and total cost of ownership.
Agentless vs. agent-based visibility
Neither approach is universally better. Agentless methods read cloud APIs and snapshots, so they deploy fast, cover accounts broadly and leave workloads untouched, but they see configuration and stored state rather than live behavior, and data can lag. Agent or sensor methods observe processes, files and network activity in real time and can respond, but they must be deployed, sized and maintained, cannot run everywhere and add operational overhead. Many programs combine them: agentless for breadth and inventory, sensors on high-value workloads.
Questions that expose weaknesses
What creates billable units: workloads, resources, accounts, hosts, developers or data volume?
Which capabilities require agents, and what is unavailable agentlessly?
What permissions does onboarding require, and can they be scoped?
Where is our security data processed and stored, and for how long?
Which telemetry or storage costs sit outside the base price?
Can all findings and data be exported if we leave?
How are suppressions and risk acceptances audited?
Can risks map to repositories, services and owners?
How does remediation work, and how does automation avoid breaking production?
How are unsupported clusters and accounts handled?
What operational effort remains after onboarding?
CNAPP Evaluation Scorecard and Proof-of-Concept Checklist
Use a weighted 100-point scorecard to compare candidates, then validate the leading scores with a proof of concept (PoC) run against real workloads. Adjust the weights to your risk profile, but fix them before demos begin so enthusiasm does not rewrite the criteria.
Criterion | Points | What to test |
Environment coverage and discovery | 15 | Accuracy and speed of discovery across your accounts, clusters and services |
Risk correlation and prioritization | 15 | Attack paths, exposure and reachability that match what you know is real |
Workload and vulnerability protection | 10 | Image, host and package findings with usable context |
Runtime threat detection | 10 | Detection quality, response options and overhead |
Kubernetes and container depth | 10 | Cluster posture, admission integration, managed-cluster parity |
Identity and data context | 10 | Effective permissions, unused access, sensitive-data linkage |
DevSecOps, code and IaC integration | 10 | Pull-request and pipeline feedback tied to deployed assets |
Remediation and workflow integrations | 10 | Owner routing, ticketing, ChatOps, SIEM/SOAR, APIs |
Governance and compliance | 5 | RBAC, audit trails, framework mapping, data residency |
Operational fit and TCO | 5 | Effort to run, licensing units, telemetry costs, exportability |
Total | 100 | Weighted sum of the ten criteria |
Proof-of-concept checklist
Resource discovery: compare what the platform finds with a known inventory.
Misconfiguration: seed a realistic issue, such as public storage, and time its detection.
Artifact to runtime: trace a vulnerability from repository and image to the deployed workload and its owner.
Excessive privileges: confirm it surfaces an over-permissive role or service account.
Attack path: check that several findings combine into a path you recognize as real.
Exposure and reachability: verify it separates exposed, reachable risk from theoretical risk.
Kubernetes: validate cluster visibility, admission integration and managed versus self-managed parity.
Runtime detection: run safe, approved test behaviors for each claimed detection.
Ownership routing: confirm findings reach the right team without manual triage.
Workflow integration: test ticketing, ChatOps and SIEM/SOAR delivery.
Noise: count false positives and duplicates and the time spent tuning.
Investigation time: time an analyst answering what is exposed and who owns it.
API and export: extract all findings and configuration data.
Operational burden: log the hours spent onboarding and maintaining.
Difficult vendor questions
Show a finding our current tools missed, and one your product would miss.
How is reachability determined, and what happens when the data is stale?
What breaks if an agent or API permission is removed?
What do customers typically spend on telemetry beyond the license?
How are false positives suppressed without losing audit history?
How to Implement a CNAPP Without Overwhelming Developers
Roll out a CNAPP in phases: observe first, assign ownership next, then enforce gradually with developer feedback. Do not block every build on every finding on day one. A 30/60/90-day plan works as a starting point.
Days 1 to 30: baseline and ownership
Connect cloud accounts with read-only access and run discovery.
Map accounts, clusters and repositories to owners.
Agree on a short critical list, such as exposed data stores, internet-facing workloads with critical vulnerabilities and over-privileged identities.
Run every policy in audit mode.
Days 31 to 60: prioritize and integrate
Route critical-list findings to owners through existing ticketing or ChatOps.
Set service-level expectations and an exception process with expiry dates.
Add IaC and image scanning to CI/CD as warnings.
Deploy runtime sensors on a small set of high-value workloads.
Days 61 to 90: enforce and measure
Block only high-confidence, high-impact violations, such as privileged pods or public storage, through guardrails.
Extend runtime coverage and tune detections.
Collect developer feedback and retire noisy rules.
Report time to remediate, owner coverage and exposed critical risk.
Cloud-Native Security Maturity Model
This original five-level model helps teams place themselves and choose the next investment. It is a self-assessment aid, not a standard.
Level | Characteristics | Tooling and process | Main limitation | Next step |
1. Ad hoc | Manual reviews, no complete inventory | Console checks, occasional scans | Unknown assets, no owners | Build inventory, assign owners |
2. Baseline visibility | Continuous inventory and posture findings | CSPM, image scanning, basic logging | Findings lack context and owners | Standardize policies and guardrails |
3. Standardized controls | Policy as code, admission control, hardened templates | IaC scanning, Pod Security Admission, secrets management | Tools remain siloed | Correlate code, cloud and runtime findings |
4. Integrated code-to-cloud | Shared inventory, attack paths, owner routing | CNAPP or integrated toolchain, runtime detection | Metrics track activity, not risk | Tie tuning and metrics to risk reduction |
5. Risk-driven optimization | Continuous tuning by exposure and business impact, guarded automation | Platform feedback into templates and policies | Process and culture drift | Keep testing assumptions |
Common Cloud-Native Security and CNAPP Mistakes
Equating cloud-native security with image scanning. Images are one layer of many.
Relying only on shift left. Drift, stolen credentials and new CVEs appear after release.
Treating all CVEs equally. Severity without exposure context buries real risk.
Ignoring identity. Permissions often decide the blast radius.
Ignoring runtime. Preventive controls miss novel and credential-based attacks.
Treating tools as a substitute for architecture. No platform fixes a flawed trust model.
Buying a CNAPP without ownership workflows. Findings nobody owns do not get fixed.
Enabling every policy at once. Noise teaches teams to ignore the tool.
Ignoring developers. Controls that slow delivery without explanation get bypassed.
Assuming agentless means complete visibility. It sees configuration, not live behavior.
Measuring finding volume instead of risk reduction. Counts reward activity, not safety.
Buying from feature checklists. Test outcomes in your environment instead.
What's Next for Cloud-Native Security and CNAPP
The directions below rest on public documentation and analyst framing. Treat vendor roadmaps as claims, not facts.
Directions with current support
Code-to-cloud correlation. Analyst excerpts from Gartner's 2024 guide, summarized by CrowdStrike, describe CNAPPs modeling code, libraries, containers, scripts and configuration to find where effective risk sits.
Platform convergence. Defender for Cloud is documented as a CNAPP, and Google now owns Wiz, so hyperscalers and independents are converging on the category.
Software provenance. NIST's December 2025 SSDF 1.2 draft shows continuing public-sector attention to secure development, though final text may change.
Secure-by-default platforms. Platform engineering teams increasingly embed policy guardrails into paved roads so controls arrive with the platform.
Plausible but less certain
AI-assisted triage and investigation, which should be validated in a PoC rather than accepted from demos.
Guarded automated remediation, which depends on safe rollback and change controls.
Security of AI-generated code and infrastructure templates, which need the same scanning, review and policy checks as human-written work.
FAQ
What is cloud-native security?
Cloud-native security is the practice of protecting applications built from containers, Kubernetes, serverless functions, APIs and managed cloud services across their lifecycle, from code and pipelines to cloud configuration, identities and runtime. It is broader than container or Kubernetes security.
How is cloud-native security different from cloud security?
Cloud security covers anything running on or connected to cloud platforms. Cloud-native security is the application and workload layer, designed around short-lived workloads, infrastructure as code and automated delivery. The two overlap heavily, and most programs treat the second as part of the first.
What does CNAPP stand for?
CNAPP stands for Cloud-Native Application Protection Platform. It is a category of integrated platforms that combine capabilities such as posture management, workload protection, identity analysis and code scanning to assess and prioritize risk from development through runtime.
What does a CNAPP do?
A CNAPP discovers cloud assets, detects misconfigurations, vulnerabilities and excessive permissions, and correlates them into prioritized risk. Many also scan code and infrastructure as code, detect runtime threats and route findings to owners. Capabilities and depth vary by vendor.
Is CNAPP the same as CSPM?
No. CSPM focuses on cloud configuration and compliance posture. A CNAPP includes posture management but adds workload, identity and code-to-runtime context and correlates findings across them. A product with CSPM alone is not a complete CNAPP.
What is the difference between CNAPP and CWPP?
A CWPP protects workloads such as virtual machines, containers and serverless functions from vulnerabilities and runtime threats. A CNAPP generally includes workload protection as one component alongside posture, identity and code. A CWPP alone says little about cloud configuration or entitlements.
Does a CNAPP replace a SIEM?
No. A SIEM collects and correlates telemetry from across the enterprise and supports investigation, often with SOAR automation. A CNAPP produces cloud-specific risk and detection data that typically feeds a SIEM. The two are complementary.
Does a CNAPP replace endpoint security?
Not as a rule. Endpoint tools protect user devices and often servers, while a CNAPP focuses on cloud resources and workloads. Where a CNAPP includes workload sensors it may overlap with server protection, so confirm coverage rather than assuming equivalence.
Do you need a CNAPP to secure Kubernetes?
No. Kubernetes can be secured with built-in controls such as Pod Security Admission, RBAC and network policies, plus benchmarks and focused tools. A CNAPP becomes more useful when clusters are numerous, span clouds or need code-to-runtime context.
Can a single-cloud organization benefit from a CNAPP?
Yes, when scale, account count, clusters or compliance pressure make fragmented tools hard to manage. A small, simple single-cloud estate may do well with native security services and a few focused scanners.
How does agentless CNAPP scanning work?
Agentless scanning reads cloud APIs and typically analyzes snapshots or metadata of workloads without installing software on them. It offers fast, broad coverage of configuration and installed packages but sees little live behavior, and results can lag behind changes.
Are agents still needed?
Often, for runtime visibility and response. Sensors observe processes, files and network activity as they happen and can contain threats. They add deployment and maintenance effort and cannot run everywhere, so many teams combine agentless and agent-based approaches.
What should a CNAPP proof of concept test?
Test discovery accuracy, realistic misconfiguration and privilege findings, tracing from repository to runtime, attack-path quality, Kubernetes visibility, claimed runtime detections, owner routing, noise, investigation time, data export and operational effort, all in your own environment.
What affects CNAPP cost?
Pricing units vary and may include workloads, resources, accounts, hosts, developers or data volume, plus telemetry, storage and add-on modules. Count onboarding, tuning and staff time too. Ask what creates billable units, and do not assume consolidation always lowers cost.
What are the biggest cloud-native security risks?
Misconfiguration, excessive permissions, exposed secrets, insecure CI/CD, vulnerable images and dependencies, supply-chain compromise, Kubernetes misconfiguration, privileged workloads, weak segmentation, insecure APIs, exposed data and poor runtime telemetry. Many are governance failures that automation can prevent or detect.
What are the most important cloud-native security best practices?
Build an inventory with owners, apply least privilege and short-lived credentials, manage secrets centrally, enforce policy as code before deployment, harden Kubernetes with Pod Security Standards, prioritize vulnerabilities by exposure, and add runtime detection and logging. Measure risk reduction, not finding counts.
Key Takeaways
Cloud-native security spans development, supply chain, cloud configuration, identity, workloads and runtime, so scanning at one stage is not enough.
Most major risks are configuration and governance failures that automation can prevent, detect or route.
Shift left, posture management and runtime detection answer different questions and work best together.
A CNAPP can reduce fragmentation and add context, but platform breadth does not guarantee depth in every capability.
Risk context and remediation workflow matter more than raw finding counts.
Agentless and agent-based approaches both have blind spots, and many programs use both.
Small or simple estates may reasonably rely on native controls and focused tools.
Test candidates in your own environment with a weighted scorecard and a proof of concept.
Actionable Next Steps
Inventory accounts, clusters, repositories and services, and assign an owner to each.
Set a baseline: public exposure, privileged identities, exposed secrets and Pod Security levels.
Map current tools to the lifecycle and mark visibility gaps.
Identify the highest-risk workloads and data.
Write the outcomes you need, such as owner routing or attack-path analysis, and decide whether you need a CNAPP at all.
Weight the scorecard and shortlist two or three candidates.
Run a controlled proof of concept on real workloads using the checklist.
Measure noise, remediation time and operating effort.
Roll out in phases, auditing before enforcing.
Review outcomes quarterly and tune toward risk reduction.
Glossary
API: application programming interface, the way software requests services from other software.
ASPM: application security posture management, which aggregates and prioritizes application security findings.
Attack path: a chain of weaknesses an attacker could use to reach a target.
CI/CD: automated build, test and delivery of software.
CIEM: cloud infrastructure entitlement management, which analyzes and reduces excess permissions.
Cloud-native: designed for cloud operating models, using containers, services, APIs and automation.
CNAPP: Cloud-Native Application Protection Platform.
Container: a packaged application and its dependencies, run in isolation on a shared kernel.
CSPM: cloud security posture management, which finds cloud misconfigurations.
CWPP: cloud workload protection platform, which protects workloads from vulnerabilities and threats.
DevSecOps: integrating security into development and operations practices.
DSPM: data security posture management, which locates and secures sensitive data.
eBPF: a Linux kernel technology some tools use to observe system activity.
IaC: infrastructure as code, infrastructure defined in version-controlled files.
IAM: identity and access management.
Kubernetes: an open-source system for orchestrating containers.
KSPM: Kubernetes security posture management, a loosely defined term for cluster posture assessment.
Least privilege: granting only the access a task requires.
Policy as code: security rules written as machine-enforceable code.
Runtime security: detecting and preventing threats in running workloads.
SBOM: software bill of materials, an inventory of software components.
Service account: a non-human identity used by applications.
Shift left: moving security checks earlier in development.
Software supply chain: everything involved in producing and delivering software.
Workload identity: an identity assigned to a workload so it can access resources without static keys.
Zero Trust: a model that verifies every request instead of trusting network location.
Sources & References
Gartner's full market guides are paywalled. Entries marked as excerpts refer to publicly hosted vendor pages quoting or summarizing them. Product examples are illustrative; confirm current capabilities with first-party documentation.
National Institute of Standards and Technology. Application Container Security Guide (SP 800-190). NIST, September 2017.
National Institute of Standards and Technology. Secure Software Development Framework (SSDF) Version 1.1 (SP 800-218). NIST, February 2022.
National Institute of Standards and Technology. SSDF Version 1.2 (SP 800-218 Rev. 1), Initial Public Draft. NIST, December 17, 2025.
CNCF TAG Security. Cloud Native Security Whitepaper, Version 2. Cloud Native Computing Foundation, May 2022.
Kubernetes Authors. Pod Security Standards. Kubernetes documentation, page last modified August 2, 2026.
Kubernetes Authors. Pod Security Admission. Kubernetes documentation.
Kubernetes Authors. Security Checklist. Kubernetes documentation.
Kubernetes Authors. Role Based Access Control Good Practices. Kubernetes documentation.
Kubernetes Authors. Good practices for Kubernetes Secrets. Kubernetes documentation.
Kubernetes Authors. Network Policies. Kubernetes documentation.
National Security Agency and Cybersecurity and Infrastructure Security Agency. Kubernetes Hardening Guidance, Version 1.2. August 2022.
OWASP Foundation. OWASP Kubernetes Top Ten, 2025 edition. OWASP.
MITRE. ATT&CK Containers Matrix. MITRE ATT&CK.
Center for Internet Security. CIS Kubernetes Benchmark. CIS.
Amazon Web Services. Shared Responsibility Model. AWS.
Microsoft. Shared responsibility in the cloud. Microsoft Learn.
Google Cloud. Shared responsibility and shared fate on Google Cloud. Google Cloud Architecture Framework.
Microsoft. Microsoft Defender for Cloud overview. Microsoft Learn.
Gartner. Market Guide for Cloud-Native Application Protection Platforms. MacDonald, Winckless and Koeppen, March 14, 2023 (excerpt page).
Gartner. Market Guide for Cloud-Native Application Protection Platforms. Koeppen, Winckless, MacDonald and ElTahawy, July 22, 2024 (excerpt page).
CrowdStrike. Our 6 Key Takeaways from the 2024 Gartner Market Guide for CNAPP. CrowdStrike blog.
Cleary Gottlieb. Google Completes $32 Billion Acquisition of Wiz. March 11, 2026.
Cloud Native Computing Foundation. Cloud Native Computing Foundation Announces Falco Graduation. CNCF, February 29, 2024.
