3.5 AppSec implementation cheatsheet
Persona: AppSec Leader
Block mode vs. Monitor mode — Decision matrix
Factor | Monitor mode | Block mode |
What it does | Detects and reports exploits; does not interfere with execution | Detects and stops exploits in real-time; the malicious request is terminated |
Risk | Attacker’s exploit succeeds (but you know about it) | A potential false positive blocks a legitimate request |
Best for | Initial rollout, low-confidence rules, non-critical apps, learning period | High-confidence rules, critical apps with well-tested policies, and known-exploited vulnerabilities |
Start here if… | You’re deploying ADR for the first time | You’ve validated in Monitor mode and have zero/low false positives |
Recommended rollout approach:
Phase | Duration | Mode | Scope |
1 — Observe | 2–4 weeks | Monitor only (all rules) | Tier 1 (critical) applications |
2 — Validate | 1–2 weeks | Monitor + review all alerts for false positives | Tier 1 applications |
3 — Selective Block | Ongoing | Block for high-confidence rules; Monitor for the rest | Tier 1 (critical) apps first |
4 — Expand | Ongoing | Block for validated rules across broader app portfolio | All tiers |
Per-rule modes and exclusions
Each ADR rule can be independently set to Off, Monitor, or Block, either per application or organization-wide through Policy management > Protect rules. The goal is Block Mode for every ADR rule on every Tier 0 and Tier 1 app.
Because ADR detects exploitation at the code level rather than matching request patterns, Block Mode runs with a low false-positive rate, far below what perimeter tools produce. Leaving a rule in Monitor on a critical app should be a deliberate, documented decision, not a default. See Set Protect rules for more information.
Per-rule mode
Each ADR rule can be independently set to Off, Monitor, or Block, either per application or organization-wide via Policy management > Protect rules. The goal is Block Mode for every ADR rule on every Tier 0 and Tier 1 app. Because ADR detects exploitation at the code level rather than matching request patterns (see 2.3), Block Mode runs with a low false-positive rate, far below what perimeter tools produce. Leaving a rule in Monitor on a critical app should be a deliberate, documented decision, not a default. See Set Protect rules.
Exclusions are an escape valve, not a tuning step. ADR does not require exclusions to run safely in Block Mode. Exclusions exist for three narrow cases:
The application is doing something insecure that legitimately needs to keep working. At the same time, the underlying issue is fixed (e.g., a tool that passes user input directly to a shell, or an internal report that generates unparameterized SQL). Block Mode is correctly stopping the request. Add a scoped exclusion for that specific rule plus URL/input/code path, open a remediation ticket on the underlying behavior, and keep the rule in Block everywhere else.
Highly sensitive workloads where AppSec wants to constrain Block Mode to a known-good profile out of extra caution.
An emergency, when Block Mode has unexpectedly blocked a legitimate request. Prefer a scoped exclusion over a full rule disable.
If you find yourself adding many exclusions, the signal is to look at the application, not the rule. See Application exclusions and Add application exclusions.
Application Risk-Tiering guide
Tier | Criteria | ADR policy |
Tier 1 — Critical | Revenue-generating, customer-facing, handles PII/PCI/PHI, regulatory scope | Block mode (after validation). All alerts → SIEM. Highest SLA. |
Tier 2 — Important | Internal apps with sensitive data, partner-facing, support critical processes | Monitor mode initially → Block after validation. High-severity alerts → SIEM. |
Tier 3 — Standard | Internal tools, low-sensitivity data, limited blast radius | Monitor mode. Critical alerts only → SIEM. |
Communicating Block Mode to engineering
When enabling block mode on an application, engineering needs to know:
What to tell them | Why |
Which applications are moving to Block Mode | They own the rollback if something breaks |
What types of requests will be blocked | So they understand the potential impact on functionality |
How to identify an ADR block vs. an application error | ADR blocks code execution; the response depends on how the application handles the blocked path. Check the ADR dashboard to confirm blocks. |
Who to call if production is impacted | AppSec on-call → can disable Block Mode in minutes |
The expected rollback time | Define SLA: e.g., “Block mode can be disabled within X minutes of a confirmed production impact.” |
Escalation to engineering — when and how
Trigger | Action | Who |
Block Mode is suspected of breaking production | Immediate: disable Block Mode for the affected rule/app. | AppSec on-call (or Eng if AppSec is unavailable) |
Active exploitation detected, no patch available | Request an emergency hotfix or virtual patch via ADR Block Mode | AppSec → Eng Lead |
ADR agent causing performance degradation | Reduce instrumentation scope or switch to Monitor mode. | AppSec → Eng on-call |
New vulnerability discovered by ADR at runtime | Create a Jira/ticket with ADR-provided code location and remediation guidance | AppSec (auto or manual) |