The 10 Best RASP Tools

Most teams reach runtime protection from one of two directions: a scanner produced a backlog nobody can finish and someone asked what protects the code already deployed, or an application cannot be patched in time and a compensating control has to exist by the audit date. Neither is what RASP was sold on, which was an application that defends itself.

Be blunt about the label. "RASP" covers three kinds of product and all three are here. True in-process RASP loads into the application runtime, instrumenting bytecode or the interpreter so a SQL call or a deserialization is judged with knowledge of the code path that reached it. Mobile hardening libraries also compile into the app but face a different adversary: someone holding the device, running a hooking framework against your binary. The rest sit in the request path or watch the process from outside, making them next-generation WAFs and observability platform security modules. A WAF called RASP is still a WAF.

The axis that matters is where the decision gets made: before your code runs, inside the interpreter at a dangerous operation, from a kernel probe, or on a device you do not control. Ten tools follow, across all three kinds, each with an honest caveat.

What actually matters when choosing #

Runtime coverage decides the shortlist before anything else. In-process protection is built per runtime, so a vendor strong in Java and .NET may have a thin Python agent and nothing for the Go service handling payments. Check coverage against your deployment inventory, not the marketing matrix.

Second, and teams underweight this: whether you will ever turn on blocking. An agent left in monitoring mode is an intrusion detection system with extra steps, and most deployments never leave it, because nobody wants to own the incident where the agent killed a legitimate request at peak. Settle who has authority to enable blocking before you buy.

Third, overhead under realistic load. Every vendor quotes a small number; what matters is your latency distribution at peak with your garbage collection profile. Attack class coverage, the obvious criterion, discriminates least, because nearly all of these detect injection. What survives production is runtime support, operational trust and tail latency.

How these were selected #

These are scenario picks, not a ranking. Each entry names a distinct situation where that tool is the strongest answer, so position carries no quality signal. Nobody paid for inclusion and there is no paid placement. Broadly applicable tools come first, specialists later. The right choice depends on your runtimes, not on a score.

Datadog Application Security #

Best for: adding attack detection to services already carrying Datadog APM tracing libraries

The mechanism is reuse. Datadog's tracing libraries already sit in the application process instrumenting request handling and database calls, so security detection becomes another consumer of instrumentation you deployed for performance reasons. Turning it on is usually a configuration flag and a library update, not a new agent and a new owner. Because detections attach to traces, an event arrives with the endpoint, service and code path already on it, so triage feels like normal operational work.

That reuse is also the constraint. Protection depth generally trails specialist in-process agents, particularly on exotic injection and deserialization cases, because the instrumentation was designed for observability first. It only makes sense if Datadog is already your platform. The signal also lands in a tool owned by the observability team rather than security, worth settling early.

Dynatrace #

Best for: runtime vulnerability prioritization across an estate already standardized on OneAgent

Dynatrace's strongest contribution is not blocking, it is answering the question your software composition analysis backlog cannot: which vulnerable library is actually loaded and executing, in which environment, exposed to what. OneAgent already knows process inventory and topology, so a vulnerable component narrows to the instances that genuinely matter. For a team drowning in dependency findings, that reduction is worth more than another detection engine, and injection blocking at execution points sits on top of it.

The caveat is scope. This is an application security module inside a large observability platform, not a standalone RASP product, and it is realistic only where OneAgent is already broadly deployed. Runtime coverage follows the platform's priorities rather than security's. Expect to negotiate agent configuration with a team whose concern is monitoring stability.

Imperva RASP #

Best for: signature-free injection blocking inside Java and .NET applications

Imperva's in-application agent evaluates payloads using language grammars at the point of execution. Rather than asking whether a request looks like an attack, it parses what is about to run and determines whether user-supplied input changed the structure of the statement. A fragment that alters query structure is injection regardless of encoding, which is what lets the agent work without signature tuning, traffic learning or a baselining period. For teams who have watched WAF tuning consume a headcount, having no rule set to maintain changes the operating burden.

