Program and Packaging

## The shape of the product ZAP is not one monolithic application. It is a **core program** on a single version line plus a directory of **add-ons** — `.zap` archives read out of the install's `plugin/` folder at startup, each with its own independent version number and its own release cadence. Saying *"ZAP does X"* is therefore ambiguous in a way that matters operationally: two installs that report the same program version can differ in what they can do, because they carry different add-on sets. An add-on plugs into core through one surface, `ExtensionHook`. Through it an add-on registers extensions, command-line arguments (`addCommandLine`), control-API components, HTTP-sender listeners, input-vector `Variant`s and automation job names. Because the registration is uniform, an add-on's contributions are **indistinguishable from core's** once ZAP is running: an add-on's flag looks like a core flag, an add-on's API component looks like a core component. That uniformity is the whole reason this distinction has to be learned rather than observed. ## What is genuinely core | capability | where it lives | |---|---| | the command line, the control API, the session database | core | | the **active-scan engine** (`paros.core.scanner`) | core — only the active **rules** are add-ons | | the passive-scan **rule contract** (`PassiveScanner`, `PluginPassiveScanner`) | core, and not deprecated | | the passive-scan **engine** that schedules and runs those rules | the `pscan` add-on | | the local HTTP proxy listener and the root certificate authority | the `network` add-on | | the crawlers | the `spider`, `spiderAjax` and `client` add-ons | | automation plans, rendered reports, alert filters | three separate add-ons | The asymmetry in the middle rows is the single most useful thing on this subject. **The passive engine left core; the active engine did not.** And the passive row itself split: a passive rule is written against a **core** base class, and it is **an add-on** that drains the history table and runs it. Whenever you describe passive scanning, say which half you mean. ## Three shapes the boundary takes Two of these are ways a subsystem leaves core; the third is a packaging shape that never involved a move at all. 1. **A move-out that leaves a deprecated shim.** The old package survives in core with type-level `@Deprecated` markers so that add-ons compiled against it still link. This is the case for the proxy, the certificate authority and the passive engine. 2. **A move-out that leaves nothing.** The traditional spider moved into the `spider` add-on and its old core package simply does not exist any more. A move-out does not have to leave a footprint, so the absence of a shim is not evidence that a capability is core. 3. **An add-on that was never core code at all.** Some add-ons ship **no classes at all** — their manifest lists files that are unpacked into ZAP's home directory on install, for a core subsystem to read. The standard scan policies are packaged this way: the policy *machinery* is core and reads a directory, and the shipped policy *files* arrive as an add-on that drops them there. Nothing about the add-on boundary implies code, and nothing about an add-on's data implies that the subsystem reading it moved. ## Why the shim is a trap A grep or an IDE lookup will happily resolve a moved-out class in the core source tree. That hit proves a shim is present; it does not prove the capability runs from there. The honest checks are different: - read whether the type carries a type-level `@Deprecated` marker; - ask which package the *live* implementation sits in; - from a running install, list what is actually loaded rather than reasoning from the source tree. ## Why a pipeline reader should care - A capability you rely on may be **absent from this build** even though it is present in the project, because its add-on was never installed. - A capability may be present and still **not running**, because its add-on failed a requirement at load time. - Upgrading the program does not upgrade the add-ons, and upgrading an add-on does not upgrade the program. They are separate decisions with separate blast radii. - Describing a finding as *"ZAP reported it"* loses the information a reviewer needs. *"An `ascanrules` active rule reported it"* or *"a `pscan`-scheduled passive rule reported it"* is reproducible. ## How to say it correctly Name the owner every time: *"core's active-scan engine"*, *"the `pscan` add-on"*, *"the `network` add-on's local proxy"*. Never *"ZAP lets you…"*. Every identifier in a mis-attributed sentence can be real while the sentence is false, and no tooling catches that — only the habit of naming the owner does.