Your team wants to drop a commercial workbench and use OWASP ZAP for everything. What do you warn them about?

## Start by naming what is actually being proposed "Drop the commercial tool and use this instead" bundles two different swaps, and they do not carry the same risk: 1. **The unattended half** — scheduled scans, a gate on a pipeline, a report someone reads on Monday. This transfers well, and it is where the project concentrates. 2. **The hands-on half** — a tester sitting with a request in front of them, working a single finding. This does not transfer like-for-like, and pretending otherwise is how the migration ends up reversed six months later. Separate them before you answer. A team that hears "yes" to both and then discovers the second half is different will blame the tool, the recommendation, or you. ## The evidence, from the project's own packaging You do not have to argue this from taste. The project says where its attention is: - The add-ons carrying the hands-on surfaces — `requester` and `fuzz` — ship at **`beta`**, and neither is marked as part of the core distribution in the core repository's distribution list. A plain core install does not have them. - The access-control testing add-on is not in that distribution list at all; it has to come from the marketplace. - The browser-overlay surface is not even in the add-on repository — it lives in its own, and the project's own catalogue note says it is disabled by default because *"it still works but its flaky, and currently not a focus for us"*. Set that beside the unattended side, where the core program registers the headless option itself and the client libraries for several languages are generated from the control API automatically. ## Read the maturity label correctly Here is the trap, and it cuts the other way from how most people use it. The status on an add-on is about **API maturity** — how likely its programmatic surface is to change — not a quality grade. The automation framework that a great many pipelines depend on wears the same `beta` label, and so does the networking add-on that provides the local proxy every run goes through. So: - ❌ "It is beta, therefore it is unreliable." - ✅ "It is beta, therefore its API may still move; budget for that when you build on it." If you reject the interactive add-ons because of the label, you have to reject the automation framework too, and nobody does. The honest reason to be cautious about the hands-on swap is **where the effort goes**, not the four letters next to it. ## What to actually tell the team | their expectation | the honest correction | |---|---| | "same product, no licence" | different centre of gravity; the unattended half is the strong half | | "we lose nothing" | the hands-on workflow changes shape, and people have to relearn it | | "beta means bad" | it is an API-maturity label that the automation framework carries too | | "one tool is simpler" | one tool is simpler only if one tool actually covers both jobs | And give them a decision rule rather than a verdict: **swap the job, not the toolbox.** Move the unattended work first, run it in parallel with what you have for a release or two, and compare what each run produced on the same target before you retire anything. If the hands-on half is a small part of the work — which on many QA teams it genuinely is — the swap may be right anyway. Decide it with the number of hours, not with the licence line. ## The failure mode to name out loud The thing that actually goes wrong is not a missing feature. It is that the people who did the hands-on work lose the workflow they were fluent in, do it more slowly, and quietly stop doing it. The finding count then goes up, because the unattended scan is now the only thing running and it reports what unattended scans report. That looks like an improvement on a dashboard and is not one. So the warning, in one sentence: *you are not buying the same product cheaper — you are choosing a tool whose strong side is the side you were not paying for anyway, and the side you were paying for is the one that changes.* Whether that trade is good depends entirely on how much of your team's week is spent on each side, which is a measurement you can take before you decide.