Kodem’s Approach to ADR: Rethinking Application Detection & Response

From IAST and RASP to Modern ADR: The Evolution of AppSec

Legacy approaches (IAST/RASP): Traditional application security tooling focused on finding vulnerabilities during testing and stopping known attacks in production. Interactive Application Security Testing (IAST) instruments an application in a test environment to detect vulnerabilities while the app runs (usually during QA or automated tests). Runtime Application Self-Protection (RASP) goes a step further – it installs an agent inside the running application to monitor and intercept attacks in real time, without code changes. One pioneer in this space (Contrast Security) famously described their approach as “like AppDynamics for security,” using code instrumentation to give the app self-protective abilities. This instrumentation-based model was innovative and could block certain exploits and confirm some vulnerabilities at runtime, but it came with significant downsides.

Deployment and performance friction: Instrumentation-based IAST/RASP solutions require deploying language-specific agents or hooks into each application’s runtime. This often means modifying the app server startup, adding an agent and restarting services to attach it. In practice, rolling out RASP across dozens of microservices is painful – each service needs the agent installed and kept up-to-date. There’s a non-trivial performance and memory overhead to running these agents in-line with application code. As one internal study noted, this “Datadog for security” approach can be hard to scale across microservices, and every new language or runtime typically requires a whole new agent product (supporting a new language is effectively building a new sensor). In short, traditional RASP adds latency and complexity at runtime, which has made some teams hesitant to deploy it widely.

Coverage gaps: IAST tools can effectively find vulnerabilities in real code execution, but only for scenarios that are exercised in tests. They depend on thorough test coverage – if a critical use-case isn’t hit by a test, IAST won’t flag the vulnerability. In the Next.js CVE-2025-29927 case (a logic flaw in authentication middleware), it’s unlikely any pre-release test simulated an attacker adding a rogue x-middleware-subrequest header. Thus an IAST solution would have missed this bug entirely, as it did for two years in the wild. RASP, on the other hand, aims to prevent exploits at runtime, but traditional RASP focuses on well-known attack patterns (SQL injection, XSS, deserialization, etc.) and may not catch subtle logic flaws or novel attack techniques that don’t match a signature. For example, an older RASP agent would not view a single harmless-looking header as malicious by itself. Indeed, the Next.js auth bypass involved no injection or payload – it was exploiting a design oversight. Such an attack can slip past a RASP that isn’t specifically looking for that condition.

These limitations have led to the rebranding and broadening of RASP into ADR (Application Detection and Response) by incumbents. The idea is to move beyond simple in-app blocking and provide more comprehensive detection, visibility, and response akin to EDR (Endpoint Detection & Response) but for applications. Contrast Security, for instance, now markets its RASP/IAST agent as an ADR platform. However, if the core technology still relies on heavy in-line agents, the fundamental deployment and coverage challenges remain.

Modern ADR approaches (observability and sandboxing): To address the overhead of instrumentation, newer ADR solutions take a different route. Some leverage modern observability techniques (e.g. eBPF in the kernel) to monitor application behavior from “just outside” the process, rather than altering the app’s code. This can capture function calls, syscalls, and other events without injecting an agent, making it “non-intrusive” and lightweight on performance. In principle, this means you can watch what an app is doing internally (which functions it’s calling, what network connections it makes, etc.) without modifying the app or requiring its source code. This is a big improvement in deployment friction – no app restart needed, and one observability mechanism can often cover many languages.

Other “modern” ADR techniques incorporate sandboxing or safe-mode execution for suspicious actions. For example, if the application attempts something potentially malicious (say, a dangerous deserialization or OS command), an ADR system might intercept that operation and execute it in a sandbox first, observing the behavior while preventing any real damage. If it turns out to be malicious, the system can block the real action; if it’s benign, it lets it proceed. This approach can stop exploits by containing them – the application continues running, but the malicious payload never impacts the real system.

These modern methods (used by some new ADR vendors, such as Oligo Security’s platform) focus on real runtime insights. They often answer questions like “Is my application actually using that vulnerable library function at runtime?” or “Has this code path ever been executed?” For instance, when the Next.js CVE-2025-29927 surfaced, Oligo highlighted how their ADR could immediately identify all running Next.js instances, detect which ones had the vulnerable middleware code loaded in memory, and even filter to see if any had executed the middleware-skipping logic. This runtime visibility is a leap over static scanning – it assures you that an app is actually vulnerable and potentially under attack, not just that it has a vulnerable component sitting idle.

