Trackr.Live The landing site for Trackr Services
§ Trackr.Live

ZAP (OWASP ZAP)

Start with the name, because the name is now wrong. The tool most people still type into a search bar as “OWASP ZAP” has not been an OWASP project since August 2023, and as of 2026 it is branded ZAP by Checkmarx. The acronym (Zed Attack Proxy) survived the move; the OWASP prefix did not. If your tooling inventory, your SSP, or your pipeline docs still say “OWASP ZAP,” that string is stale, and the reason it changed tells you something about how this tool is funded and who keeps it alive.

Schematic of an intercepting proxy sitting between a browser and a web application, passively reading traffic on one path and injecting test payloads on another, with findings sorted into a triage queue.

What ZAP actually is hasn’t changed across any of that. It’s an intercepting HTTP/HTTPS proxy that sits in the middle of traffic between a browser (or an API client) and a running web application, reads everything passing through, and can be pointed at that application to inject attack payloads (SQL injection, cross-site scripting, the rest of the OWASP Top 10 surface). It is the most widely deployed open-source dynamic application security testing tool, Java-based, Apache 2.0 licensed, and it runs on Windows, Linux, and macOS. The 2.17 line requires Java 17 or higher. Free with no paid tier and no feature gating, which is most of why it ended up in so many CI pipelines.

Who owns it now, and the version that’s actually current

The stewardship history is worth getting right because the seed version of this story circulates wrong. ZAP did not leave OWASP in 2024, and it is not run by the Software Security Project today. The actual sequence: in August 2023 the core team announced they were leaving OWASP to join the Software Security Project, an arrangement meant to land under the Linux Foundation. That Linux Foundation funding fell through, so ZAP never formally joined the LF. Then on September 24, 2024, the three core developers (Simon Bennetts, Rick Mitchell, Ricardo Pereira) became Checkmarx employees, and the project was rebranded ZAP by Checkmarx. The current steward is Checkmarx. Not OWASP, not the SSP. The project still describes itself as independent and controlled by the ZAP Core Team, with Checkmarx paying the maintainers and putting its name on the box. The code still lives at github.com/zaproxy/zaproxy, where the repo now reads “The ZAP by Checkmarx Core project.”

Latest stable is 2.17.0, released December 15, 2025. The release before it, 2.16.0 (January 2025), was the first stable build fully under Checkmarx branding and the one that bumped the Java floor to 17 and reworked the default spider. Worth noting that the version numbers ran straight through the ownership change (2.14, 2.15, 2.16, 2.17) with no reset, so don’t read the rebrand as a new product line. It’s the same codebase with a new sponsor. Weekly dev builds keep shipping off the main branch most Mondays; the current one at time of writing is dated 2026-05-27 if you need a feature that hasn’t reached a tagged release yet.

There’s a flag to plant here, and I’ll mark it as opinion: the Checkmarx arrangement is a net positive for ZAP’s survival but a standing conflict of interest worth watching. Paid maintainers and continuity beat the alternative, which for an unfunded open-source DAST tool is slow death. But Checkmarx sells a commercial DAST and SAST product, and ZAP is now the open-source feeder for that enterprise offering. Treat the project’s roadmap independence as something to monitor across releases, not something to assume.

Where it sits in the compliance flow

This is where people miscategorize ZAP, so be precise about it. ZAP scans a running application. That makes it a dynamic testing tool, and in NIST SP 800-53 terms it lives under SA-11, Developer Security Testing and Evaluation, specifically SA-11(8), dynamic code analysis. It maps cleanly there. What it does not do is satisfy RA-5, Vulnerability Monitoring and Scanning, the control your ACAS/Nessus host scans answer to. RA-5 is about scanning the deployed system’s hosts and network for known CVEs and misconfigurations. ZAP doesn’t touch that lane. It probes application behavior, not host posture, and an assessor who knows the difference will not accept a ZAP report as RA-5 evidence.

