Notifications
Clear all
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.
NHIMG editorial — based on content published by Aikido: WAF vs. RASP vs. ADR
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
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: When do in-app runtime controls work better than edge filtering?
A: They work better when the risk depends on how input is used inside the application, not just on the shape of the request.
Q: What breaks when teams rely only on WAFs and post-exploit containment?
A: They often miss what happens inside the application, where the actual exploit completes.
Practitioner guidance
- Map each control to an attack phase Document which threats are handled at the edge, in the application, and at the kernel layer.
- Prioritise in-app controls around dangerous sinks Focus runtime inspection on database calls, shell execution, outbound HTTP, and file operations where user input becomes an action.
- Add host-level telemetry for bypass paths Use eBPF-based ADR where native add-ons, direct syscalls, or post-exploitation activity can evade application hooks.
What's in the full article
Aikido's full guide covers the operational detail this post intentionally leaves for the source:
- Side-by-side implementation guidance for WAF, RASP, and ADR deployment choices in real application stacks
- Examples of sink-level blocking and runtime inspection patterns for SQL, shell, and outbound request activity
- Practical tradeoffs for teams deciding when eBPF-based host visibility is worth the additional setup
- Vendor-specific setup notes for Aikido Zen and other runtime controls that are not detailed here
👉 Read Aikido's guide to WAF, RASP, ADR, and eBPF runtime protection →
WAF vs. RASP vs. ADR: are your runtime controls layered enough?
Explore further
02/08/2026 1:05 pm
Layered runtime security is now an identity governance problem, not just an application security choice. Once applications depend on secrets, service accounts, and automated access paths, the question becomes where those identities are validated and constrained. WAF, in-app, and in-kernel controls each cover a different trust boundary, so governance fails if teams assume one layer substitutes for the others. Practitioners should treat runtime security as part of identity control design.
A question worth separating out:
Q: Which frameworks support layered runtime security decisions?
A: Use NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 to map edge, application, and host controls to protect, detect, and respond functions. For identity-heavy applications, pair that with workload and secret governance so runtime policy aligns with access scope and privilege.
👉 Read our full editorial: WAF, RASP and ADR: what runtime security layers change