However, despite these improvements, modern ADR approaches still have limitations:

• Lack of context or intent: Observing that a vulnerable function was called (or that a certain method executed) doesn’t always tell you if it was executed maliciously or in a valid context. In our Next.js example, an ADR tool could see that the middleware function to skip auth was invoked. But was it invoked by an attacker’s crafted request, or by some legitimate internal mechanism? Without tying the event to the full execution context (e.g. which incoming request, which user, what data), security teams might get alerted on a technical event without clarity on its impact. Some tools try to build behavioral baselines to distinguish anomalies, but a clever exploit that mimics normal operations (like a normal-looking HTTP request with an extra header) might not stand out on pure behavior analysis.
  
  
• Sandbox blind spots: Sandbox-based protection can ironically miss attacks that don’t exhibit obvious malicious behavior in isolation. A logic flaw like CVE-2025-29927 doesn’t spawn a new process, drop a file, or make an abnormal system call – it simply skips an auth check and then proceeds with normal application logic (serving a page or data that should have been protected). If an ADR solution were to “detonate” this sequence in a sandbox, it would see nothing overtly malicious – the app just responds to a request, which in a sandbox looks fine because there’s no real data theft visible without the broader context (the sandbox doesn’t know that user wasn’t supposed to access that data). Similarly, if an exploit requires external communication to fully trigger (e.g., calling out to an attacker’s server), a sandbox that forbids outbound network might prevent the malicious step from executing, thereby failing to detect the exploit attempt. In short, by containing the action, the sandbox might also contain the indicators needed to identify it as an attack.
  
  
• Limited response precision: Observability-based ADRs can certainly alert on suspicious events, and some can take action (for example, killing the application process or blocking a specific syscall via eBPF). But these responses tend to be coarse-grained (stop the whole process) or require careful policy tuning (deciding which function calls to block preemptively). There is a risk of false positives if the system blocks something it thinks is malicious but isn’t – hence many teams run these in detect-only mode initially. Without a very specific understanding of the attack, the response might be to simply alert and rely on humans to triage.
  
  

These gaps set the stage for Kodem’s approach, which was designed to retain the strengths of runtime monitoring while directly addressing the above issues of context, confirmation, and precision.

Kodem’s ADR Approach: Precise Runtime Protection with Low Friction

Kodem takes a unique approach to Application Detection and Response that builds on the lessons of its predecessors. At a high level, Kodem’s solution performs targeted runtime monitoring of known vulnerable functions within applications, in a way that is safe for production use and provides rich context when an issue is detected. Let’s break down Kodem’s key strengths:

