I've sat through five CNAPP demos in the last six months. Every one of them used the word "detection" to mean "misconfiguration finding." By the third one, I started opening every call with the same question: when a credential gets stolen and used against a correctly configured resource, what does your product do?
Three answers were variations of "we'd surface the over-permissioned role beforehand," one was a roadmap item, and one vendor told me, honestly, that runtime detection wasn't really their architecture.
That gap between "cloud-native security" as vendors sell it and what actually stops cloud-native attacks is structural. The market has spent five years papering over it with rebadged hygiene. CrowdStrike's 2025 Global Threat Report found that 79% of detections were malware-free, meaning attackers are logging in with valid credentials and using legitimate APIs.
That's the pattern CSPM has nothing to say about. And it's still the line item I write the biggest checks for.
In brief:
- Cloud-native security and cloud hygiene are different capabilities. Cloud Security Posture Management (CSPM) tells me a bucket is public. It doesn't tell me someone with valid credentials is staging data through it.
- Cloud-Native Application Protection Platform (CNAPP) bundles posture functions under one label, then adds Cloud Detection and Response (CDR) as a separate acquisition or rollout. The bundle has not collapsed the detection gap.
- Real cloud-native detection requires telemetry CSPM never collects: identity behavioral logs, workload runtime, SaaS and OAuth events. Most CNAPPs see only control-plane snapshots.
- Maturity moves from posture baselines (Stage 1) through deliberate alert routing (Stage 2) to TTP-aware detection engineering and identity-centric monitoring (Stages 3-4). Most programs I audit stall at Stage 1 and call it done.
What cloud-native security actually is (and what cloud hygiene is not)
The textbook definition makes cloud-native security and cloud hygiene look like the same thing. They aren't. Cloud hygiene is CSPM, CIS benchmark checks, patch status, entitlement analysis and baseline configuration audits. These are necessary. I run them. Each finding generates a remediation ticket. The work is real.
Cloud-native security is something else. It's protecting identities, workloads, and control planes against active threats in dynamic cloud environments. It requires behavioral detection of credential abuse, runtime monitoring of workload execution, and cross-domain correlation that connects an identity anomaly in Okta to a privilege escalation in AWS to a data staging event in S3.
Different data sources, different detection logic and different operational workflows than configuration scanning. Anton Chuvakin from Google Cloud's Office of the CISO writes the distinction cleanly in Dark Reading: "Posture management and threat detection won't save you, but not having them would ruin you."
He treats them as separate capabilities in the same sentence. Vendor marketing treats them as the same thing, and I'm the buyer paying for the confusion.
How hygiene gets sold as cloud-native security
Five mechanisms keep showing up in the demos I sit through. Naming them upfront has saved me from buying the wrong thing twice.
- Bundling posture functions under a single "platform" label: CNAPP bundles CSPM, Cloud Infrastructure Entitlement Management (CIEM), and Application Security Posture Management (ASPM) into one product. Forrester VP analysts Andras Cser and Sandy Carielli called the bundling "unnecessary at best and misleading at worst." Each component adds configuration assessment or entitlement analysis. Runtime behavioral detection isn't in the bundle.
- Agentless architecture sold as full visibility: Around Black Hat 2023, CrowdStrike argued publicly that siloed cloud tools (CSPM, Cloud Workload Protection or CWP, and agentless approaches) could not keep up with modern cloud environments. Agentless gives me control-plane snapshots. It doesn't give me in-memory activity, short-lived workloads, lateral movement, or active data exfiltration.
- Acquisition patterns that prove the gap: Wiz acquired Gem Security, which Forrester described as a "cloud detection and response specialist" acquired to "round out" the portfolio. Palo Alto Networks rolled out Cortex Cloud Detection and Response alongside Prisma Cloud. Fortinet acquired Lacework at what Forrester called a "fire sale." If the original platforms were complete, the acquisitions would be hard to explain.
- The word "detection" applied to finding misconfigurations: CloudSecList Issue 323 carries vendor copy stating CNAPPs "detect misconfigurations after deployment." A misconfiguration detection produces a remediation ticket that the cloud team handles, while a behavioral threat detection produces a SOC alert that needs triage within minutes. These are operationally different products marketed with the same word.
- RSAC Innovation Sandbox as community acknowledgment: Two of the ten 2024 RSAC Innovation Sandbox finalists addressed cloud behavioral detection and response specifically: RAD Security (behavioral cloud-native detection) and Mitiga (cloud investigation and response for SOCs). The innovation community is building what the established CNAPP platforms keep separating from posture.
The first vendor that fooled me was a category leader. The demo dashboard had a "Detections" tab populated with red counters. When I asked what was inside, it was all misconfigurations. I almost signed the renewal anyway because the rest of the slide deck was good.
Real cloud-native security starts with telemetry CSPM never collects
For real cloud-native detection to fire, two things have to be in place: telemetry CSPM doesn't ingest, and TTP-aware logic that runs on top of it.
The telemetry CSPM doesn't see
The SANS Detection Engineering Poster states it plainly: "Detection does not start with alerts. It starts with data." For cloud-native threats, the data sources are control plane events, identity behavioral logs, workload runtime telemetry, and SaaS or OAuth logs. CSPM collects posture data only.
The telemetry math is brutal once you look at a single AWS GuardDuty finding. AttackSequence:EKS/CompromisedCluster draws on EKS audit logs, runtime monitoring, CloudTrail data events, CloudTrail management events, VPC Flow Logs, and Route53 Resolver DNS query logs. A CSPM focused on configuration state doesn't see those runtime streams.
The TTPs and detections that fire on real attacks
The tactics, techniques, and procedures (TTPs) that matter confirm the gap. Recorded Future Insikt Group writes in their 2025 cloud ransomware report that "nearly all of the events discussed in this report include the abuse of valid credentials at some point in their attack chain." MITRE ATT&CK on T1550.001 (Application Access Token) describes stolen application access tokens as a way to bypass typical authentication and reach restricted accounts.
Real cloud-native SecOps requires TTP-aware detections for access-key misuse, OAuth abuse, privilege escalation through identity synchronization, and data exfiltration via cloud storage APIs. It requires playbooks that account for ephemeral workloads.
Sysdig reports that 60% of containers live for one minute or less. And it requires bridging identity, cloud, and endpoint so the SOC can build a full evidence chain from initial credential compromise through lateral movement to data staging.
A handful of newer providers are building this from AI-native foundations. Daylight Security is one example I've evaluated. Senior practitioners on follow-the-sun, business context loaded into the investigation, evidence chain published with every verdict.
Whether the right answer is an AI MDR like Daylight, a runtime-first product, or in-house detection engineering depends on the team and the environment.
Why green dashboards don't equal incident response capability
I watched this happen at the last company I led SecOps at. The CNAPP dashboard was green, and the compliance score was 92 in the same quarter, we missed a credential-abuse case for six hours because the on-call analyst was buried in posture alerts that the cloud team should have owned. Most programs I've audited since look the same: posture score high, response muscle untested.
The volume gives attackers cover. Unit 42's 2025 analysis found the average total cloud alerts per organization increased 388% in 2024, and 80% of all alerts come from just 5% of security rules. Cloud attack chains are also fast. Sysdig TRT documented credential extraction to admin compromise in 8 minutes, and Mandiant M-Trends 2026 reports initial-access handoffs to secondary actors in 22 seconds at the fast end of the distribution. A nightly CSPM scan is the wrong instrument for that timescale.
A maturity path that doesn't end at posture
Most programs I audit are still in Stage 1. Maturity beyond posture follows four stages, with clear graduation signals.
- Stage 1: Baselines in place: CSPM, CIS benchmarks, logging enabled on high-value assets, IAM hygiene. Foundational, and aligned with the DoD Cloud Security Playbook. Graduation signal: zero critical misconfigurations on high-value asset systems.
- Stage 2: Deliberate alert routing: Most hygiene alerts shouldn't reach the SOC. CISA M-21-31 guidance outlines log capture and retention requirements. I auto-remediate low-risk misconfigurations or route them to engineering. Only high-value-asset findings requiring judgment go to the SOC queue. Graduation signal: a meaningful reduction in posture alerts hitting the SOC, with no rise in missed real findings.
- Stage 3: Cloud-aware detection engineering: The MITRE ATT&CK Cloud Matrix is the detection backlog. CISA's Red Team Advisory AA23-059A details TTPs worth prioritizing. I start with Discovery, Defense Evasion, and Credential Access. Graduation signal: validated detections firing on at least three Credential Access techniques and two Defense Evasion techniques.
- Stage 4: Identity-centric monitoring: Sysdig's 2025 report shows machine identities outnumber human identities 40,000 to 1, and service accounts are 7.5x more risky than human users. Only 20% of organizations use CIEM weekly. Graduation signal: identity behavioral anomaly detections firing, privileged identities baselined, just-in-time access in place.
I report four numbers to leadership quarterly: posture alerts reaching the SOC (filtered, not ignored); high-fidelity identity and cloud detections validated against MITRE ATT&CK; MTTD (mean time to detect) and MTTR (mean time to respond) for cloud-specific incidents; and percentage of cloud techniques with validated detections.
SANS 2024 data shows 23% of organizations don't measure detection coverage at all. I've made that mistake before, and you can't defend a budget against capabilities you can't measure.
Three questions that separate detection from posture
These are the questions I now ask in the first 20 minutes of every cloud security demo. They separate real detection from rebadged posture faster than any analyst report.
- What telemetry do you analyze at runtime? If the answer is control-plane API snapshots and nothing else, it's hygiene. Real cloud-native detection needs continuous behavioral telemetry from identity logs, workload runtime, and SaaS or OAuth events. I ask the vendor to name the specific log sources and show correlation across at least two on a simulated attack.
- Which TTPs do you detect, mapped to MITRE ATT&CK Cloud Matrix techniques? A vendor should point to specific technique IDs (T1528, T1078.004, T1556.007) and show detections firing on them in a demo environment. If the conversation stays at "we detect misconfigurations" or "we identify risks," the product begins and ends with posture.
- How do you support investigation beyond configuration reports? I ask for the evidence chain from alert to verdict for a credential abuse scenario. Can the vendor show who authenticated, from where, what APIs they called, what data they accessed, and how their behavior deviated from baseline? If the investigation stops at "this resource is misconfigured," it's a compliance tool, not a security operations platform.
The red flags I now end evaluations on: features that begin and end with scanning, scoring, and reporting; agentless architecture sold as full runtime coverage; runtime detection capabilities described as roadmap items rather than shipping features; and any demo that can't show me lateral movement detected against correctly configured resources using compromised credentials.
I keep the three questions simple on purpose, because they force the vendor to show whether they operate on runtime evidence and investigation workflows, or whether they mostly generate better remediation tickets.
What to do on Monday morning
I treat posture data as one input, not the detection system. The detections and playbooks I ship live on the telemetry attackers actually touch: identity, workload runtime, SaaS, OAuth. My detection backlog maps to the MITRE ATT&CK Cloud Matrix, not the compliance crosswalk.
And when a vendor uses the word "detection" in a demo, I now stop the conversation to ask which definition they mean. The bill I pay depends on the answer.
Frequently asked questions about cloud-native security
What's the difference between cloud-native security and cloud hygiene?
Cloud hygiene covers configuration scanning, compliance benchmarking, and entitlement analysis. Cloud-native security adds behavioral detection of active threats: credential abuse, lateral movement, privilege escalation, and data exfiltration across identity, workload, and control plane telemetry.
Both are necessary. Only the second catches attackers using valid credentials against correctly configured resources.
Why doesn't CSPM detect most cloud attacks?
CSPM reads configuration state through cloud provider APIs and identifies misconfigurations. The dominant cloud attack pattern, per CrowdStrike and Recorded Future Insikt Group, involves valid credentials used against correctly configured resources. CSPM lacks the behavioral telemetry to detect credential abuse, OAuth token theft, or runtime privilege escalation.
How do I measure whether my cloud security program is actually improving?
Track four things: percentage of MITRE ATT&CK Cloud Matrix techniques with validated detections, ratio of actionable alerts to total posture alerts routed to the SOC, MTTD and MTTR for cloud-specific incidents, and alignment with CISA M-21-31 logging requirements. If you're only tracking compliance scores, you're measuring hygiene, not security.
What questions should I ask a CNAPP vendor to test for real detection capability?
Ask which specific MITRE ATT&CK Cloud Matrix techniques the product detects and request a live demonstration. Ask whether runtime capabilities are shipping today or on the roadmap.
Ask the vendor to show cross-domain correlation on a credential abuse scenario. If the conversation stays at configuration findings and compliance scores, it's a posture tool.