The caveat is runtime breadth. Java and .NET are covered well and nothing else is, so a polyglot estate gets partial protection and needs a second control for the rest. It is a commercial in-process agent, which means a change to application startup and a platform team to persuade.

Waratek #

Best for: neutralizing known vulnerabilities in Java applications that cannot be rebuilt

Waratek targets a common problem: an application nobody can safely recompile, because the vendor is gone, the build environment is undocumented, or change control will not approve a release before the deadline. It applies rule-driven fixes inside the JVM, intercepting vulnerable behavior at the bytecode level so a known issue stops being exploitable without a source change or a rebuild. For a legacy estate with a deserialization problem and no upgrade path, that is sometimes the only control achievable this quarter.

The caveat is that virtual patching is a holding action which tends to become permanent. Once a vulnerability is no longer exploitable, pressure to finish the real upgrade evaporates, and you accumulate applications protected only while the agent stays correctly configured. Scope is deliberately Java-only. Treat every virtual patch as debt with an expiry date you actually write down.

OpenRASP #

Best for: proving the in-process protection model on Java or PHP before committing to a contract

OpenRASP hooks sensitive functions in the runtime and evaluates each call in context using plugins written in JavaScript. The plugin model is the interesting part: detection logic is readable, editable and specific to your application, so instead of accepting a vendor's opinion of what a dangerous file path looks like, you encode what is normal for your code. For an engineer who wants to understand what in-process protection does, reading the hook beats any trial license.

The caveat is ownership. This is an open source project with a modest maintenance cadence, and adopting it makes your team responsible for the agent's behavior in production, including plugin quality, upgrade testing and hooks that interact badly with a framework. Coverage stops at Java and PHP. Running it in blocking mode at scale is a genuine commitment.

K2 Cyber Security #

Best for: teams whose previous runtime rollout died from false positives

K2's approach is control flow integrity rather than pattern matching. The agent models the application's legitimate execution paths and treats deviation as the signal. An injected command or hijacked control transfer does not resemble an attack pattern, it produces execution the application was never built to perform, which yields deterministic rather than probabilistic detections. Where an earlier attempt was abandoned because nobody trusted the alerts, a method that does not depend on threshold tuning is a credible second try. The technology now sits within New Relic.

The caveat is organizational rather than technical. Acquired security technology tends to get repositioned as a platform feature, so evaluate the current packaging and roadmap directly. The modelling approach also assumes reasonably stable application behavior, a poor fit for systems that legitimately execute highly dynamic code paths.

Oligo Security #

Best for: determining which vulnerable dependencies are genuinely executing in production

Oligo uses eBPF sensors in the kernel to observe how libraries behave while the application runs, rather than instrumenting the application itself. That buys two things. Real reachability: not whether a vulnerable function is theoretically callable, but whether it executed, which collapses a dependency backlog faster than static analysis. And behavioral deviation: a library that suddenly opens a socket or spawns a process is a strong signal, catching supply chain compromise no signature describes.

The caveat is that observing from outside the process is not blocking inside it. This is closer to application detection and response than to classic RASP, so if your requirement is terminating a malicious request before the query executes, it is the wrong shape of tool. eBPF also carries kernel and privileged-deployment prerequisites that some managed platforms refuse outright.

Signal Sciences #

Best for: blocking persistent attackers in front of applications no in-process agent supports

This is a next-generation WAF, not RASP, and it earns a place here because it solves the problem teams usually buy RASP for. Agents and modules in the request path tag requests with attack signals and evaluate them locally, and the blocking decision is made about a source crossing a threshold of malicious behavior rather than a single request matching a pattern. That is why teams actually leave it in blocking mode: one odd-looking request from a real customer is not dropped, while an attacker probing steadily gets cut off. Enforcement needs no cloud round trip.

The caveat is inherent to the model. Operating on requests and responses, it cannot see what the application does with the input, so an injection assembled internally is invisible to it. Do not let procurement treat it as an in-process control.

ModSecurity #

