Runtime Application Self-Protection (RASP) is security technology that runs inside an application's own process — instrumenting its function calls, database queries, and memory operations — and blocks attacks in real time based on what the code is actually doing, rather than filtering traffic at the network edge. Gartner analyst Joseph Feiman coined the term in a 2012 research note, and by the mid-2010s vendors including Contrast Security, Imperva, and Signal Sciences had shipped commercial agents built on the idea: attach a Java agent, .NET profiler, or Node.js middleware to a running app, watch the call stack at the moment a SQL statement or OS command executes, and terminate the request if that call chain matches a known attack pattern. RASP got a real-world stress test during Log4Shell (CVE-2021-44228, disclosed December 9, 2021), when several vendors marketed it as a same-day mitigation for JNDI injection while teams scrambled to patch. Below is what RASP actually does, how it differs from a WAF, and where it runs out of road.
How Does RASP Actually Work?
RASP works by embedding a monitoring agent inside the application runtime itself — the JVM, CLR, PHP interpreter, or Node.js process — so it can see the real data and control flow of a request instead of just the raw HTTP packet a network appliance sees. In a typical Java deployment, the agent attaches via the -javaagent flag at startup and uses bytecode instrumentation to hook "sink" APIs: java.sql.Statement.execute, Runtime.exec, File constructors, XML parsers, and deserialization entry points. Commercial agents like Contrast's routinely instrument 100+ such sinks out of the box. When a request comes in, the agent tracks whether attacker-controlled input (a query parameter, header, or JSON body field) flows untransformed into one of those sinks — the same taint-tracking technique used by Interactive Application Security Testing (IAST) tools, which is why RASP and IAST are frequently built by the same vendor and sold as a bundle. If tainted input reaches a sink in a way that matches an attack signature (a ' OR 1=1 pattern landing in a raw SQL string, for example), the agent throws an exception or kills the thread before the query executes. Vendors typically cite single-digit-percentage latency overhead in benchmarks, though real overhead varies by language runtime, instrumentation depth, and request volume, and heavily loaded JVMs have reported overhead into the double digits in independent testing.
How Is RASP Different From a Web Application Firewall (WAF)?
RASP is different from a WAF because it sits inside the process and inspects code-level context, while a WAF sits in front of the application and inspects only the HTTP request and response bytes. A WAF — deployed as a reverse proxy or at the CDN edge (Cloudflare, AWS WAF, F5) — decides to block a request using regex signatures, IP reputation, or ML scoring applied to the raw payload, with no idea whether that payload will ever reach a dangerous function call. RASP has that context: it can tell the difference between a support ticket description that literally contains the string ' OR 1=1 and the same string actually reaching a Statement.execute() call, which is why RASP vendors claim lower false-positive rates on OWASP Top 10 A03 (Injection) class attacks specifically. The two technologies converged commercially rather than staying separate — Fastly acquired Signal Sciences, a "next-gen WAF" with RASP-like runtime insight, for roughly $775 million in October 2020, and most WAF vendors now bundle some runtime-context feature under the RASP label rather than sell it standalone.
What Are the Biggest Limitations of RASP?
The biggest limitation of RASP is language coverage: an agent has to exist for your specific runtime, so teams running Go, Rust, or Elixir services typically have no RASP option at all, while Java, .NET, Node.js, PHP, and Python are comparatively well served. Coverage gaps aside, RASP is a purely reactive control — it doesn't reduce your attack surface or fix the underlying flaw, it only tries to stop exploitation of a vulnerability that is already sitting in production code. That distinction matters in practice: a RASP agent instrumented on the vulnerable endpoint in theory could have blocked exploitation of the Apache Struts flaw (CVE-2017-5638) that Equifax failed to patch for more than two months after its March 2017 disclosure, but only if it had already been deployed, tuned, and covering that exact code path — the breach happened because the underlying vulnerability existed in shipped code, which RASP does nothing to prevent. Other practical limits: every service needs the agent added and redeployed (no retrofitting a fleet overnight), agents add memory and CPU overhead that scales with instrumentation depth, and tuning false positives on business-logic-heavy endpoints often takes weeks of production traffic before a team trusts the agent in blocking (versus monitor-only) mode.
Which Vendors Offer RASP Today?
Contrast Security is the vendor most associated with standalone RASP, having raised $150 million in a June 2021 funding round at roughly a $2.6 billion valuation on the strength of its combined IAST/RASP platform for Java and .NET. Imperva sells RASP as a module of its application security portfolio, positioned alongside its WAF and API security lines. Datadog entered the market by acquiring the French RASP/IAST vendor Sqreen, announced in December 2020 and closed in January 2021, and now ships that capability as Application Security Monitoring inside its broader observability platform. On the open-source side, Baidu released OpenRASP for Java and PHP in 2017 and has kept it maintained as a free alternative to the commercial agents. The common thread across all of them: RASP is sold as an add-on to an existing security or observability platform, not as a category any vendor competes in purely on its own anymore.
Does RASP Replace SAST, DAST, or SCA?
RASP does not replace SAST, DAST, or SCA because it operates entirely after code has already been deployed — it has no ability to find a vulnerability sitting unused in a codebase or a dependency before that code ships. Static analysis (SAST) and dependency scanning (SCA) look at source code and manifests before deployment; dynamic testing (DAST) exercises a running app in staging to find exploitable flaws before release; RASP only watches production traffic against sinks it already knows to instrument. That's also why RASP does nothing about OWASP's A06:2021 category, Vulnerable and Outdated Components — one of the top three risks in OWASP's 2021 Top Ten — since a RASP agent has no visibility into which of your hundreds of open-source dependencies actually carry a known CVE; that's a software composition problem RASP was never designed to solve. Teams that deploy RASP without upstream scanning tend to end up with a production safety net and a growing backlog of unpatched CVEs it's quietly absorbing the blast radius for.
How Safeguard Helps
Safeguard takes the opposite end of the timeline from RASP: instead of adding a runtime agent to block exploitation after a vulnerable dependency ships, Safeguard's reachability analysis determines whether a CVE flagged in your SBOM is actually called by your application's code paths, so teams triage the small fraction of findings that are truly exploitable instead of the entire raw CVE list a scanner returns. Griffin AI, Safeguard's reasoning engine, correlates that reachability signal with exploit maturity and package context to rank what needs attention this week versus what can wait. Safeguard generates and ingests SBOMs across your build pipeline so that new dependencies — and the components hiding inside them — are tracked from the moment they land, not discovered during an incident. And where a fix exists, Safeguard opens an auto-fix pull request with the minimal version bump or patch already validated against your test suite, closing the gap between "found" and "fixed" without waiting on a runtime agent to catch the exploit attempt first.