Aviv Mussinger is CEO & co-founder of Kodem, building application security on runtime truth: what actually runs, not what looks risky.
For a decade, security teams have extended detection and response across every layer of the stack: We got EDR for endpoints, NDR for the network and XDR to stitch those signals together. Each answered the same question in a different place: When something malicious is happening right now, can we see it and stop it?
There is one layer where that question still goes mostly unanswered: the application itself.
This is odd, because the application is where a large share of real breaches actually land. Web application attacks have ranked among the leading breach patterns in Verizon’s Data Breach Investigations Report for years. The application is where the business logic lives, where sensitive data is handled, and where an attacker who gets in has the most to gain. Yet the runtime security we point at production tends to watch the infrastructure around the application (the host, the container, the network) rather than the code executing inside it. The result is a blind spot precisely where the stakes are highest.
Consider two examples, each invisible to a different layer of conventional monitoring.
First, an attack that looks like normal traffic. In 2025, a widely used web framework had an authentication-bypass flaw: A crafted HTTP header let a request skip the middleware meant to enforce access control. To a network monitor, that request is ordinary HTTPS. To an endpoint agent, the process behaves normally. Nothing at the infrastructure layer is obviously wrong. The malicious act is semantic. It lives in what the application logic was tricked into doing.
Second, an attack that looks like normal execution. A well-known flaw in a popular Java framework let an attacker put a crafted expression in a request header that the application then evaluated and ran as code. Here is the subtle part: When that exploit finally spawns a process, the system calls it makes are hard to distinguish from a legitimate feature doing the same thing. A monitor watching syscalls, or a sandbox watching behavior, sees an ordinary process launch. The only way to tell the two apart is to follow the execution path inside the application and see that this one originated in an expression evaluator handling untrusted input, not in the code meant to spawn that process.
Two different attacks, one common thread: The infrastructure around the application looked fine. The evidence that mattered was inside the running code.
Pre-deployment tools do not close this gap either. Static analysis and dependency scanning are essential, but they describe what could be vulnerable before the code ships. They do not watch what happens once it is running, and they cannot catch a zero-day or a logic flaw that no signature describes yet. Detection and response is, by definition, a runtime discipline. It has to live where the code executes.
This is the case for what a growing number of practitioners now call application detection and response, or ADR: detection and response designed for the application layer, with execution context. A few things make it different from bolting an endpoint mindset onto an app.
It works from behavior, not signatures. You cannot enumerate every exploit in advance, so the useful baseline is how the application normally executes: which functions call which, which paths are exercised, what normal looks like for this code. Deviation from that is the signal. This is what lets you catch novel and logic-based attacks rather than only the ones already on a list.
It aims to catch the first malicious action, not the aftermath. The value of watching the application is intercepting an exploit as it begins to execute, before it becomes exfiltration or persistence, rather than reconstructing it later from logs.
It has to be low overhead. Instrumentation-heavy approaches, such as traditional RASP, that inject third-party code into the application process, can deliver depth, but at an operational cost teams struggle to run at scale. Observing execution without becoming a liability inside the critical path is a hard requirement, not a nice-to-have.
And it has to feed the response you already have. Application-layer detections are most useful when they flow into the SIEM and SOAR workflows security teams already run, and when they can inform enforcement points such as a WAF at the perimeter. ADR does not replace those. It is the missing source of truth about what is happening inside the app that makes the rest more precise.
None of this means adding another dashboard of alerts. The point of watching the application layer is accuracy: fewer, better signals about exploitation that is actually happening, grounded in what the code is really doing. A layer that produced more noise would defeat the purpose.
Security has methodically closed its runtime blind spots, from the endpoint to the network to the cloud. The application is the one that has been hardest to instrument and, not coincidentally, the one where breaches are most consequential. Detection and response is finally arriving there. For teams shipping more code, faster, on top of more dependencies and now AI-driven components they did not write themselves, an “R” at the application layer is not a luxury. It is the part of the stack they have been missing.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
