OWASP ZAP → Burp Suite Enterprise
OWASP ZAP ↔ Burp Suite Enterprise: integration to migration path.
DAST is load-bearing, so we never flip a switch. OWASP ZAP deploys alongside Burp Suite Enterprise first — running advisory in your pipeline while Burp keeps owning every blocking decision — and only takes over apps once it has proven its recall against them. No flag day, no re-credentialing, and every per-phase step rolls back in minutes.
The honest exception we lead with: on heavy single-page applications Burp's browser-DAST engine has no OSS equal. Those apps stay on Burp until ZAP genuinely covers them — we measure it, we do not assert it.
The idea
Run ZAP in the pipeline first. Retire Burp last.
The topology that makes this zero-downtime: ZAP runs as a per-PR baseline and active scan inside your existing CI, while Burp Enterprise keeps running its scheduled, deeper scans against the same targets. Findings from both flow into one DefectDojo aggregator, deduped on CWE plus URL plus parameter. Burp stays the blocking gate of record while ZAP proves itself app by app; only after a measured recall comparison passes does ZAP take over that app's gate, with Burp dropping to advisory before it is removed. You are never betting coverage on one cutover.
The phases
Seven steps. Each one reversible.
Baseline & inventory
We pull every Burp Site, schedule, and the last 90 days of findings via the Burp REST API, then classify each app by auth flow, OpenAPI presence, SPA-heaviness, and data classification. Read-only — nothing changes.
ZAP in CI, advisory-only
ZAP runs a baseline scan on every PR for a canary service, its Automation Framework YAML versioned in the repo. Findings flow into DefectDojo. No PR is ever blocked by ZAP — Burp stays the sole gate.
Expand coverage; baseline-then-diff
Every in-scope app gets ZAP AF YAML committed and baseline-then-diff active, so only net-new findings surface. Both tools ingest into DefectDojo, deduped on CWE plus URL plus parameter. Burp is still the only blocking gate.
Shadow comparison
A weekly recall report diffs ZAP against Burp's high/critical findings per app, enumerating exactly which classes ZAP catches and which it misses. This is the measured evidence that lets you stop renewing Burp honestly.
Promote ZAP to blocking
For apps that passed the recall gate, ZAP becomes the blocking PR gate and Burp drops to weekly advisory — still scanning, still a tripwire. Promoted in waves of low- to high-blast-radius, 7 days at 100% before the next app.
Decommission Burp for the migrated set
After a 30-day soak, Burp Sites for the migrated apps are deleted and the concurrent-scanner licence reduced — a PortSwigger contract conversation, not self-service. Apps that failed the recall gate stay on Burp.
Optional final retirement
ZAP becomes the only DAST and the Burp Enterprise contract ends — reachable only if every gap-class app is addressed with custom rules or deprecated. Otherwise the honest steady state is segmented coexistence and this phase is N/A.
Feature parity
Where ZAP matches Burp — and where it honestly does not.
| Capability | OWASP ZAP | Burp Suite Enterprise | Parity |
|---|---|---|---|
| Scan type (DAST) | Passive baseline plus active scan policy via Automation Framework | Burp Scanner (crawl plus audit) | At parity |
| SPA / DOM-aware crawl | AJAX Spider (Selenium); coverage materially worse | Burp browser-DAST (Chromium, shadow DOM, websockets) | SaaS only |
| API scanning | zap-api-scan.py over OpenAPI/SOAP/GraphQL; AF openApi job | Scanner API-definition upload | At parity |
| Authentication | Form/JSON/script-based (SAML/JWT) session scripts | Recorded login plus manual session handling | At parity |
| Finding format (SARIF) | SARIF 2.1.0 via AF report job or -J CLI | SARIF in recent Enterprise versions (version-dependent) | Partial |
| CI / PR integration | First-party GH Actions (action-baseline / -api-scan) | REST API needs a self-built CI wrapper | OSS only |
| Rule authoring | JS/Java/Python Scan Rules plus Passive Rules | Enterprise BChecks DSL | Partial |
| Baseline / diff | AF IGNORE/WARN/FAIL plus .zap/baseline.context in repo | UI issue suppression; no in-repo baseline | OSS only |
| Vendor-curated issue catalogue | Community add-on feed | PortSwigger Issue Definitions, vendor cadence | SaaS only |
| Dashboards / multi-tenant UI | DefectDojo plus K8s CronJobs (you build) | Enterprise sites/schedules/results UI | SaaS only |
| OWASP alignment | Rules tagged A01:2021 through A10:2021 plus CWE | Issue Definitions tagged | At parity |
| Deployment model | Self-hosted (Docker / K8s ZAP cluster) | SaaS / self-managed scanner cluster | Partial |
| Cost model | Free; CI minutes plus optional K8s | Per-concurrent-scanner licensing | OSS only |
| Vendor support | Community lists; budget triage time | 24/7 PortSwigger support SLA | SaaS only |
What we're honest about
The caveats most vendors leave out.
Burp's browser-DAST engine has no OSS parity
On heavy React/Vue/Angular apps with client-side routing, shadow DOM, and websockets, ZAP's AJAX Spider coverage is materially worse than Burp's vendor-tuned browser-DAST. It is the biggest honest gap. The Phase 3 recall comparison surfaces affected apps — they stay on Burp or get custom Playwright seed lists. We do not pretend AJAX Spider is parity.
Vendor-curated Issue Definitions move at PortSwigger's pace
New audit items ship on PortSwigger's research cadence; ZAP additions depend on community pull requests. Expect a coverage lag on novel issue classes. We subscribe to the ZAP add-on feed and budget AppSec time to author custom rules for the gap.
Enterprise scheduling and multi-tenant UI are real losses
Burp Enterprise gives a single pane for sites, schedules, and results. ZAP has no equivalent — you rebuild it from DefectDojo plus K8s CronJobs, and the UX is materially worse. Manageable for a small AppSec team, a real cost at scale.
You take on uptime and vendor support
Once Burp is gone there is no 24/7 PortSwigger SLA and no managed scheduling backstop. We mitigate with a self-hosted ZAP cluster (HA, dedicated CI runners), pinned browser versions, and budgeted triage time — but the operational ownership moves to you.
Why this beats a flag day
Reversible per phase. Soaked before any contract ends.
Every per-app cutover in this plan reverts in under 15 minutes while the parallel Burp coverage is still live — a two-line CI change plus a Burp Site schedule reset via REST API. And no Burp Site is ever deleted until that app has run on ZAP-only blocking for a minimum 30-day soak with zero critical findings missed; only then does the concurrent-scanner licence get reduced. The contract is the last thing to change, not the first.
See whether your DAST coverage migrates cleanly.
A 30-minute call with a senior AppSec engineer. We classify your apps by SPA-heaviness and auth flow, find the ones Burp's browser-DAST should keep, and tell you honestly which ones ZAP can take over — before you touch the contract.
Map my migration →