How would you standardise where OWASP ZAP scope is declared across many unattended pipelines?

## The problem you are actually solving Across a fleet of pipelines running OWASP ZAP, "what may this run touch?" can be answered in at least three unrelated places: a context's include and exclude lists, the session's per-subsystem exclusion lists, and the `network` add-on's global exclusions. They are stored differently, read by different components, matched by different rules, and only some of them can be written in the file that lives beside the application. A standard that does not choose between them is not a standard; it is a recommendation that each team will resolve differently, and you will find that out from an incident rather than from a review. ## What should carry the boundary The **context block in the automation plan** is the only credible home for it, for reasons that are properties of the tool rather than preferences: - It is the only scope layer expressible in a plan, so it is the only one that can live in the application's repository, be diffed, and be reviewed by the people who know what the application is. - It is the layer every scanning component consults, directly or through the derived scope value, once a job is bound to the context. - It is version-controlled by construction, which means a change to what a scan may reach arrives as a reviewable change rather than as a setting someone altered on a machine. What you give up by choosing it is real and should be stated rather than discovered: a context is matched against the URL **with the query removed**, so any boundary that can only be expressed in terms of a query parameter cannot live here at all. ## The exceptions, and how to bound them 1. **An endpoint that must be kept away from the active scanner specifically.** The session's exclude-from-scan list is the right layer, and a plan can reach it through the `activeScan-config` job. Make that job the only sanctioned writer, and require the key to be present whenever the job is — the job replaces the list from its own data, so an `activeScan-config` with no exclusions silently clears whatever was there. 2. **Third-party noise on the wire** — asset hosts, telemetry endpoints, update services. That is the global layer. Accept that it cannot be written in a plan, that it needs the add-on present, and that it returns an empty list without complaint when the add-on is missing. If it is part of your standard, it belongs in the image or the base configuration, and something has to assert that it is actually there. ## What each layer costs you | layer | lives in | reviewable as a diff | can express a query-keyed rule | |---|---|---|---| | a context's include and exclude lists | the plan, beside the application | yes | no — the query is removed first | | the session exclude-from-scan list | the plan, via one job only | yes, if that job is the only writer | yes | | the `network` add-on's global exclusions | the image or base configuration | no | yes | The row that decides the standard is the middle column, not the right one. A boundary nobody can see in a diff is a boundary nobody reviews, and this is a setting whose mistakes are silent. ## Rules worth writing down - **Scope rules are full-match regexes over paths.** Every entry ends in `.*` unless it genuinely means one URL, and every literal dot is escaped. - **A pattern is written for one named layer** and is never copied into another. Anchoring is the only property that survives the move; the string it is matched against and whether case matters both change. - **Prefix every list-layer pattern with an inline case-insensitive flag**, as the shipped defaults do. It costs nothing where the layer already sets that flag. - **One context per plan unless there is a reason for more.** Exclusion crosses context boundaries: any in-scope context's exclude removes a URL every other context included. - **A narrower scope is not a safer result.** It is a quieter one. Everything a scan does not reach is absent from the report in the same way a genuinely clean endpoint is. ## How you would know it is working The thing to measure is not whether the scope block looks right but what each run actually reached: the count of URLs visited and how it moved when the block last changed. That number falling is the only early signal that a scope change did more than it meant to, and it is the one you want on a dashboard rather than in a log. Pair it with a review rule — a change to a context block gets the same scrutiny as a change to a deployment manifest — and with a periodic read of what is set outside the plan, because that is where the layers you standardised away will quietly reappear. ## Where the judgment actually is None of the above is forced by the tool; it is a choice about where the cost lands. Putting the boundary in the plan buys reviewability and pays for it in expressiveness. Putting it in the base image buys consistency and pays for it in invisibility — nobody reading the repository can see what the run will not touch. A team that cannot state which trade it made has not made one.