Topic starter
02/08/2026 11:57 am
TL;DR: WAFs inspect requests at the edge, RASP-style in-app controls trace data through code, and in-kernel ADR watches OS activity, according to Aikido. The practical issue is not choosing one layer but matching each control to the attack phase it can actually see, especially for injection, post-exploitation, and runtime abuse.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “WAF vs. RASP vs. ADR”.
Key questions
Q: How should security teams layer WAF, RASP, and ADR for application protection?
A: Use WAF for edge filtering and volumetric abuse, in-app runtime controls for precise sink-level blocking, and eBPF-based ADR when you need host-level visibility or post-exploitation detection.
Q: Why do WAFs and in-app runtime controls catch different attacks?
A: They operate at different visibility points.
Q: What breaks when runtime protection is detection-only?
A: Detection-only controls leave the final decision to humans after the request has already been processed.
Practitioner guidance
- Define control placement by attack phase Map each runtime control to the phase it can actually observe: edge request inspection, in-app sink blocking or host-level syscall monitoring.
- Treat sink-level decisions as application policy Identify database drivers, shell execution points and other sinks, then require in-app controls for the inputs that reach them.
- Reserve kernel monitoring for post-exploitation visibility Use in-kernel ADR where you need to see shell spawning, file reads, network calls and lateral movement after an attacker has already executed code.
Bottom line: WAF, RASP and ADR solve different visibility problems, so runtime security fails when teams treat them as interchangeable.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:05 pm
Runtime security is a visibility problem before it is a blocking problem: the decisive question is which layer can actually observe the abuse at the moment it becomes enforceable. Edge filtering, code-level tracing and kernel-level monitoring are complementary because they answer different questions about the same request path. Practitioners should map controls to observation points, not buy overlapping products that all fail at the same stage.
A question worth separating out:
Q: When should teams add in-kernel ADR instead of relying on RASP?
A: Add in-kernel ADR when your risk includes post-exploitation activity, native-code bypasses or host-level policy enforcement. If the main problem is injection-class abuse inside the app, RASP is usually the better first control. If you need to see what happens after a shell spawns, kernel-level visibility becomes the relevant layer.
👉 Read our full editorial: WAF, RASP and ADR: what runtime security layers change