Runtime Cloud Security in 2025
Diving into CADR with use cases
The longer I do cloud security, the more I loathe how Cloud Native Application Protection Platforms (CNAPP) confused the goals of cloud security by trying to be “everything” platforms. Despite having “application” in the name, CNAPPs have done almost nothing to protect the applications running in your cloud environment. Here’s why:
On the posture side, CNAPPs ignore the most application related testing (SAST and DAST). Their weakest point is universally their code analysis, CLIs, IDEs, SCA, container scanning and the rest. These are checkbox features for CNAPPs, and are not really full application security platforms.
On the runtime side, CNAPPs have been EDR that (sort of) works with containers - treating them with little more complexity than malware scanning Linux servers. The Twistlock agent is about as good as it was 10 years ago, and innovation has been glacial in this space. Basic alerts from malware scanning to alerting when processes start are still getting rolled out from most providers.
These early tools treated the layers of cloud compute as separate entities, seeking to apply disjointed detections as they came up. In this article, we’ll discuss why the future of runtime security needs to be envisioned as Cloud Application Detection & Response (CADR) - a tool built from the ground up for stopping runtime threats to cloud applications, rather than treating them as an afterthought. CNAPPs leave security teams with the least visibility where it’s the most important - the application. CNAPPs have made detection and response at best limited, at worst a total waste of time.
I appreciated a reddit comment about my last article on CADR, saying it read like a fever dream, and I get why that might be how it sounds. But let’s use some real world attacks to show how modern attacks span every layer of an environment, and how existing tools are already helping with it.
Fully Detecting the MoveIT Exploit
The MoveIT vulnerability made headlines last year for being easy to access critical infrastructure, providing attackers complete access to environments. Here’s the high level of how the attack worked:
Send a SQL injection payload (application layer)
To access a shell on the remote system (container layer)
To use inherited permissions to access cloud data (cloud layer)
For more details on the exploit, Miggo Security did a fantastic write up here about the complexities of detecting the application layer of the attack. In short, if we used MoveIT, especially in a public facing capacity, we were totally hosed, and were probably getting exploited in real time.
Let’s discuss in frank terms what our odds of detecting this with current tooling might be, and how long they would take and the capabilities you’d have:
Discover via vulnerability scanning (most approaches to cloud security). Security tools could easily detect the version of MoveIT in use via either Software Composition Analysis (SCA) or container scanning depending on how it was deployed, and suggest a patch. Normally, vendors would deploy a check for this within 24 hours, but this is the fire drill patching everyone in security hates doing. My estimate is you’d notice this detection in about a week, and then it would be another two weeks of fire drill patching if you prioritize correctly. You’d never know if you were impacted or not. And if it wasn’t a critical in the news vulnerability, it would probably be months.
Detecting at the Cloud Layer (anomalous access of cloud storage). After the webshell has already been established, an attacker could access cloud files just about any way they wanted depending on the permissions attached to the workload. Depending on sophistication, it would be possible to totally avoid detection - especially because that workload or cloud role would normally be accessing these files. No tool I’m aware of would be watching a pod to notice that a new process was accessing specific files. Even if an anomaly alert did fire, the SOC response would require coordinating with development teams to find out if access was expected. You would probably never get this detection unless there was a large burst of exfiltration traffic, which is a very noisy alert you might have tuned out.
Detecting at the Workload Layer, the webshell (CWPP). This step is where most agent based CNAPPs would have a shot at detection; however, please test these things in your environment. In my testing last year, no EDR alerted on this behavior, and almost all CNAPPs missed it if the shell wasn’t started as a separate process. Let’s pretend however that it detect the presence of a webshell, in most tools, the alert would look like:
Unexpected process started on workload x
This isn’t incredibly helpful, and doesn’t give the SOC much context. They would need to coordinate with DevOps teams to determine if this action was expected, and that investigation would take a lot of time. For determining the blast radius, only a couple of tools provide workload to cloud correlation, to link up “this workload accessed these cloud files.” But this is the first layer where you stand a chance at detection with most tools. Because of lack of context, there’s a high chance this alert gets overlooked or misunderstood.
Detecting at the Application layer - SQL injection payload (ADR or Network layer). Detecting application payloads is a complicated mix of either ADR or WAF depending on the specifics of your infrastructure. WAF bypasses are well established, and third party tools like MoveIT frequently aren’t behind them or have generous exception rules. Application Detection & Response (ADR) by itself tells us the payload has occurred, some ADRs can block it, but by itself, ADR doesn’t tell us what the webshell did or if it was successful. Unlike other tools, ADRs can at least block the exploit in the first place. It’s also the only alert that the SOC doesn’t need to verify with other teams: a SQL injection is a SQL injection, so a proper investigation can be conducted. ADRs that are combined with eBPF have the best chance of detecting, “woah, this payload created a process.”
Breaking out how many detection capabilities are needed to see the entire attack chain shows the complexity security teams face, especially as they are bombarded by marketing noise. Yes, almost any scanner or EDR might detect a MoveIT style exploit, but in this case, only ADR could offer the best hope of a timely response. But ADR by itself misses the post-exploit techniques that are deployed. There’s a reason most serious breaches are not the result of overlooked alerts, but are simply not detected at all. Our capabilities for detecting cloud attacks are painfully outdated.
James, I don’t buy that this is important, are there other examples?
Yes! Here are some attacks that start at the application layer, then move down into the workload and cloud layers:
All of the above follow the same pattern as MoveIT:
Initial Compromise at the Application Layer
Attackers exploit a bug in application code or a core library to execute malicious code or commands.Pivot to the Workload Layer
Once they have code execution, adversaries drop webshells, escalate privileges, or access environment variables, effectively “owning” the container or VM.Spread to the Cloud Layer
Armed with service account credentials, API keys, or privileged roles, attackers interact directly with cloud services—reading data, spinning up crypto miners, or exfiltrating sensitive information.
No siloed solution can properly detect and respond from exploit to post-exploitation techniques. In order to operationalize the SOC for cloud attacks, new solutions are needed that can tie together the complete story - from application exploit cloud exfiltration.
James, You’ve convinced me and I’m filled with FUD, what should I buy!? I need CADR!!
Me too, and it’s a bummer no one is quite perfect yet. However, a lot of people are getting really close! To interpret this graph, CADR is bring together three different layers - cloud, workload, and application. Vendors towards the stop have focused on the application or network layers to detect attacks. Vendors towards the right have built more container security solutions. Vendors on the left have built more cloud centric solutions.
Let’s talk about what’s currently out there, and then let’s talk about potential security tool combinations you could make.
What’s out there
Here are the different approaches and acronyms out on the market:
DIY
I won’t spend too much time on this, but in case you’re crazy here’s how you could DIY a CADR (probably) by combining observability, eBPF, and SIEM.
Observability - OpenTelemtery Collector and baselining application behavior
eBPF - Choose your own open source eBPF agent (falco, tracee, calico, tetragon, kubearmor) adventure
SIEM - piping cloudtrail and cloudwatch into your SIEM of choice
Pray that you can correlate these things together and create enough detections to make it cool.
CDR
For better or for worse, now that agentless CNAPP is dead, there are only two real runtime categories: Cloud Detection & Response (CDR) and Application Detection & Response (ADR). CDRs are the evolution of CWPP + “agentless CDR” - namely the combination of telemetry from containers and cloud resources. Great CDRs will combine this telemetry to create a “workload to cloud” visibility of an attack. In terms of our MoveIT example, they’d spot the shell and cloud pivot - and tell you where that originated.
If the vendor graph wasn’t confusing enough, things are going to get really complicated in this space. Basic CDR detections are widely distributed at this point, but here are a few boxes to think about where people have put emphasis:
Anomaly based detections: Deep detection possibilities but can be noisy
Large container rule libraries: Reliable detections but can miss cloud context
Cloud detections: Tend to spot larger attacks, but don’t give enough context to the workload
Network visibility: Great visibility but noisy to navigate
Some key CDR players are ARMO, Aqua, Rad, Sweet, Sysdig, Spyderbat, Upwind, Uptycs, and Wiz. But as always, the full list is on the site.
ADR
Application Detection & Response (ADR) is very new, but all of the players in the space bring something unique to the table. What I love about ADR is how close it can get to the exploit itself, rather than just post-exploitation techniques. Going back to our MoveIT example, ADRs detect and block the SQL injection that triggers the downstream effects in the first place. Additionally, ADRs get closest to the actual context of the exploit that a SOC needs to respond to an alert.
In the CADR category, ADR is the most important part, because without it, all you know is that, seemingly magically, a process just started. Without the application context, responding to cloud alerts becomes total pandemonium, trying to hunt down developer teams and their actions within a container.
ADR though is much more complicated to wrangle than the other categories because it’s so new. Here are some general approaches from vendors:
Instrumented approaches. These bring testing and protection capabilities very close to your code, at the cost of code changes and usually more performance impact.
Network approaches. These do a great job connecting resources and dataflows, but can lack deep workload library insights.
Advanced eBPF Kung Fu. These provide great function insights into how your app connects to your infrastructure, but tend to lack the overall distributed context of an app.
Little bit of everything. These providers get the telemetry from wherever you have it, and are very flexible.
The core differences in ADR are between two categories: network based, and library based. Network based ADR can spot many OWASP type attacks (SQL Injection, SSRF), but can’t detect anomalous library behavior, function executions, or have deep visibility into the underlying code libraries. Network ADR is more common, while library ADR from an agent only exists from five providers: Oligo, Raven, Miggo, ARMO and Kodem.
Key ADR players are: Contrast, DataDog, Dynatrace, Kodem, Miggo, Oligo, Operant, Raven, Traceable. But as always, the full list is on the site.
CADR - Who to Watch
The following vendors are in my opinion the closest to CADR: ARMO, Sweet, Upwind, Oligo, Operant and Raven. From each of these vendors, I’ve seen working examples of cross plane alerting, and my hands-on time has demonstrated some ability to do that. ARMO, Upwind and Sweet are coming to CADR more from the CDR side, with application support depending on specifics of language and architecture. Raven, Oligo and Operant are more from the ADR side, building up container and cloud context. As soon as one of them can show the complete context of an attack like MoveIT, I’ll make a video and show it off! (Even since writing this article, ARMO has done it with the screenshot above)
Summing it up - Protecting Cloud Apps
Ultimately the move to cloud was about deploying applications using containerized services (yes a giant asterisk for all the other infra that was moved up, Azure exists, giant enterprise, etc. etc.). I’m so excited that we’re finally getting runtime protection for these apps in a way that let’s security teams take immediate actions on their own. While the current number of CADR companies remains very low, in my mind this is the inevitable conclusion of where we go with CNAPP. Just as “making CSPM alerts actionable” has required a lot of additional context, e.g. attack paths, blast radius, exploit data, “making CDR alerts actionable” requires the application context.
The endgame here is simple: make cloud alerts actually workable by the SOC by simplifying the storytelling of a cloud incident.
For ADR, which technical approach do you recommend more? Do you prefer library-based ADR or network-based ADR?
Shouldn’t ITDR be at the top users layer too?