That distinction also tells you who runs it and when. ZAP belongs to the app team or the DevSecOps pipeline, not the ISSO kicking off the monthly ACAS scan against the host inventory. It runs in CI/CD as a pre-deployment gate. The realistic cadence is a fast baseline scan on every pull request and a full active scan per release, against a dedicated test environment. Where the pipeline configuration that invokes ZAP gets graded, that’s CM-6 territory (configuration settings), and the broader development tooling story touches SA-15. Supply-chain SR controls apply only weakly, since ZAP is a build-time test harness rather than a runtime asset in your boundary.

One thing it is not: a FedRAMP-authorized service or a DoD APL appliance. There’s no marketplace listing to cite and no APL entry, because ZAP is a free CLI/Docker tool you run inside your own pipeline. State that plainly in any documentation rather than implying an authorization it doesn’t have.

Deeper: why DAST answers to SA-11 and not RA-5. The split comes down to what’s being tested and at what stage. RA-5 is operational vulnerability monitoring of the system as deployed: known CVEs, missing patches, host and network exposure, the kind of thing that feeds eMASS and the POA&M on a recurring scan cycle. SA-11 is developer testing of the software during its construction, before and around deployment, to find flaws that no CVE database knows about yet because they’re defects in your code. A SQL injection ZAP finds in your login form isn’t a known-vulnerability problem; it’s a coding defect, which is squarely SA-11(8) dynamic analysis. Filing a ZAP finding as RA-5 evidence conflates the two and invites a finding of its own. The cleanest framing: ACAS tells you the OS is unpatched, ZAP tells you the application is broken, and those are different controls with different owners.

Scan shapes and operational reality

ZAP runs in three practical shapes for automation, and picking the wrong one is the most common self-inflicted wound.

Scan mode What it sends Where to run it Speed False positives Pipeline fit
Baseline Passive only, no attack payloads Any environment, including shared/staging Fast (minutes) Low Per-PR gate
Full Active injection across attack policies Dedicated test env only, never prod Slow (can run long) High and noisy Per-release
API Passive + active driven by an OpenAPI/SOAP/GraphQL definition Test env for active mode Varies with spec size Moderate API-heavy releases

Drive all three through the Automation Framework, the YAML-configured job system that has subsumed the old packaged baseline and full-scan shell scripts. The legacy scripts still work, but the framework is where new capability lands and where you get repeatable, version-controlled scan definitions. The official Docker images are the standard CI integration; ZAP ships GitHub Actions and container images built for exactly this.

The complaints are real and you should know them going in. Active-scan false positives run high, especially on full scans, and an unfiltered full-scan report is mostly noise. Authentication is the historical number-one support burden: getting ZAP to log into a modern SPA with token or OIDC flows is genuinely painful, and worse, it fails quietly. The scan “passes” because it never actually authenticated and therefore never tested anything behind the login. Spider coverage on JavaScript-heavy applications is weak unless you turn on the AJAX spider or a browser-based crawl. And ZAP is a tool, not a managed platform, so triage, reporting, and baseline management land on you. Large targets want JVM memory tuning or the scan thrashes.

For gating and ticketing, ZAP exports SARIF, JSON, and HTML, which is enough to feed a pipeline gate or open tickets. What it will not do is talk to eMASS. DAST output reaches eMASS only after a human triages it into a POA&M, which is a meaningful difference from host-scan tools whose findings flow more directly. The pitfalls cluster predictably: running a full active scan against production or a shared environment (don’t, the active payloads are real), unbounded scan time blocking the pipeline, and auth-config drift silently breaking authenticated scans so the gate goes green on an empty test.

Which leads to the second contestable position, and I’ll mark it as one: a raw ZAP active-scan report is triage input, not an audit-ready artifact. Hand an assessor an unfiltered full-scan output and the false-positive volume undermines the finding rather than supporting it. The value is in the filtered result after you’ve tuned context and alert filters down to what’s real. If your pipeline gate fires on the unfiltered baseline, the team learns to ignore it, and an ignored gate is worse than no gate.

Sources

Adjacent material on this site