What does an OWASP ZAP add-on's alpha, beta or release status actually tell you?

## The enum, and where the value comes from Every ZAP add-on carries a status drawn from `AddOn.Status`, whose values are `unknown`, `example`, `alpha`, `beta`, `weekly` and `release`. The value is not assigned centrally and it is not derived from test results: each add-on declares its own in its Gradle build script, as `addOnStatus.set(...)`, and the generated manifest carries it into the published archive. You can read it back from a running install — the add-on listing prints it in a column beside each add-on's id and version. ## What the value means, and what it does not The status is a statement about the stability of the add-on's **public interface** — the classes and extension points that other add-ons compile against. An add-on at alpha may still rename or remove public types; an add-on at release has undertaken not to, within its major line. That is the axis, and it is the only one. | people read it as | it actually says | |---|---| | how well tested the add-on is | nothing | | how important the add-on is to a working install | nothing | | whether the project supports it | nothing | | whether it is safe to use in a pipeline | nothing | | how likely its public API is to change under dependants | exactly this | ## The measurement that settles it Three add-ons in the shipped set make the point on their own: - **`network`** supplies the local proxy listener and the root certificate authority, is one of the two add-ons ZAP refuses to start without, and ships at **beta**. - **`pscan`** is the live passive-scan engine — the component that drains recorded traffic and runs every passive rule — and ships at **alpha**. - **`callhome`** handles the program's outbound service calls and ships at **release**. So an add-on the program refuses to start without carries a label below release, while a label at release sits on one whose absence would change no scan's findings. Status and importance are orthogonal, and this set is the evidence rather than an argument about it. The same pattern repeats across the scripting engines: every engine that lets ZAP run a script in a given language ships as an add-on, and not one of them is at release. Anyone who has run a script in ZAP has already relied on something the status column would have refused. ## Why the misreading is expensive in a pipeline A policy written by someone who reads the label as a quality grade — *"we only permit release-status components in CI"* — has a concrete outcome: 1. Passive scanning stops, because the engine is alpha. A baseline run would report nothing and still exit as if it had worked. 2. The program will not start at all, because the mandatory networking add-on is beta and cannot be removed. 3. The scripting engines go, because none of them is at release either. That is not a hypothetical: it is what the labels imply if you take them as fitness signals. The correct control is not the status column but the **pinned add-on set** — deciding which add-ons a scanning image carries, and changing that set deliberately. ## What to do with the status instead Read it the way you read an unstable major version on a library you are *building against*: - if you write an add-on, a script or a plugin that depends on another add-on's classes, the status tells you how much churn to expect; - if you only *run* ZAP, the status is close to irrelevant — what matters is whether the add-on is installed, whether it is running, and which version you pinned; - treat `example` as what it says: sample code shipped for people learning the extension points, not a capability; - treat `unknown` as an add-on whose manifest did not declare one, not as a warning; - if you are auditing an image, read the status column as *documentation of churn risk for add-on authors*, and read the version column beside it as the thing you actually pinned. One more asymmetry is worth holding on to. The status label is declared by the add-on's own authors, in the add-on's own build, and nothing external validates it. It is a self-description with a useful and narrow meaning, not a grade awarded by a process. ## The sentence to keep *The status tracks API maturity, not importance.* If you need a single line to stop a colleague building an add-on allow-list out of the status column, that is the line — and the fact that the proxy the program cannot start without is labelled beta is the evidence that ends the argument.