• Minimal-friction deployment (no inline agents): Kodem does not require you to instrument your code or install heavyweight agents that sit in the request processing path. There’s no need for application restarts or modifying your build pipeline to include a security library. Instead, Kodem’s technology attaches out-of-band to running applications (for example, via dynamic hooking or similar mechanisms at the OS level). The result is drastically less deployment friction compared to legacy RASP. You can enable protection on a running service without redeploying it. And because Kodem operates asynchronously (out-of-band), it doesn’t add noticeable latency to your application’s request/response cycle. In the Kodem vs. Contrast Security analysis, it’s noted that Contrast’s agent is “in-line” while Kodem is “async,” translating to better performance and user experience. This means Kodem is safe to deploy in production even in high-throughput, latency-sensitive applications – you get the security insights without risking a performance hit to your customers.
  
  
• Broad language and stack coverage: By avoiding language-specific instrumentation, Kodem achieves a wide coverage across languages and environments out of the box. Traditional solutions often had to play catch-up – a new language or framework required the vendor to build a new agent or support (one reason an incumbent’s “new language support = new product”). Kodem’s approach, in contrast, is less language dependent. Whether your service is in Node.js, Java, Python, or running in a container on Kubernetes, Kodem can monitor it without special-case agents. This is a major benefit for modern polyglot microservice architectures. In fact, Kodem’s platform goes beyond just the app process – it provides visibility across code, runtime, containers, and Kubernetes orchestration for a holistic security view. You don’t have to stitch together separate tools for application vs. container security; Kodem sees it all in one place.
  
  
• Runtime vulnerable function monitoring: Unlike generic anomaly detection, Kodem’s monitoring is context-aware and vulnerability-specific. It leverages knowledge from software composition analysis (SCA) and known vulnerability databases to understand which functions or modules in your application are vulnerable or security-critical. Kodem then watches those specific execution points at runtime. If a piece of code with a known flaw gets executed – especially with input that could trigger the flaw – Kodem detects it in real time. This targeted monitoring vastly improves signal-to-noise ratio. The platform isn’t just blindly tracing everything (which would be noisy and slow); it’s watching the right things – the “hot spots” where an exploit would occur. This focus yields a very high true positive rate. When Kodem raises an alert, it’s not because something looked odd statistically – it’s because a known-vulnerable function was actually invoked with potentially malicious context. That’s a strong indicator of a real attack, not a false alarm. (As a datapoint, runtime signals tied to known vulnerabilities can reduce false positives to virtually zero compared to traditional vulnerability management.)
  
  
• Full execution path mapping: One of Kodem’s standout features is that it doesn’t just tell you “function X was executed” – it shows you how and why. When a potential exploit is detected, Kodem captures the full execution trace or path that led to it. This means you can see the sequence of calls, user inputs, and internal decisions from the entry point (say, an HTTP request or API call) all the way to the vulnerable function’s execution. In the context of our Next.js example, Kodem would record something like: a request came to GET /api/private, it carried an x-middleware-subrequest header, it bypassed the authMiddleware and directly invoked the privateRouteHandler function. This rich context is incredibly valuable – it provides exploit confirmation. You can confirm that an attack actually reached the vulnerable code and what it did next. This addresses the big question that keeps AppSec engineers up at night: “Did someone actually exploit this vulnerability in our production, or is it just theoretical?” Kodem gives a definitive answer when it catches an exploit in action, with evidence to back it. No more guessing or combing through logs for clues – the path is mapped for you.
  
  
• Specific, precise protection: Because Kodem homes in on the exact point of exploit, any protective action can be highly specific. Instead of blanket blocking an IP or shutting down a service, Kodem could, for example, block the execution of the vulnerable function at the moment of attack or sanitize the dangerous parameter, without affecting the rest of the application’s functionality. This precise intervention means legitimate traffic keeps flowing normally, and only the malicious behavior is stopped. In many cases, Kodem can operate in a detect-and-alert mode (so you can see the confirmed exploits and take manual action), or in an automated response mode to prevent the attack on the fly. Because the detection is so reliable (high confidence), organizations can choose to automatically block confirmed exploits with low risk of false positives. This is essentially surgical strike capability within the app – something very hard to do with less aware tools.
  
  

To summarize, Kodem’s approach marries the deep insight of being inside the app (like RASP intended) with the ease of deployment and low overhead of modern observability tools. It avoids the pitfalls of earlier solutions by not being inline or language-limited, and it goes beyond newer ADRs by delivering concrete attack confirmation and detailed context, rather than just surface signals. The result is an ADR solution that AppSec engineers can deploy broadly (even in production) without fear, and that actually catches real attacks with minimal noise.

Case Study: Next.js CVE-2025-29927 – How Different Approaches Stack Up

To make this comparison more tangible, let’s apply the various approaches to a single real vulnerability. CVE-2025-29927 was a recently disclosed critical flaw in Next.js (a popular React-based web framework) that allowed attackers to bypass authentication middleware by sending a special HTTP header. Essentially, Next.js had a mechanism (intended for internal use) to skip running certain middleware if a request header x-middleware-subrequest was present. Attackers discovered that by crafting requests with this header, they could trick Next.js into skipping important middleware like authentication, gaining unauthorized access to protected pages or data. This is a classic business logic vulnerability – no SQL injection or memory corruption, just abusing legitimate logic in an unintended way.

