Cybersecurity glossary
What is Runtime Application Self-Protection (RASP)?
Learn what RASP is, how runtime instrumentation detects and blocks attacks from inside an application, and how it differs from IAST and DAST.
Definition
Runtime Application Self-Protection (RASP) is a security control that instruments a running application so it can detect, alert on, or block suspicious behavior using runtime context from inside the application process.
Why Runtime Application Self-Protection (RASP) matters
Traditional perimeter controls see requests, responses, and network patterns. They often cannot tell which code path executed, whether a parameter reached a dangerous sink, or whether a payload was actually exploitable in that runtime.
Runtime Application Self-Protection (RASP) matters because it uses application context at the moment of execution. That context can turn noisy attack traffic into actionable signals and, in carefully chosen cases, block exploitation before a patch is deployed.
What RASP observes
Code paths
Instrumentation sees which controllers, functions, libraries, and sensitive sinks are reached.
Runtime data
Inputs can be evaluated with context about parameters, sessions, files, and framework behavior.
Dangerous actions
RASP can watch command execution, SQL construction, deserialization, and file operations.
Policy outcomes
Controls may run in monitor mode, alert, block, or feed telemetry into security operations.
How RASP is adopted
Choose target apps
Prioritize sensitive, internet-facing services with clear owners and production observability.
Instrument the runtime
Deploy an agent, library, framework hook, or platform integration compatible with the stack.
Run in monitor mode
Collect baseline behavior and identify noisy rules before enforcement affects users.
Tune policy
Adjust detections for real application behavior, trusted internal traffic, and business logic.
Enable targeted blocking
Apply blocking only where confidence is high and rollback paths are clear.
Feed remediation
Use runtime evidence to prioritize code fixes, tests, and vulnerability-management tickets.
RASP, IAST, and DAST compared
| Method | Primary use | Perspective |
|---|---|---|
| RASP | Runtime detection or prevention in deployed applications | Inside the application during real execution |
| IAST | Finding vulnerabilities during testing with instrumentation | Inside the application under test traffic |
| DAST | Testing externally visible behavior of a running app | Outside the application like an attacker |
| SAST | Finding code patterns before execution | Source, bytecode, or binaries without runtime traffic |
RASP implementation checklist
- Select applications where runtime blocking would reduce meaningful business risk.
- Benchmark performance and compatibility before production enforcement.
- Start in monitor mode to understand normal behavior and false positives.
- Tune rules with application owners, not only security analysts.
- Route alerts to systems with triage ownership and severity guidance.
- Use blocking selectively for high-confidence exploit patterns and sensitive sinks.
- Document rollback procedures for agent failures, latency spikes, or false-positive blocking.
- Convert confirmed RASP findings into code fixes and regression tests.
The practical takeaway
RASP is runtime defense with application context. It is neither IAST in production nor DAST with blocking; it is an inside-the-app control that can observe and sometimes stop exploitation as code runs.
Use RASP where context and prevention matter, tune it carefully, and keep fixing root causes. Runtime protection buys time; secure software removes the condition that made the protection necessary.
Related security terms
Interactive Application Security Testing (IAST)
Instrumentation used during testing to find vulnerabilities with runtime context.
Dynamic Application Security Testing (DAST)
External testing of a running application without inside-process instrumentation.
Application Security (AppSec)
The broader discipline that includes runtime defenses and secure development.
Attack Surface
The exposed code paths and interfaces RASP may monitor during execution.
Vulnerability Management
The program that decides how runtime findings are triaged and remediated.
Frequently asked questions
What is RASP in simple terms?
RASP is security logic inside or alongside the application that watches real execution and can stop dangerous behavior as it happens.
How is RASP different from IAST?
IAST is mainly a testing technique that instruments applications to find vulnerabilities during QA or test traffic. RASP is a runtime defense that can alert or block attacks in deployed environments.
How is RASP different from DAST?
DAST tests a running app from the outside like an attacker. RASP observes inside the application process, so it has context about code paths, parameters, libraries, and execution flow.
Does RASP replace secure coding or testing?
No. RASP can reduce exploitability and improve visibility, but vulnerable code should still be fixed through normal AppSec and vulnerability-management processes.
What attacks can RASP detect?
Depending on language and product, RASP may detect injection attempts, unsafe deserialization, suspicious file access, command execution, path traversal, or abuse of sensitive APIs.
Can RASP hurt performance?
It can if instrumentation is heavy or poorly tuned, so teams should benchmark latency, error rates, and compatibility before broad production rollout.
Where should RASP be deployed first?
Start with high-value applications that handle sensitive data, are internet-facing, and have mature observability and ownership for tuning alerts.
References
Explore authoritative guidance and frameworks related to runtime application self-protection (rasp).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.