The firewall saw the request arrive. It looked ordinary. It had no way of knowing what the application was about to do with it.
Every enterprise security stack shares that blind spot. Perimeter tools can see traffic going into an application. They cannot see what the application does with it. A web application firewall inspects HTTP requests as they pass by; it has no idea how the application parses, transforms or executes the payload once it arrives.
Runtime Application Self-Protection — RASP — lives in that gap.
Gartner coined the term in 2012 for a simple idea: build the protection into the application or its runtime environment. By instrumenting the running code — intercepting system calls, tracking data flows, observing execution context — RASP detects the moment an input turns into an attack and stops it in real time, without waiting for a human.
Contrast Security, one of the category's pioneers, describes it this way: by using the app to continuously monitor its own behaviour, RASP protects applications from data theft and malicious inputs as they run.
The blind spot that built a category
Traditional runtime defences work from outside. Intrusion prevention systems and web application firewalls sit inline as network traffic inspectors, analysing requests and sessions travelling to and from applications. They cannot observe how that traffic is processed within the application.
And because their protective measures lack the accuracy to confidently terminate sessions, they are typically deployed in alert-and-log mode — consuming considerable security-team bandwidth without actually stopping attacks.
Sit with that arrangement for a second. A tool that sees an attack, suspects an attack, logs an attack — and lets it continue, because it cannot be sure enough to act. The alert lands in a queue. A human reads it later. Meanwhile the request has already been processed.
Now picture a deserialization attack, or a SQL injection variant the WAF's signatures have never seen. From the network's perspective, the request looks like ordinary application traffic. From inside the runtime, the picture is unambiguous: untrusted input flowing into a database query constructor, a deserialized object invoking an unexpected code path.
Same request. Two completely different levels of understanding.
RASP sees the attack at the point where intent becomes execution — the one vantage point where blocking is both safe and precise. Safe, because the context is there to judge by. Precise, because the decision is made about what the input is actually doing, not about what it superficially resembles on the wire.
That inside-out visibility is also what makes RASP valuable against zero-day vulnerabilities. When a critical flaw is disclosed in a widely used library — the industry's shared trauma remains Log4Shell, the 2021 remote-code-execution flaw in Apache Log4j — organisations face a brutal window. The vulnerability is public. Exploits circulate within hours. Patching thousands of applications takes weeks.
Hours versus weeks. That mismatch is the window.
A RASP agent already woven into the runtime can recognise and block the exploitation pattern generically, buying time to patch on a sane schedule. Gartner's original framing positioned RASP exactly there: applications that cannot be patched immediately because of release-cycle constraints.
It complements the other layers too, from automation that shortens detection inside the SOC to authorisation discipline that stops API abuse. No single layer sees everything. RASP's claim is narrower and stronger: for the applications it sits inside, it sees the one thing the others structurally cannot.
Inside the runtime, where an attack can't hide
The mechanics are elegant. RASP products use instrumentation to weave protection directly into applications without requiring application code changes.
An agent attaches to the runtime — typically Java or .NET application servers, where the ecosystem is most mature — and monitors behaviour from within: the logic being executed, the events generated, the instructions running, the bidirectional flow of data in and out.
When the agent sees user input reach a sensitive sink — a SQL query, a command shell, a file-system call — without proper neutralisation, it can act. Block the request. Terminate the session. Or simply log, depending on policy.
Because the decision carries full application context, false positives drop sharply compared with network-layer controls guessing from outside. That last word matters — guessing. A perimeter tool infers intent from the shape of a request. A runtime agent watches intent turn into action, with the data flow in front of it.
If the model sounds familiar, it should. The instrumentation approach borrows from application performance monitoring, which has attached agents to runtimes for years without asking developers to rewrite code. The difference is intent. A monitor asks how the application is behaving. RASP asks whether what it is doing right now is an attack — and unlike a monitor, it is allowed to intervene.
The commercial implementations package this differently. Contrast Security offers Contrast Protect as its RASP product alongside Contrast Assess for interactive testing. The company was named a Visionary in Gartner's Magic Quadrant for Application Security Testing in 2015, 2016, 2017 and 2018, and counts Capital One, Cisco and Société Générale among its adopters. Veracode Runtime Protection deploys an agent to the application host, available as a SaaS subscription, giving insight into application logic, generated events, executed instructions and data flow. Micro Focus Fortify Application Defender emphasises zero code changes, working out of the box to detect and optionally block exploits in Java and .NET applications, offered as SaaS or self-managed. Checkmarx CxRASP observes bidirectional data flow to detect anomalies in real time.
Four vendors, four packagings — but the same underlying bet: the runtime is the one place an attack cannot hide what it actually is. Underneath those choices, the shared mechanics do not change. Instrumentation. An agent in the runtime. Attention to logic, events, instructions and data flow. A decision — block, terminate or log — taken with the application's own context in hand.
A misconception worth killing here: RASP and the WAF are not rivals. They defend different layers and fail in different ways. The WAF sees every request but understands none of them deeply — excellent at blocking known-bad patterns at scale, terrible at judging novel application logic abuse. RASP understands the application deeply but only protects the applications it is installed in.
Mature programmes deploy both. The WAF as a broad, cheap first filter at the edge. RASP as the precise last line inside business-critical applications, particularly internet-facing systems handling sensitive data in regulated industries, where PCI-DSS and HIPAA effectively require evidence of active controls at the application layer.
RASP also covers traffic shapes that defeat perimeter inspection — encrypted payloads the WAF cannot decrypt, WebSocket streams, complex application-specific attack surfaces where generic signatures are useless. The stakes are not theoretical, either; the same applications face espionage programmes built to collect now and exploit later.
Where it doesn't fit, and why that matters
Honest architecture names the limits. RASP has several, and pretending otherwise is how deployments go wrong.
Tight latency budgets come first. Applications with sub-millisecond P99 latency SLOs may not tolerate even the 1–2% overhead a well-tuned agent adds. That overhead is small. Small is not the same as free, and for some systems the budget simply is not there.
Then language coverage. Mature agents exist for Java and .NET. Coverage for Go, Rust and Elixir services is far less mature, and an immature agent can introduce more risk than it mitigates. A security control that destabilises the thing it protects has failed at its first job.
Ephemeral compute is another poor fit. In serverless functions with very short execution durations, agent initialisation overhead can exceed the function's own runtime. The protection costs more time than the work itself takes.
And alert handling. Deploying RASP without a security operations capability to triage its findings creates alert fatigue, which eventually leads to misconfiguration. The agent gets tuned into silence.
That last failure mode is quiet, and common enough to deserve emphasis. A control nobody listens to is not a control. It is decoration with a licence fee.
None of that makes RASP useless. It makes it a compensating control, and it should be documented as one: evidence of active defence at the application layer, not a substitute for fixing the code underneath.
Contrast has long argued that the application layer is where breaches actually happen. In most cases, users and systems interact with enterprise sensitive data through applications, and it is within application code that attackers find and exploit vulnerabilities. The vendor further claims 90% of applications are never checked for vulnerabilities during development and QA — a vendor statistic, worth treating with appropriate scepticism, but directionally consistent with what every breach report shows about unpatched, internet-facing software, including critical flaws being exploited while a patch is still not out.
Buying time is the whole strategy
Consider what the zero-day window actually costs without it.
A critical library flaw drops on a Friday. By Monday, exploit code is public and scanning is industrialised. The patch exists — but the estate runs thousands of services owned by dozens of teams, each with its own release train, its own testing burden, its own change window.
Somebody has to decide which systems stay exposed, and for how long, usually with incomplete information.
A runtime agent that blocks the exploitation pattern generically turns that triage from an emergency into a schedule. The vulnerability still gets patched. It just stops being a countdown.
The strategic case comes down to time. Patching is the correct fix, but patching is slow: testing, change windows, coordination across the teams that own the applications. RASP does not replace patching. It buys the weeks responsible patching requires, by making the running application defend itself in the meantime.
For CISOs, that reframes RASP from a tool purchase into a risk decision: how much is it worth to close the window between disclosure and deployment?
Deployment, done properly, starts with inventory, not vendor slides. Map which production applications run on supported runtimes — predominantly Java and .NET estates — and rank by exposure. Internet-facing systems handling payment data, health records or customer PII go first.
Run the agent in monitor-only mode for two to four weeks to baseline false-positive rates against real traffic before enabling blocking. Flipping straight to block mode on day one is how RASP projects earn a reputation for breaking applications.
Define who owns the alerts. RASP findings are application-contextual, so they route best to the teams that own the code, with a runbook where block events page the application owner while the SOC tracks aggregate exploit-attempt trends as an input to patching prioritisation.
And measure what matters: mean time to virtual-patch coverage after a CVE disclosure, and the percentage of the internet-facing estate under active runtime protection. Not vanity metrics like total blocked requests.
Sources
- Contrast Security — "What Is RASP Security? | Runtime Application Self Protection": contrastsecurity.com
- Contrast Security — "5 Must-Know Facts About Protecting Production Applications" (Executive Brief): contrastsecurity.com
- Contrast Security — "Recognized as the Only Visionary in Gartner 2018 Magic Quadrant for Application Security Testing" (March 20, 2018): contrastsecurity.com
- RASP framework reference (Gartner origin, adopters, use cases): github.com
- Cybersecurity Kings — "What Is RASP In Application Security?" (vendor overview): cybersecuritykings.com
