skip to content

A ZAP active scan rule floods your pipeline with alerts — why won't lowering its attack strength help?

level: seniorimportance: should knowfreq 50%

answer

  1. the two dials act at different moments
  2. noise is produced when a rule reports
  3. cheap checks survive a strength cut
  4. a muted rule still sends its requests

basics

~20 s

Attack strength is spent before the requests go out and does not move the reporting bar. Lowering it makes the rule try fewer payloads, so you keep the cheap false positives and lose real findings. Noise is a threshold question.

solid answer

~40 s

Because the two dials sit on opposite sides of the rule. `AttackStrength` decides how much the rule *tries*; `AlertThreshold` decides how much evidence it demands before it *reports*. A rule that is noisy at Medium strength is usually noisy on its cheapest checks, so dropping to Low keeps those and discards the deeper payloads — the alert count barely moves and the coverage you paid for is gone. Raise that rule's `threshold` instead, and if it is simply wrong for this application, set it to `'Off'` rather than half-muting it. There is a second-order hazard too: in an `activeScan-policy` job, setting only a `strength:` on a rule calls `setEnabled(true)` on it unconditionally, so "quietening" a rule this way can switch back on a rule that `defaultThreshold: 'Off'` had disabled.

go deeper

for a junior

Recall the direction: fewer alerts is a threshold change, less traffic and time is a strength change. Do not reach for strength to fix noise.

for a middle

Explain why a strength cut keeps the noise: the cheap generic checks run at every level and the deeper payloads are what you discard.

for a senior

Show the production judgment — name the symptom, pick the dial, and say what the change costs, including that muting a rule does not stop it attacking the target.

for a principal

Own the policy question rather than the knob: decide whether a rule that needs permanent muting belongs in the pipeline's policy at all, and make that decision reviewable.

## Why the wrong dial feels like the right one Both dials read as intensity knobs, and *noisy scan* sounds like *too much intensity*. But they act at different points in a rule's life: - **`AttackStrength`** is consumed **before** the requests go out. It is the rule's payload budget. - **`AlertThreshold`** is consumed **when the rule decides whether it has seen enough** to raise an alert. Alert volume is produced at the second point. Turning the first one down changes what the rule looked for, not what it was willing to say about what it saw. ## What actually happens when you lower the strength Rules spend their strength budget in roughly increasing order of cost and specificity: the cheap, generic checks run at every level, and the expensive, narrower ones are gated behind Medium, High or Insane. A rule that is drowning your pipeline is usually drowning it from the cheap end — generic error-string matching, broad response comparisons, the checks most prone to matching something innocuous. So dropping that rule to Low: 1. **keeps** the cheap checks that are generating the noise; 2. **discards** the deeper payloads that were the reason to run the rule at all; 3. **reduces** scan time and traffic, which is real but was not the problem you had. You end up with roughly the same false positives, fewer true ones, and a shorter run. That is a worse scan that *looks* like it was tuned. ## What to reach for instead | the symptom | the dial | what it costs you | |---|---|---| | too many alerts from one rule | raise that rule's `threshold` | findings the rule was only moderately sure about | | the scan takes too long, or hits the target too hard | lower `strength`, globally or per rule | depth — the payloads only tried at higher levels | | this rule is simply wrong for this application | `threshold: 'Off'`, or leave it out of a locked policy | that rule's coverage, honestly and visibly | | this one finding is wrong, but the rule is useful | not a dial at all — a different mechanism owns it | nothing here; the requests are still sent either way | The last row matters for a pipeline reader: a rule you merely stop reporting has still attacked the target. Of the controls a policy offers, only turning the rule off stops the traffic. ## The mirror mistake, and why it is less wrong The symmetrical error is raising thresholds to make a scan *finish faster*. That is the wrong dial for the stated goal — the threshold is not a time budget — but it often has the effect anyway, because a rule commonly implements "be more sure" by not running its least reliable checks at all, and those checks send requests. Shipped rules do exactly this: at a High threshold, whole check families switch themselves off. So the honest statement is not that the dials are sealed off from each other. It is directional: **strength never moves the reporting bar, while the threshold frequently moves request volume as a side effect** — rule by rule, and not as a contract you can plan a scan window around. ## The second-order hazard in a plan There is a concrete way that reaching for the strength dial makes things worse rather than merely useless. In an `activeScan-policy` job, each rule entry is applied in two steps, and the strength step is unconditional: - if the entry has a `strength`, the job sets it **and calls `setEnabled(true)` on that rule**; - if the entry has a `threshold`, the job sets it and sets `enabled` from whether it was `Off`. That is deliberate — it is what makes the *off by default, then name the survivors* pattern work, where `defaultThreshold: 'Off'` disables everything and a listed rule's strength brings it back. But it means that adding `strength: low` to a rule in a policy that had disabled it silently switches that rule back on. If a listed entry carries both, the threshold is applied second and wins. ## Saying it to an interviewer The sentence that demonstrates you have actually tuned one of these: *"Alert volume is a reporting property, so it is a threshold question; scan duration and traffic are an attack property, so they are a strength question. If the rule is wrong for the app, I would rather turn it off in a reviewable policy than leave it running at Low where it still reports and no longer finds anything."*

  • You want the scan to finish inside a shorter CI window. Which dial, and what do you lose?
    Strength — that is the traffic-and-time dial. Lowering it, globally or on the heaviest rules, drops the payloads only tried at higher levels, so you lose depth rather than reporting quality. Trimming the rule set in a locked policy is often the bigger win.
  • Why is raising a threshold to `HIGH` not a reliable way to shorten a scan, even though it often does?
    Because the reduction is a side effect of individual rules choosing to skip their least reliable checks at that level, not an engine behaviour. Rules that gate nothing on the threshold send exactly the same requests, so the saving is unpredictable and rule-dependent.
  • A rule is noisy on one endpoint only. Is the threshold still the right dial?
    Usually not — both dials are per-rule and global to the scan, so raising the threshold gives up that rule's moderate-confidence findings everywhere. A scope or per-finding mechanism fits a single-endpoint problem better; the dials are the wrong granularity.

saying these in an interview costs you the question

  • Treats lowering strength as a way to cut false positives
  • Says a shorter scan proves the tuning worked
  • Believes a muted rule stops sending requests
  • Assumes raising the threshold always shortens the scan
  • Adds a strength override to a rule the policy had disabled