What Is Cloud Application Detection and Response (CADR)?

01

Definition

Cloud Application Detection and Response (CADR) is an approach to detecting and investigating attacks on applications that run in the cloud by correlating three layers of evidence that are usually collected by separate tools: the cloud control plane, the running workload, and the application itself. The aim is a single account of an attack, from the API call or request that started it to the process it spawned and the cloud resources it touched, instead of three partial alerts in three consoles.

The emphasis is on runtime. A CADR tool is judged by what it can show about an attack in progress or one that already happened: which workload, which process, which identity, which request, and what it reached. Finding misconfigurations and vulnerable packages before deployment is a different job, done by posture and scanning tools.

02

Where the term comes from

The name was proposed in July 2024 by James Berthoty of Latio Tech, an independent analyst, as an umbrella for detection that spans cloud, container and application layers. His argument was that cloud detection and response, Kubernetes detection and response, and application detection and response each see one layer of an attack, and none of them can put the whole picture together alone.

Since then several runtime security vendors have adopted the label, each emphasising the layers its own product is strongest in. That is worth knowing when comparing products: CADR describes a goal, correlation across layers, rather than a standard with a conformance test. Two products that both call themselves CADR can collect very different evidence.

03

The three layers of evidence

Each layer answers a question the others cannot, which is why correlation is the point of the category.

• Cloud control plane: audit trails such as AWS CloudTrail and the Kubernetes audit log record who called which API, with which identity. They show a credential being used to list buckets or create a pod, but not what ran inside the workload that used it.
• Workload and kernel: a sensor on the node, today usually eBPF based, records process execution, file access, network connections and library loads for each container, with the process lineage behind each event. It shows the shell that was spawned and what it did, but not which HTTP request caused it.
• Application: request-level telemetry from tracing, instrumentation or network observation ties behaviour to the request, route or user that triggered it. It shows the malicious input, but not what the process did after the application handed control to the operating system.

04

What CADR does not do

Correlation is powerful and easy to over-read. Three limits matter when you rely on it.

• Grouping is not attribution: events linked into one timeline because they share a workload or a time window are a hypothesis about one attack, not proof of a single adversary. A good tool shows why events were grouped so an investigator can disagree.
• Coverage is uneven: application-layer context depends on the language, framework and protocol, and kernel-level visibility depends on the node and runtime. Evidence that was never collected does not appear as a gap; it just is not there.
• Detection is not prevention: most CADR deployments observe and alert. Blocking at runtime is possible but carries availability risk, so it is usually introduced per policy, often after a period of recording what a policy would have blocked.

05

Questions to ask when evaluating a CADR tool

Because the label covers different architectures, a short list of concrete questions separates the products better than a feature matrix.

• Which of the three layers does it collect itself, and which does it import from other tools? Ask to see one alert with all three in the same view.
• What runs on the node, with which privileges, and what does it cost in CPU and memory on your workloads? Ask for the measurement method, not just a number.
• Can an investigator see the process tree, arguments and parent of a suspicious execution, and the workload and owner it belongs to, without exporting data?
• How does it use runtime evidence for vulnerabilities: can it show whether a vulnerable package was loaded or executed, and what does it say when nothing was observed?
• How does evidence leave the product: SIEM integrations, OpenTelemetry (OTLP), APIs, and at what retention?

06

How Primod approaches CADR

Primod describes itself as a Cloud Application Detection and Response platform. A per-node eBPF sensor records process activity, library loads, network connections and workload identity, with request context where it is available, and the platform correlates them with cloud posture into two workflows: investigating runtime attacks, and prioritising vulnerabilities by whether they were loaded or executed in production. Alerts and incidents can be exported over OTLP. The platform page describes the architecture and what the evidence does not cover.

07

At a glance: CADR compared with CDR, CWPP, ADR and EDR

The categories overlap, and vendors stretch every label. The table compares them by the question each one is built to answer, which is more stable than any feature list. In practice many teams run several of these, and the useful question is which evidence each one contributes to an investigation.