Topic starter
02/08/2026 11:57 am
TL;DR: Runtime security fails when WAF, RASP and ADR are treated as interchangeable, according to Aikido. Edge, app and OS visibility only works when each control is matched to the attack phase it can actually observe.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “WAF vs. RASP vs. ADR”.
Key questions
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.
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.
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.
Glossary terms: Web Application Firewall, Runtime Application Self-Protection, eBPF-Based ADR, Sink
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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: Runtime security needs the right layer at the right attack phase
This post was modified 2 days ago by NHI Mgmt Group