Chapter 2: Why ADR? — The two timelines
Persona: All (conceptual anchor for the rest of the handbook)
Time to read: 5 minutes
The core insight: your AppSec team and your SOC team each operate on a different timeline. These timelines collide at one critical point — exploitation. ADR exists at that intersection.
2.1 The vulnerability lifecycle
This is the AppSec team’s timeline. It runs left-to-right over days, weeks, or months.
VULNERABILITY LIFECYCLE (AppSec's World)
Key reality: The vulnerability exists in production for weeks or months before it’s patched. During this entire window, attackers can exploit it. Scanners find it eventually; ADR detects exploitation in real time.
2.2 The Incident lifecycle
This is the SOC team’s timeline. It runs top-to-bottom from minutes to hours.
INCIDENT LIFECYCLE (SOC's World)
Without ADR: The AppSec timeline and Incident timeline operate in silos. AppSec tracks tickets; SOC triages alerts from the perimeter. Neither has full context at the exploitation point.
With ADR: The ADR solution sits at the intersection and: - Tells the SOC: “This attack is targeting this specific vulnerability in this specific function of this specific application” — context no WAF or EDR can provide - Tells AppSec: “This vulnerability isn’t theoretical — it’s being actively exploited right now” — reprioritizing the backlog instantly - Optionally blocks the exploit in real-time without waiting for a patch.
2.3 Where the timelines intersect
The two timelines cross at exploitation — the moment an attacker uses a known or unknown vulnerability in a running application.
Without ADR: The AppSec timeline and Incident timeline operate in silos. AppSec tracks tickets; SOC triages alerts from the perimeter. Neither has full context at the exploitation point.
With ADR: The ADR solution sits at the intersection and: - Tells the SOC: “This attack is targeting this specific vulnerability in this specific function of this specific application ” — context no WAF or EDR can provide - Tells AppSec: “This vulnerability isn’t theoretical — it’s being actively exploited right now ” — re-prioritizing the backlog instantly - Optionally blocks the exploit in real-time without waiting for a patch.
Why runtime visibility is different
To understand why ADR can do what WAF, EDR, and NDR cannot, you need to understand where the sensor sits.
WAF | EDR | NDR | ADR | |
Where it observes | HTTP traffic at the network edge | OS-level processes, files, and network connections on the endpoint | Network traffic between hosts | Inside the application runtime — in the same process as your code |
What it sees | Request syntax and patterns | Process trees, file writes, socket connections, memory-based exploits | Packet payloads (if not encrypted) | Decrypted input, decoded parameters, the actual function call, the data flow from request to database to response |
Encryption | Sees traffic after TLS terminates at the load balancer/proxy — blind if TLS terminates at the app | Not applicable (OS-level) | Blind to TLS-encrypted traffic without a decryption infrastructure | Operates inside the app process — TLS has already terminated. Sees cleartext regardless of where encryption ends. |
Encoding/obfuscation | Sees the raw request. Attackers routinely bypass WAFs with encoding tricks (double-encoding, Unicode, case variation). | Not applicable | Same limitation as WAF if inspecting payloads | Sees the input after the application has decoded it — the actual value that reaches the vulnerable function, not the encoded version on the wire |
Can it confirm exploitation? | No — it matches patterns on requests. A “suspicious” request may be benign; a benign-looking request may be an exploit. | No — it sees symptoms (suspicious process) but not root cause (which vulnerability, which input) | No — same limitation as WAF | Yes — it observes the malicious input reaching a vulnerable function and executing. Confirmed, not inferred. |
Detection implication: Because the agent is inside the runtime, ADR provides verified detections. When ADR says “SQL injection exploited in execute() ,” it observed the injected query reach the database driver. A WAF saying “SQL injection pattern detected” is a guess based on request syntax — it doesn’t know whether the payload reached a vulnerable function or was harmlessly discarded by the application’s own input handling.
Response implication: Because detection is confirmed at the code level, blocking is surgical. ADR Block Mode terminates execution when a known vulnerability is actively being exploited — not when a request looks suspicious. This is why Block Mode can run in production with a low false-positive rate: the blocking decision is based on observed code-level exploitation, not pattern matching. A WAF in block mode must choose between aggressive rules (more false positives, more legitimate traffic blocked) and permissive rules (more attacks pass through). ADR doesn’t face that trade-off — it blocks what it can confirm.
2.4 ADR controls overlay
Where ADR provides value across both timelines:
Lifecycle Stage | What ADR Does | Who Benefits |
Code Written → Deployed | Runtime analysis identifies vulnerabilities as code executes (not just static patterns) | AppSec |
Vuln Discovered | Discovers vulnerabilities via runtime instrumentation; confirms exploitability | AppSec |
Exposure Window | Monitors exploitation attempts in real time | SOC + AppSec |
Exploitation (Intersection) | Detects and verifies the exact exploit, function, input, and data flow — confirmed real, not a pattern match | SOC |
Exploitation (Intersection) | Outcome Verification — reports whether the attack succeeded or was blocked, so the SOC can prioritize confirmed successful exploits | SOC |
Exploitation (Intersection) | Blocks the exploit at the application layer (Block Mode) | SOC + Eng |
Containment | Provides precise context for surgical containment (which app, which route, which function) | SOC |
Remediation | Identifies exact code location and remediation guidance | AppSec + Eng |
Ticket Prioritization | Elevates actively-exploited vulns above theoretical ones | AppSec |
Patch Verification | Confirms the vulnerability is no longer exploitable after deployment | AppSec + Eng |