RASP Is Dying. Runtime Application Security Is Not.

RASP was built for a world in which an application was mostly code a company understood, running in a small number of predictable language runtimes. Put a security agent inside the application, inspect suspicious input as it reached a sensitive function, and block the request before damage occurred. The idea was ambitious and, at its core, correct: perimeter security cannot protect what it cannot see inside running code.

That world is gone.

J.P. Morgan's 2026 Patchmageddon report highlights that 77 percent of commercial code is made up of prebuilt open-source libraries and frameworks. Modern applications are polyglot, containerized, ephemeral, and assembled from code their developers did not write. Attackers can inspect much of that code without entering the network, and AI is reducing the cost of finding exploitable paths through it.

The need for protection during execution has never been greater. But the original RASP delivery model, injected instrumentation, per-language agents, and checks placed directly on the request path, has become a poor fit for the applications it is supposed to protect. RASP is dying as a product category because the architecture no longer scales with the software estate. Runtime application security is replacing it by keeping the original goal and changing how protection reaches the application.

Key Takeaways

• RASP got the control point right: exploits must be detected and stopped while code is executing, not only before deployment or at the network edge.
• The classic RASP market is contracting. Products have been acquired into larger platforms, older agent branches have reached end of support, and the last OpenRASP release was published in January 2022.
• In-app instrumentation creates a deployment and maintenance tax across languages, frameworks, agent versions, application teams, and production performance budgets.
• The problem RASP tried to solve is becoming more urgent because most commercial code is open source or third party and can be analyzed by attackers at scale.
• Modern runtime application security uses infrastructure-level observation, library and function attribution, and policy-based prevention without injecting security code into every application runtime.

RASP Got One Thing Right

Runtime application self-protection challenged a weak assumption in application security: that inspecting code before deployment and filtering traffic at the perimeter were enough. RASP moved the control into the application, where it could connect input to a database query, deserialization call, file operation, or operating system command.

That application context remains valuable. A WAF can see a request, but it cannot prove which library or function executed after the request arrived. An endpoint tool can see a process launch, but it may not know which dependency and call path caused it. RASP recognized that an exploit becomes real inside execution.

The failure was not the destination. It was the vehicle. To gain context, classic RASP made security part of the application's execution path. The application carried the instrumentation, compatibility risk, performance cost, and upgrade burden. That trade may be acceptable for a small, stable Java estate. It becomes much harder to justify across hundreds of services written in Java, Go, Python, Node.js, Rust, .NET, PHP, and native code.

The Market Is Sending a Message

The RASP category did not disappear in one dramatic product announcement. It consolidated quietly.

Datadog acquired Hdiv Security in 2022 and integrated application security capabilities into a broader cloud platform. Fastly completed its acquisition of Signal Sciences in 2020 and folded its technology into a wider web application and API security portfolio. The last published OpenRASP release was January 2022.

Imperva's status is more nuanced than a simple shutdown headline. Its RASP lifecycle notice established end-of-life and end-of-support dates for several older agent branches, while later branches in that notice remained to be determined. The lesson is not that every Imperva RASP deployment vanished. It is that an embedded production agent creates a lifecycle dependency that security and engineering must continuously carry.

Acquisition is not failure, and a capability can improve inside a larger platform. But markets reveal architectural pressure through consolidation. Standalone RASP did not become the default application control. Its features migrated into observability suites, application security platforms, and broader runtime products because customers wanted the outcome without operating another fragile layer inside every service.

Why the Classic RASP Architecture Aged Badly

Every Runtime Becomes a Separate Integration

Traditional RASP depends on supported instrumentation for a particular language, framework, runtime version, and deployment model. Coverage on a vendor website does not mean every feature works identically across Java, .NET, Node.js, Python, Go, PHP, and emerging languages. Each new service can become another compatibility decision.

This fragmentation is especially costly in cloud-native environments. Services are created and replaced quickly. Base images change. language versions move. A security program that requires each application team to install, test, tune, upgrade, and roll back a different in-process agent will always struggle to reach complete coverage.

Security Runs on the Application's Critical Path

Classic RASP inspects input and applies checks as the application handles a request. Published performance figures vary widely by product and workload, which is why a universal overhead claim is not credible. Even a low average can hide tail-latency changes, startup delays, garbage-collection effects, or instability under unusual traffic.

The deeper issue is ownership. When security code shares the application runtime, the application team inherits the consequences of compatibility bugs and performance regressions. Security may own the policy, but engineering owns the outage.

The Agent Becomes Production Software You Must Maintain