Traditional IAST: An IAST tool in the development pipeline likely would not have caught this issue. Why? Because catching it would require a test case that sends a request with the rogue header and then detects that auth was bypassed. Unless the development team specifically anticipated and wrote a test for this scenario (highly unlikely, given the bug lived unnoticed for two years), the IAST instrumentation would never exercise that code path or flag it. IAST excels at finding things like unsafe SQL queries or known vulnerable API calls when tests hit them, but a logic flaw in auth flow is easily missed. So by the time the app went to production, this vulnerability was still present – which is exactly what happened with Next.js across many deployments.

Traditional RASP: Now suppose we had a RASP agent (legacy ADR) running in the Next.js app in production. Would it have stopped the attack? Out of the box, probably not. The attack request doesn’t contain a suspicious payload – no SQL keywords, no script tags, just an extra HTTP header that the app (mistakenly) trusts. A typical RASP focuses on detecting things like code injection, XSS, SSRF, etc., by scanning inputs and function calls. This particular exploit might not trigger any of those detection rules. The RASP sees a request come in; maybe it notices an unusual header, but unless it has a specific check for “middleware skipping attempt” (which it wouldn’t have before the vulnerability was known), it treats it as a normal request. The malicious effect – skipping auth – happens inside the app’s logic, and the RASP agent wouldn’t recognize that as an attack unless it’s clairvoyant. So the attacker’s request sails through, the RASP does nothing, and the protected resource is returned to an unauthenticated user. Only after the CVE became public could a RASP vendor update their agent with a rule like “if header X is present from an external request, block it.” But that’s reactive, and meanwhile attackers had a window of opportunity. This illustrates how RASP can fail for novel, context-specific flaws; it’s not a silver bullet if it’s not tuned to the exact scenario.

Modern ADR (sandbox/observability example): Now consider an approach like Oligo Security’s ADR, which uses runtime observability (eBPF) and focuses on vulnerable library usage. In fact, Oligo’s team responded to CVE-2025-29927 by quickly helping customers identify where they were running vulnerable Next.js versions and whether those apps had executed the middleware bypass code. This is extremely useful for incident response – if you had Oligo, you could immediately answer: Do we have this flaw in our environment, and has anyone tried to hit it? Oligo’s tool would show you which applications loaded the vulnerable middleware function into memory and even if the function was called. If you saw that the function was invoked in a particular service, that’s a strong sign someone may have attempted the exploit there (or at least that the code ran). However, would such a tool prevent the attack or alert in real-time? It depends. Suppose an attacker sends the malicious request. Oligo’s eBPF hooks might detect the moment the middleware function is invoked (since it’s a key library method) and could potentially generate an alert for that event. But without deeper application context, that alert might just say “AuthMiddleware.skip() function was called in Service X.” It would then be up to the security team to correlate that with an abnormal request. Some ADR solutions might have the ability to automatically flag the presence of the unusual header as an IOC (Indicator of Compromise) – for example, Sweet Security’s blog mentioned detecting the x-middleware-subrequest header via deep packet inspection as an IoC. If the ADR solution is sophisticated enough to inspect HTTP requests and know that header is bad, it could alert or block on that pattern. But that again requires prior knowledge (after the CVE was known).

What about the sandbox angle? If a solution attempted to sandbox this behavior, it might see the Next.js code trying to skip auth and respond with the page. In a sandbox, nothing obviously dangerous happens – the app just renders content. The sandbox doesn’t have the concept of “this user should not have seen that content.” So sandboxing wouldn’t raise a red flag here; there’s no malware executing or system call being made. Moreover, if the attack’s impact was to exfiltrate data to an attacker’s browser, a sandbox that is not integrated with the live app wouldn’t catch that – the data would just be returned (to the sandboxed request). In summary, a modern ADR could detect the vulnerable code and even notice it was exercised, but might not decisively stop or fully understand the exploit without additional rule updates. It’s great for visibility (“you are affected and someone hit it”), but less so for prevention by default. This is not a knock on these solutions – they significantly improve over silence – but it shows the need for even more context and precision.