Best for: self-hosted rule-driven virtual patching at a web server or proxy you already operate

ModSecurity is also a WAF rather than RASP, and it belongs in the conversation because it is the most common answer to "we need a compensating control by Friday." It embeds in a web server or ingress proxy and evaluates traffic against a rule language, with the OWASP Core Rule Set giving broad coverage from first deployment. The rule language is expressive enough to write a targeted virtual patch for one vulnerable parameter, useful when a fix is weeks out and an exploit is public.

The caveat is well documented: the Core Rule Set out of the box generates false positives against real applications, and paranoia level tuning and exclusion writing is ongoing work needing an owner. Teams that deploy and walk away end up in permissive mode: logs, no protection. Engine maintenance has also been uneven, so confirm the state of the implementation for your server.

MobShield #

Best for: hardening a shipped Android or iOS app against tampering and instrumentation frameworks

Mobile hardening is a different adversary model: the attacker owns the device, has your binary, and runs a hooking framework against it. MobShield compiles in as modular detectors covering rooting and jailbreak frameworks, hook and instrumentation tooling, debugger attachment, emulator and automation environments, and code integrity verification. The design choice that matters is per-build native personalization: the native core is transformed so each build differs, and a bypass developed against one release does not transfer cleanly to the next. Published reusable bypasses are the standard failure mode for freely available mobile RASP.

The caveat is that detection is only half the job. The library reports environment signals and your application decides what to do with them, so a weak response policy wastes good detection. It is also a young project with no server-side attestation behind it, and the native core carries a Business Source License rather than a conventional open source one.

How to choose #

If you already run Datadog APM everywhere, start with Datadog Application Security.

If OneAgent is your standard and the pain is a dependency backlog, use Dynatrace.

If you need in-process blocking for Java or .NET, start with Imperva RASP.

If a Java application cannot be rebuilt before the deadline, use Waratek.

If you want to understand the model first, try OpenRASP on a non-critical service.

If a previous rollout collapsed under false positives, look at K2; if you need to know which libraries actually execute, start with Oligo.

If your stack is polyglot and no agent covers it, you want a WAF: Signal Sciences, or self-hosted ModSecurity.

If you ship a mobile app and the threat is device tampering, start with MobShield.

What these tools will not do for you #

RASP adoption stalled for reasons worth naming plainly. Performance anxiety came first: platform teams are asked to accept injected code in a production runtime, and the burden of proof falls on security, which rarely has the load testing evidence. Second, the reluctance to block: a control that never leaves monitoring mode feeds a queue competing with everything else, and is hard to defend at renewal. Third, overlap with the WAF budget, since that line item exists already and the product surviving audits wins.

Be clear about what you are buying. None of these removes a vulnerability. They reduce exploitability while the fix is scheduled, and if it never is they become permanent infrastructure defending code nobody is fixing. None helps with logic flaws or broken authorization, because no agent knows that this authenticated user should not see that record. What makes them work is an owner with authority to enable blocking, a defined response when an agent fires, and a pipeline that keeps virtual patches temporary.

Frequently asked questions #

Do I need RASP if I already have a WAF?

Only if you can name what the WAF cannot see. The gap is context: a WAF inspects the request, an in-process agent sees the resulting database call, file operation or deserialization, including input the application assembled itself. If you cannot articulate that gap from your own incidents, the WAF is doing its job.

Will an in-process agent slow my application down?

It adds overhead, and how much depends on your workload. Published averages are close to meaningless; what matters is tail latency at peak under your own traffic. Load test with the agent in the mode you intend to deploy.

Should we run in blocking mode?

Eventually, or you are running detection you already have elsewhere. The workable path is one low-risk application, one high confidence detection, a documented rollback, and a named owner. Teams planning to evaluate blocking later are usually still in monitoring mode two renewals on.

Does mobile RASP belong in the same category as server-side RASP?

They share a name and little else. Server-side agents defend application logic against remote attackers; mobile libraries defend a binary against the person holding the device. Different threat model, different buyers, different failure modes.