A RASP rollout is not finished when the first agent connects. Teams must track supported releases, backports, framework changes, restarts, exceptions, and vendor roadmaps. When the product is acquired or retired, migration means removing runtime hooks and retesting applications, not simply changing a dashboard.

These costs explain why the category is shrinking even though runtime protection remains necessary. RASP asks every application to adapt to security. Modern runtime application security reverses the relationship: security must adapt to the application estate.

Open Source Made the Original RASP Problem Bigger

The 77 percent open-source figure changes the threat model. Most organizations do not control the discovery, disclosure, or patching timeline for most of the code they run. A direct dependency can bring hundreds of transitive dependencies. A package may be vulnerable, malicious, abandoned, or simply capable of a dangerous action when used in an unsafe way.

Predeployment scanning remains essential. It inventories components and finds known vulnerabilities before release. But it can only reason from the evidence available before the application encounters real traffic, credentials, data, feature flags, and production execution paths.

Attackers are no longer bound to that evidence. They can analyze public libraries directly and use AI to trace filters, parsers, deserializers, template engines, and native decoders. A working exploit does not need to wait for a CVE, advisory, signature, or agreement about which project owns the security boundary. If the path is reachable, the CPU will execute it.

This is where the decline of RASP becomes paradoxical. The market is moving away from classic RASP at the exact moment its central insight becomes unavoidable. The winning architecture will be the one that preserves application-level context without forcing every application to carry the security mechanism.

What Replaces RASP

Runtime application security is not a renamed RASP agent. It changes the deployment and evidence model.

Linux eBPF allows a platform to observe relevant execution and system actions from the infrastructure layer. The hard part is not collecting more events. It is reconstructing application meaning: which workload, library, function, and call chain caused a process execution, file access, network connection, or other sensitive action.

That creates a different security question. Classic RASP asks whether suspicious input reached an instrumented sink. Modern runtime application security asks what code ran, what it did, and whether that library should be allowed to perform the action.

• Deployment: Classic RASP: Instrument each supported application runtime. Modern runtime application security: Deploy through the infrastructure without application code injection.
• Evidence: Classic RASP: Input flow and configured in-app checks. Modern runtime application security: Workload, library, function, call chain, and resulting action.
• Coverage model: Classic RASP: Per-language and framework instrumentation. Modern runtime application security: Language-agnostic observation with validated application attribution.
• Prevention: Classic RASP: Block through in-process checks. Modern runtime application security: Enforce policy on dangerous library-attributed actions.
• Operational burden: Classic RASP: Application testing, agent upgrades, tuning, and compatibility. Modern runtime application security: Infrastructure deployment with workload-level policy and coverage validation.

Infrastructure-level collection is not automatically better. A platform still has to prove that it reconstructs enough application context, covers the relevant languages and native paths, and blocks precisely without breaking legitimate behavior. The architecture removes the in-app agent tax; it does not remove the need for a serious proof of value.

Raven Keeps the Goal and Replaces the Delivery Model

Raven vs. RASP starts with a simple distinction. Traditional RASP injects security instrumentation into the application. Raven deploys through the infrastructure, observes execution at the library and function level, and attributes sensitive actions to the call chain behind them.

That application context powers both detection and prevention. Raven can show which library initiated an unexpected process, file operation, or network connection, then apply runtime policy to the action. Protection does not require a CVE-specific signature, which matters when attackers reach an unknown path in open-source code before disclosure catches up.

Raven Runtime Prevention covers abnormal execution associated with remote code execution, command injection, deserialization, template injection, supply chain attacks, and malicious package behavior. The control point is what code attempts to do, not whether a database has already named the exploit.

The deployment model is designed for polyglot production estates. Raven supports major managed and native languages without a separate in-app agent for each runtime. Raven reports less than 0.2 percent CPU use and less than 300 MB of memory with all modules active. Those are vendor figures and should be validated against each organization's workloads, latency objectives, and enforcement policies.

This is the transition the RASP market has been trying to make. The future is not another generation of injected agents with a longer language matrix. It is application-level execution evidence and control delivered without making the application carry the security layer.

RASP is dying because its architecture belongs to an earlier application model. Runtime application security is growing because the need to protect running code did not disappear. Open source, cloud-native delivery, and AI-assisted exploitation made it more urgent.

Buyers should not ask which RASP tool has the longest feature list. They should ask which platform can cover the applications they actually run, attribute behavior to the responsible code, prevent representative exploit paths, and survive production scale without forcing every development team into another instrumentation project.

The category label may fade. The control point will not.

See how Raven delivers application-level detection and prevention without RASP-style code injection.

Book a demo