Kodem’s ADR: If Kodem had been protecting a Next.js application, how would this play out? First, Kodem’s SCA-integrated knowledge would flag that the Next.js version in use had a known vulnerability in its middleware logic (once the CVE became known). That means Kodem would begin monitoring the specific function that implements this header-skipping logic. (Even for a zero-day, Kodem’s generic monitoring of authentication functions might catch unusual behavior, but let’s stick to the known vulnerability scenario for now.) When an attacker sends the malicious header to bypass auth, Kodem’s monitor on the vulnerable function triggers: the function executed in a context that it normally shouldn’t. Because Kodem maps the execution path, it knows this call was reached without the usual auth check. Kodem would immediately raise an alert (or take action) at that moment: essentially saying “Critical: Auth bypass function executed for request X – potential exploit of CVE-2025-29927!” This alert comes with the full context: which user/IP sent the request, what URL, what data was accessed, and the call stack that shows the middleware was skipped. For the security team, this is gold – it’s an exploit confirmed in real-time. They don’t have to guess or hunt; they have evidence that someone just bypassed authentication on that app. Kodem could even automatically block the request or the response from being sent, effectively preventing the exploit from succeeding (e.g., it could intervene once it detects the unauthorized access and return an error or empty response instead of the sensitive data).

Why is this different from the other approaches? Kodem is unique in that it focuses exactly on the point of exploitation (the vulnerable function) and understands the intended vs. actual execution flow. It doesn’t need a generic signature or a baseline anomaly; it has a purpose-built watch on the known weak spot. When that weak spot is hit inappropriately, Kodem doesn’t just see it – it knows it’s an attack and can stop it or flag it with high confidence. This is why Kodem achieves a much higher true positive rate – it’s not guessing; it’s catching actual exploits as they happen. In the case of Next.js, Kodem would have caught the very first exploitation attempt, even before the CVE was widely public, because the behavior was inherently suspicious (auth middleware skipped from an external request). That kind of detection could have alerted the Next.js maintainers or the app owners long before a human eventually discovered the bug. (In fact, recall that this flaw sat in code for two years; one analysis noted that behavioral analysis could have identified it prior to it becoming a CVE – precisely the sort of behavioral monitoring Kodem provides.)

Finally, to wrap up the comparison, here’s a summary of how Kodem’s ADR vs. Traditional vs. Modern approaches compare on key dimensions:

(Sources: Contrast Security’s instrumentation-based ADR approach; Oligo Security’s description of ADR capabilities; Sweet Security’s analysis of runtime detection efficacy.)

Conclusion

The landscape of application security is shifting decisively towards in-app detection and response. Legacy tools like IAST and RASP laid the groundwork by bringing security testing and protection into runtime, but they struggled with deployment complexity and blind spots for new attack types. Modern ADR solutions have improved performance and broadened coverage, yet they often still lack the contextual intelligence to distinguish a true exploit from a flurry of runtime activity. Kodem’s approach to ADR represents a powerful leap forward – one that embraces runtime monitoring on production systems without fear of slowing them down, and that focuses on the actual points of exploitation to deliver highly accurate, actionable alerts.

By monitoring the execution of vulnerable functions and mapping out the complete path of an attack, Kodem provides what AppSec engineers have long wished for: real-time insight into attacks as they happen, with the evidence to prove it and the capability to stop them in their tracks. The Next.js CVE-2025-29927 is just one example – a subtle auth bypass that evaded traditional detection for years, yet would be promptly caught (and blocked) by Kodem’s vigilant runtime sensors. And it’s not just about stopping a single bug; Kodem’s holistic coverage across languages and environments, combined with its integration of vulnerability intelligence, means it continuously adapts to protect against the latest threats with minimal tuning.

In summary, Kodem’s ADR solution addresses the limitations of both its predecessors and its contemporaries: it’s as easy to deploy as the newest observability tools, yet as deeply aware of application logic as an instrumentation agent – and it elevates that awareness with exploit-specific intelligence. For AppSec teams and broader engineering organizations, this translates to greater confidence: confidence that you can run security in production without breaking things, confidence that when an alert fires it’s the real deal, and confidence that even sophisticated attacks (the kind that slip past perimeter defenses and scanners) will be caught from within. In an era where application-layer breaches are increasingly common, Kodem’s approach offers a compelling, modern defense: watch the right things, learn from every execution, and respond with precision when it matters most. It’s Application Detection and Response done right – turning the application itself into the last, and strongest, line of defense.