Runtime Application Self-Protection (RASP) is a security technology built into or attached to an application that monitors its own behavior during execution and detects — and can actively block — attacks in real time, from inside the running process. Rather than sitting at the network edge and inspecting traffic like a firewall, RASP lives within the application itself, where it has full context about the code being run, the data being processed, and whether a given request is about to do something dangerous.
That inside-the-application vantage point is what sets RASP apart. A traditional perimeter defense sees a raw HTTP request and must guess whether it is malicious. RASP sees the same request as the application interprets it — it knows whether that input is about to become a SQL query, a file path, or a shell command — and can stop the operation at the exact moment it turns harmful.
Why RASP matters
Perimeter defenses have a structural weakness: they operate on pattern matching against traffic they do not fully understand, which produces both false positives (blocking legitimate users) and false negatives (missing cleverly encoded attacks). Because RASP evaluates a request in the context of what the application actually does with it, it can make far more accurate decisions.
RASP also confronts an uncomfortable reality: not every vulnerability gets patched in time. Even a well-tested application ships with unknown flaws, and known flaws in dependencies can take days or weeks to fix. RASP provides a compensating control — a layer that can neutralize an exploit attempt against a flaw that has not been patched yet, buying teams time to remediate properly.
For regulated environments, RASP can serve as evidence of runtime protection and can generate detailed attack telemetry — who tried what, against which function — that feeds incident response and audit requirements.
How RASP works
RASP instruments the application at runtime, typically through an agent or library woven into the application's execution (similar to how IAST instruments code, but for protection rather than testing). It places hooks around sensitive operations: database access, file I/O, command execution, deserialization, and outbound requests.
When the application runs, RASP inspects each of these operations in context. If it detects that an operation is about to be exploited — say, an input that would break out of a SQL query's intended structure — it can respond in one of several modes:
- Monitoring mode logs and alerts but allows the operation, used during tuning.
- Blocking mode terminates the request or throws an exception before the dangerous operation completes.
- Virtual patching applies a targeted rule that blocks exploitation of a specific known vulnerability until a code fix ships.
Because it judges behavior rather than signatures, RASP can catch novel variants of an attack class that a signature-based tool would miss.
RASP compared with a Web Application Firewall
| Aspect | WAF (perimeter) | RASP (in-app) |
|---|---|---|
| Location | Network edge | Inside the application |
| Context | Sees raw traffic only | Sees code, data, and intent |
| Detection basis | Signatures / patterns | Application behavior |
| False positives | Higher | Lower |
| Encrypted / encoded attacks | Harder to inspect | Seen after decoding |
| Deployment | No code change | Agent or library in the app |
WAFs and RASP are complementary rather than mutually exclusive: a WAF filters obvious noise at the edge and reduces load, while RASP makes precise decisions about the traffic that gets through.
RASP and the software supply chain
RASP's virtual patching is especially relevant to supply chain risk. When a vulnerability is disclosed in a widely used open-source dependency, every organization using it faces a race to upgrade — and upgrades take time to test and deploy. RASP can block exploitation of that flaw at runtime in the interim, shrinking the window of exposure.
But runtime protection is a mitigation, not a cure. The flaw still lives in the code, and the durable fix is to remove or upgrade the vulnerable component. That is why RASP works best alongside software composition analysis, which tells you exactly which dependencies are vulnerable and need upgrading, and dynamic testing, which validates that a fix actually closed the hole. Deciding which flaws to virtually patch first — and which to fix immediately — is a prioritization problem Griffin AI is designed to solve by weighing reachability and exploitability. The broader landscape of these techniques is mapped in the concepts library.
Curious how continuous dependency protection works end to end? Create a free Safeguard account or learn more in the Safeguard Academy.
Frequently Asked Questions
Is RASP the same as a WAF? No. A WAF sits at the network edge and inspects traffic by pattern; RASP runs inside the application and judges behavior in context. RASP generally produces fewer false positives, while a WAF can filter obvious attacks before they reach the app. Many teams run both.
Does RASP replace secure coding and testing? No. RASP is a compensating control that blocks exploitation at runtime, but the vulnerability still exists in the code. It buys time; it does not remove the underlying flaw. Secure development and testing remain essential.
Does RASP affect performance? Yes, modestly. Because RASP inspects sensitive operations at runtime, it adds some overhead. Vendors optimize heavily to keep this low, and most teams find the trade-off acceptable for the protection gained.
What is virtual patching? Virtual patching is a RASP capability that blocks exploitation of a specific known vulnerability without changing the application's code, giving teams a temporary shield while they prepare and deploy a proper fix.