Server side runtime application self-protection (RASP) puts a security agent inside your production application, so a poor choice costs you latency, outages and false blocks rather than just licence fees. NIST SP 800-53 describes RASP (control SI-7(17)) as runtime instrumentation that detects and blocks exploitation using information from the software in execution, unlike perimeter protections that see only network traffic. This buyer's guide covers server side RASP for web applications and APIs running on JVM, .NET, Node.js, Python, PHP and similar runtimes. Mobile app shielding, which protects client apps against tampering and reverse engineering, is a different category: see the Mobile App Shielding and RASP Buyers Guide. For how RASP works and when to choose it over IAST or a WAF, read the Interactive Application Security Testing (IAST) and RASP Guide first. The guide is vendor neutral and does not name or rank products.
Key takeaways
- Buy for a specific job. RASP earns its place on internet-facing applications you cannot patch quickly, legacy code and exposed APIs; it is not a substitute for fixing vulnerabilities.
- Runtime coverage decides everything. Confirm the exact language versions, frameworks, application servers and container or serverless platforms you run, not the vendor's headline list.
- Measure overhead and false positives yourself. Test with your own traffic in monitor mode before any blocking, with a written latency and error budget.
- The agent is privileged code. It runs inside every protected process, often fetches rules and sends telemetry, so its update channel, credentials and data handling need the same scrutiny as any production dependency.
- Plan for operations, not just detection. Events must reach your SIEM with enough context to act, and someone must own tuning and the decision to block.
Define requirements
- Applications in scope: list each candidate application with runtime and version, framework, application server, hosting model (VM, container, Kubernetes, serverless), exposure and data class. RASP is usually justified first for public-facing services, where it mitigates exploitation tracked by MITRE ATT&CK as T1190 Exploit Public-Facing Application.
- Problem to solve: virtual patching for known flaws while fixes are scheduled, protection for unsupported or third-party code, attack visibility at the code level, or evidence for a control requirement such as SI-7(17). See the Virtual Patching and Compensating Controls Guide.
- Attack classes: injection (SQL, command, LDAP, expression language), path traversal, server-side request forgery, insecure deserialisation, XML external entities, and exploitation of known vulnerable libraries. Decide which you need blocked and which only reported.
- Budgets: maximum added p95 latency, CPU and memory per instance, start-up time impact and acceptable false positive rate, agreed with the service owners before evaluation.
- Deployment constraints: whether agents may be loaded at start-up only, whether outbound connections from production to a vendor cloud are allowed, data residency for telemetry, and change management for agent upgrades.
- Integration: SIEM, ticketing, CI/CD, and the application security testing tools that will consume RASP findings. See the Application Security Testing Buyer's Guide.
Capability areas
| Capability | What it means | Why it matters |
|---|---|---|
| Instrumentation model | How the agent hooks the runtime: JVM agents through -javaagent, .NET through the CLR profiling interface, language-specific modules or wrappers for interpreted runtimes | Determines stability, start-up behaviour and what the agent can see |
| Sink-level detection | Inspecting inputs where they reach sensitive functions such as query execution, file access, process creation and outbound requests | Context-aware detection fires only on attacks that reach a sink, which is RASP's main advantage over pattern matching at the edge |
| Modes and granularity | Monitor and block per application, per attack class and per route, with allow-listing | Lets you block high-confidence classes first and roll back narrowly |
| Vulnerable library protection | Rules that stop exploitation of known flaws in specific components | Buys time when a library cannot be upgraded quickly |
| Event quality | Request, route, sink, payload excerpt, stack trace and decision for each event, in a structured format | Developers need the code location; the SOC needs a clear block or alert |
| Management and policy | Central policy, rule updates, agent version control, role-based access and audit of policy changes | Policy changes in a blocking tool are production changes |
| Performance controls | Sampling, fail-open or fail-closed choice, circuit breakers when the agent misbehaves | Protects availability if the agent or its rules fail |
| Platform support | Containers, Kubernetes injection, serverless functions, and air-gapped or on-premises management options | Coverage gaps are the most common reason RASP stays partial |
Evaluation criteria
| Criterion | Weight (example) | How to evidence it |
|---|---|---|
| Coverage of your runtimes and frameworks | 20% | Supported versions matrix checked against your inventory; agent running on each in the PoC |
| Detection accuracy on your applications | 20% | Seeded vulnerable routes blocked; false positives over two weeks of real or replayed traffic |
| Performance overhead | 15% | p50 and p95 latency, CPU, memory and start-up time with and without the agent under the same load |
| Operational safety | 15% | Behaviour when the management plane is unreachable, when a rule update is bad and when the agent crashes |
| Integration and event quality | 10% | Events in your SIEM with route, sink and stack trace; ticket creation for developers |
| Agent and supply chain security | 10% | Signed agents and rules, update channel controls, credential handling, telemetry contents and retention |
| Management and governance | 10% | SSO and role-based access to the console, audit of policy changes, API for automation |
Adjust weights to the problem. A team buying RASP mainly for virtual patching of legacy applications should weight coverage and accuracy higher; a platform team rolling out across hundreds of services should weight operational safety and automation higher.
Where identity fits
Each agent authenticates to a management plane with a token, key or certificate, and the console often holds API tokens for SIEM and ticketing integrations. These are non-human identities with influence over production behaviour: anyone holding a console admin account or an agent enrolment secret can switch protection off or change what is blocked. Ask how enrolment secrets are issued, scoped, rotated and revoked, and keep them in your secrets manager rather than in container images or environment files. See the Secrets Management Guide.
Questions to ask vendors
- Coverage: which exact runtime, framework and application server versions are supported today, and how quickly are new runtime releases supported?
- Loading: is the agent loaded at start-up, or does it rely on dynamic attach? JDK 21 warns on dynamically loaded Java agents and JEP 451 states that a future release will disallow them by default.
- Failure behaviour: what happens to requests if the agent errors, times out or loses contact with the management plane? Can we choose fail-open or fail-closed per application?
- Accuracy: how is detection performed for each attack class, at the sink or on the request, and what evidence can you give for false positive rates on applications like ours?
- Overhead: what overhead do you measure, on which benchmark, and can we reproduce it?
- Data: exactly what telemetry leaves the process: payloads, headers, cookies, personal data? Where is it stored, for how long, and can it be kept on premises?
- Update security: how are agent binaries and rule updates signed and verified, and can we pin versions and stage rule updates?
- Policy governance: who can change blocking policy, is every change audited, and can changes go through our change process via API?
- Agent hardening: what privileges does the agent need, and how do you prevent the instrumentation mechanism from being abused?
- Exit: how do we remove the agent cleanly, and what export of events and policy is available?
Red flags
- "No tuning required" claims: every RASP deployment needs a monitor period and tuning on real traffic.
- Coverage by family name: "supports Java and .NET" with no version and framework matrix.
- No fail-safe design: no clear answer on what happens when the agent or management plane fails.
- Unsigned or unpinnable updates: rules or agents pushed automatically with no staging or version control.
- Opaque telemetry: the vendor cannot list what data leaves your process or where it goes.
- Positioning RASP as a fix: RASP mitigates exploitation; it does not remove the flaw, and a vendor that suggests skipping remediation is selling risk.
- Overhead figures you cannot reproduce: benchmarks on synthetic applications only.
Proof of concept
- Select two to four applications covering your main runtimes, including one high-traffic service and one legacy application.
- Baseline performance without the agent: p50 and p95 latency, throughput, CPU, memory and start-up time under a repeatable load test.
- Deploy in monitor mode through your normal pipeline, loading the agent at start-up, and repeat the load test.
- Seed test cases in a non-production copy: known vulnerable routes for injection, path traversal, SSRF and deserialisation, plus a vulnerable library version. Record which are detected, at which sink, and with what evidence.
- Run on real or replayed traffic for at least two weeks and count false positives per attack class.
- Test failure modes: block the management plane, push a deliberately broken rule in staging, and kill the agent; record request behaviour each time.
- Enable blocking for one high-confidence attack class on one service, confirm SIEM events and developer tickets, and practise rolling back to monitor mode.
- Review telemetry captured during the PoC with your privacy and security teams, and confirm agent and console credentials are handled as agreed.
- Score against the evaluation criteria and write down the overhead and false positive figures you will hold the vendor to in the contract.
Metrics to track after purchase: percentage of internet-facing applications protected, percentage in blocking mode, false positive rate per month, added p95 latency, time from new critical library vulnerability to a protective rule in place, and RASP findings converted into code fixes.
How NHI Mgmt Group can help
We provide independent application security and non-human identity advisory and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Interactive Application Security Testing (IAST) and RASP Guide · Web Application Firewall Guide · Application Security Guide · Mobile App Shielding and RASP Buyers Guide