What would you require of an unattended ZAP scan job before it may start against a host?

## Start from what the tool cannot do A handful of measured facts set the whole problem, and any credible answer starts by conceding them: 1. **The program holds no authorisation fact.** There is no ownership lookup and no confirmation step. The target is a string, used as given. Scope is something you assert, and the program never checks your assertion against anything. 2. **The control that can refuse a scan is off by default and nothing shipped turns it on.** `Control.Mode` is persisted as `view.mode`, defaults to `standard`, and is set by nothing under the packaged wrapper directory or the `automation` add-on. Every unattended run is unrestricted. 3. **Proxy exclusion is bookkeeping.** A matched request is still sent; only the record of it is suppressed. An exclude list cannot hold a boundary. So the question is not which ZAP setting to turn on. It is **where the boundary lives**, and the honest answer is that it mostly lives outside the scanner. ## Where the boundary can live, and what each place costs | where | what it gives you | what it costs | |---|---|---| | **Before ZAP starts** — the target is derived, not typed | prevents the wrong host from ever being an argument | you must have a trustworthy source for the target, and a defined behaviour when it is missing | | **Inside ZAP** — `-config view.mode=protect` plus a context that includes only what you signed for | a loud, early, attributable refusal at scan start | admission-only; it does not filter what an admitted scan sends, and it does not touch the proxy path | | **Around the runner** — egress restricted to the hosts in bounds | the only non-advisory control of the set | it lives with whoever owns the runner, and it is the hardest of them to change per job | None of them subsumes the others, which is why this is a judgment question rather than a configuration question. Most teams can get the first cheaply, should take the second because it is nearly free and fails loudly, and can only get the third if they own the environment the job runs in. ## What I would actually require of the job 1. **The target is derived from the thing being deployed**, not carried as a hand-edited literal. The commonest real incident on this subject is a copied job, or an edited variable, that still runs perfectly against the wrong host. 2. **Fail closed when the target cannot be resolved.** The tool has no safe default here — hand it any string and it scans it — so the fail-closed behaviour must exist before ZAP is started. A job that falls back to a default URL is the defect. 3. **Set the mode explicitly rather than inheriting it.** `protect` with an accurate context turns "we pointed it at the wrong host" into a refusal at the moment of the start call. That is worth having even though it is not containment, because it is early and it names the reason. 4. **Do not express the boundary as a proxy exclusion.** If a host must not be touched, it must not be reachable or it must not be a target. Putting it on an exclude list produces a clean report about traffic that still went out. 5. **Say which control you are relying on, in the job, where the next reader will find it.** The run's own output does not distinguish "in bounds" from "reached"; if the reason a host was permitted is not written down beside the job, nobody recovers it later. ## The tradeoff to name out loud Restricting the mode and defining a context has a cost, and a lead should say so rather than pretending the control is free: - it is another piece of configuration, and configuration drifts out of agreement with reality; - when it drifts, the failure is a refused scan — a red pipeline for a legitimate target; - it guards the door and not the room, so it can create a false sense of containment in a reader who has not been told what it actually checks. The opposite posture — leave everything unrestricted, rely entirely on the target being right — has no configuration to drift and no false refusals, and its failure mode is attack traffic arriving at a stranger with nobody informed. Those are not symmetric, which is why the restricted mode is worth its friction even though it only guards the door. ## The sentence to land on The scanner can refuse a scan on the basis of its own configuration. It can never refuse a target on the basis of who owns it, because that fact does not exist inside it. So the entitlement lives in the process, the reachability lives in the network, and the mode is a cheap, loud, partial backstop that is worth setting precisely because nothing sets it for you.