WAF, RASP and ADR: what runtime security layers change

At a glance

What this is: This is Aikido’s comparison of WAF, RASP, ADR, and eBPF-based runtime security, with the key finding that each layer sees a different part of the attack path.

Why it matters: It matters because IAM and security teams increasingly need runtime controls that complement access governance, especially where secrets, service accounts, and application context intersect.

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.

👉 Read Aikido's guide to WAF, RASP, ADR, and eBPF runtime protection

Context

Application security often fails when teams treat edge filtering, runtime inspection, and host-level visibility as interchangeable. They are not. WAFs, in-app controls, and in-kernel controls each answer a different question, and the right governance model depends on what kind of abuse you are trying to stop in the application stack.

For identity and access programmes, the relevance is straightforward. Runtime protection increasingly sits alongside secrets management, service account governance, and workload identity because attacks often move from request handling into credential use, code execution, and OS-level actions. The stronger the application’s dependency on secrets and automated access, the more important it becomes to understand where each control has visibility and where it does not.

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. The layers are complementary because each sees a different part of the attack path. The right design follows the threat phase, not a single tool category.

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. Injection-class attacks, dangerous database calls, and logic abuse all benefit from code context. If the control must understand sinks, data flow, or library behaviour, in-app inspection is the stronger fit.

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. WAFs operate at the edge, and container kill-switches act after compromise is already underway. That leaves a gap between detection and execution. Teams should assume the attacker will adapt payloads faster than perimeter rules can be updated.

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.

Technical breakdown

WAFs versus runtime controls: what each layer can actually see

A WAF sits in front of the application and inspects HTTP traffic before it reaches code. That makes it useful for high-volume filtering, known malicious patterns, and bot-style abuse, but it has no understanding of what the application does with a request once it passes the edge. In practice, that means a WAF can block a suspicious payload while still missing a benign-looking request that becomes dangerous only after application logic processes it. This is why WAF tuning tends to be probabilistic: it depends on signatures, allowlists, and thresholds rather than code-level context.

Practical implication: use WAFs for edge filtering and volumetric defense, not as your only control for application abuse.

RASP and in-app ADR: why code context reduces false positives

RASP and in-app ADR instruments run inside the application and trace how input moves through code until it reaches a sink, which is a function where data becomes an action such as a database query or shell execution. Because these tools know the input source, the execution path, and the dangerous sink, they can block at the exact point of misuse rather than guessing from packet patterns. That makes them especially strong against injection-class attacks and logic abuse. Their main limitation is scope: if execution bypasses the runtime, the in-app hooks never fire.

Practical implication: place in-app runtime controls where you need precision around sinks, data flow, and third-party library behaviour.

In-kernel ADR and eBPF: why OS visibility complements app context

In-kernel ADR uses eBPF to observe syscalls at the Linux kernel layer, so it sees process activity after code has already crossed the runtime boundary. That gives defenders visibility into shell spawning, file access, network calls, and other post-exploitation behaviour that in-app tools may miss. The tradeoff is that kernel telemetry lacks application context, so policy must be more binary, such as blocking a process from spawning a shell or writing to a restricted path. This is especially useful when an attacker uses a native module, direct syscall, or other bypass that avoids application hooks.

Practical implication: reserve kernel-level ADR for post-exploitation visibility, host policy enforcement, and runtime bypass detection.

Threat narrative

Attacker objective: The attacker wants to turn a request-level foothold into code execution or post-exploitation activity that survives edge filtering and in-app inspection.

1. Entry begins at the HTTP edge, where malicious or high-volume traffic first meets the WAF rather than the application runtime.
2. Escalation occurs when payloads reach application code, trigger dangerous sinks, or bypass in-app hooks through native execution or direct syscalls.
3. Impact follows when the attacker moves into shell execution, file access, or lateral activity that only host-level telemetry can still observe.

NHI Mgmt Group analysis

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.

Application context is the decisive advantage for blocking misuse near the sink. A control that understands input lineage and execution path can distinguish between harmless traffic and a request about to become a database query or shell invocation. That is why in-app tooling reduces false positives and improves precision for injection-class abuse. Teams should map these controls to application logic, not just to the presence of traffic.

Runtime blind spots are the governance gap teams keep underestimating. Edge tools cannot see code intent, and kernel tools cannot see user context. The resulting gap is a coverage mismatch, not a product failure, and it becomes more visible as applications mix third-party dependencies, native code, and automated access. The practical conclusion is that governance must be layered around visibility boundaries, not vendor categories.

Post-exploitation visibility is becoming a baseline expectation for mature programmes. Once attackers reach a shell or host-level process, the security question changes from blocking input to constraining what the process can do next. That shift aligns with broader zero-trust thinking and with NHI governance where standing access, secrets exposure, and runtime abuse often intersect. Practitioners should align runtime telemetry with least-privilege enforcement and incident containment.

Runtime control strategy should be built around attack phase, not technology preference. The right control depends on whether the threat is edge noise, sink-level misuse, or host-level execution. Teams that design by phase can justify where WAF ends, where in-app ADR begins, and where kernel telemetry adds value. That makes control selection more defensible to security, engineering, and risk stakeholders.

What this signals

Visibility is the control boundary that determines whether runtime security is preventive or merely observational. When teams cannot see service accounts or workload identities clearly, edge and host telemetry still leave gaps in the chain of custody for access. That is why control design needs to start with identity inventory, then extend into runtime enforcement and monitoring.

Runtime governance will increasingly sit alongside secrets, workload identity, and policy enforcement. As applications rely more on automated access, the distinction between application security and identity security blurs at the point of execution. Teams should expect more scrutiny of where secrets are used, where processes are allowed to act, and how those actions are logged and constrained.

For practitioners

• Map each control to an attack phase Document which threats are handled at the edge, in the application, and at the kernel layer. Use that map to stop treating WAF, RASP, and ADR as interchangeable coverage options.
• 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. That is where code context provides the highest value.
• 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. The aim is to retain visibility after the runtime boundary is crossed.
• Align runtime policy with identity and secrets governance Tie application runtime controls to the service accounts, API keys, and workload identities that the app uses. If the process should not spawn a shell or reach an unexpected service, enforce that through policy and access design.

Key takeaways

• WAFs, RASP, and ADR solve different problems, so governance fails when teams treat them as substitutes.
• In-app runtime controls offer the strongest context for sink-level abuse, while kernel-level ADR extends visibility after execution escapes the runtime.
• Identity-aware runtime security matters because service accounts, secrets, and workload identities often define the real blast radius.

Key terms

• Runtime Application Self-Protection: RASP is a runtime control that detects and can block suspicious application behaviour as it happens. In NHI contexts, it can contain abuse from service accounts or tokens, but it does not replace identity ownership, entitlement review, rotation, or deprovisioning.
• Cloud Application Detection And Response: Cloud Application Detection and Response is the practice of identifying suspicious behaviour inside live cloud applications and workloads, then containing that behaviour before it spreads. It focuses on runtime signals such as unusual access, API misuse, and escalation paths that scan-time posture tools cannot see.
• eBPF: eBPF is a Linux kernel technology that lets security tools observe selected system events without modifying the kernel itself. In runtime protection, it is used to watch syscalls, process activity, and host behaviour, which helps detect post-exploitation actions and policy violations.
• Sink: A sink is a point in code where input stops being inert data and becomes an action, such as a database query, shell command, or file write. Runtime controls focus on sinks because that is where a benign-looking request can turn into a security incident.

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

👉 Aikido's full post covers the attack paths, tradeoffs, and deployment details behind each runtime security layer.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security and identity practitioners align access design with operational control across modern environments.