# ZAP by Checkmarx: the core repository behind the world's most widely used web app scanner

> The zaproxy/zaproxy repository holds the Java core of the Zed Attack Proxy, a free DAST scanner for automated and manual web app testing. It is a strong default for teams that want a scriptable scanner they can run headless, and a poor fit for anyone expecting a one-click audit.

**zaproxy/zaproxy** — The ZAP by Checkmarx Core project

- Repository: https://github.com/zaproxy/zaproxy
- Website: https://www.zaproxy.org
- Stars: 15,850 · Forks: 2,653
- Language: Java
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/zaproxy-zaproxy

## What ZAP by Checkmarx actually is, and who the core repository is for

The Zed Attack Proxy (ZAP) by Checkmarx is a web application security scanner. The README describes it as "the world's most widely used web app scanner", free and open source, and a community project that anyone can contribute to. Its stated job is to help you automatically find security vulnerabilities in your web applications while you are developing and testing them. The README also names a second audience: experienced pentesters who use it for manual security testing.

That dual purpose explains a lot about the repository. This is the core project, written in Java, licensed Apache-2.0, and published under the zaproxy organisation with the homepage at zaproxy.org. If you are evaluating ZAP as a tool, the practical question is not what the scanner does in the abstract but which of those two modes you need. A pipeline that wants a pass or fail gate is asking for the automated side. A tester who wants to intercept, replay and tamper with requests is asking for the manual side. The same application serves both, which is why the repository is large and why the documentation matters more than the README.

The README itself is short. It carries badges, a download link and a pointer to the website. Anyone deciding whether to adopt ZAP will get almost nothing from the README alone, and should treat zaproxy.org as the real entry point.

## How the Java core, the CLI and the container packaging fit together

ZAP is a proxy. That is the mechanism behind everything else. Traffic routed through it is inspected, and the scanner's rules act on what passes through. The repository layout reflects a Java application built with Gradle: build.gradle.kts, settings.gradle.kts, gradlew and a buildSrc directory sit at the top level, alongside zap/, docker/, snap/, python/, docs/ and examples/.

The zap/ directory is the application itself. docker/ holds the container packaging, and snap/ holds the Snap packaging, which is how the tool reaches Linux distributions that prefer snaps. python/ is a Python client for the API, which matters because the API is the mechanism for driving ZAP from scripts and CI rather than from the desktop UI. The examples/ directory contains sample reports in merged and unmerged HTML and XML form, which tells you the scanner emits machine-readable output suitable for archiving or parsing.

The release cadence visible in the repository is weekly, with tags in the wYYYY-MM-DD form. The most recent listed releases are w2026-09-15, w2026-09-08 and w2026-09-03, and the last push to the default branch was on 2026-09-18. That cadence is a real cost consideration: pinning a version is easy, but the stream of weekly builds means you should decide deliberately whether your pipeline follows the weekly tags or freezes on one.

## Installing zaproxy and running a first scan

The README does not contain install instructions. It links to the download page at zaproxy.org/download, and that is where the project says to get it. What the repository does show is the packaging: a docker/ directory, a snap/ directory, and a Gradle build for building from source. The repository does not publish the exact container command or image tag, so the download page and the docker/ directory are what you should read before writing a pipeline step.

What the repository does give you is the build path. From a checkout, the Gradle wrapper at the top level is the entry point for building the Java core:

```bash
./gradlew build
```

BUILDING.md at the top level documents the build, so read it before running anything, since the wrapper assumes a JDK is already installed. Expect a Gradle build of the zap/ module and its dependencies, not a packaged installer.

For the packaged distributions, the snap/ directory indicates a Snap package is published, which is the install route on Linux distributions that use snaps and keeps updates automatic. The docker/ directory is the container packaging that lets the scanner run without a desktop. The README does not document the image name, the tag scheme or the command line for either, so treat the download page as authoritative for those values rather than guessing them.

If you want to drive ZAP from a script instead of the desktop interface, the python/ directory in the repository is the Python client for the API. The README does not document the client's constructor arguments or an API key, so read the files under python/ before writing code against it. The examples/ directory is the other useful reference: it holds sample reports in merged and unmerged HTML and XML form, which is what the scanner's output looks like when you need to parse or archive it.

## Where ZAP is the wrong tool

ZAP is a DAST scanner. It tests a running application from the outside by sending requests. It does not read your source, it does not inspect dependencies, and it cannot tell you that a library version is vulnerable unless the running application exposes something that reveals it. If your problem is a known CVE in a transitive dependency, a scanner of this kind is the wrong instrument.

The second limitation is authentication. Most interesting applications sit behind a login, and a scanner that cannot get past it sees only the public surface. Configuring ZAP to authenticate, maintain a session and stay logged in is real work, and the README says nothing about it. Teams that skip this step get a clean report that means very little.

The third is the gap between a finding and a decision. The scanner produces alerts with risk levels. It does not know your threat model, your compensating controls or which endpoints are reachable by an attacker. Anyone expecting the tool to output a definitive list of things to fix will be disappointed, and the README's own framing, that ZAP helps you find vulnerabilities while developing and testing, sets that expectation honestly.

Finally, there is the operational cost of running active scans. A full scan sends attack traffic. Pointing it at production without agreement is a way to generate incidents, and the repository gives no guardrails against that.

## ZAP and Burp Suite: two different centres of gravity

The comparison people search for is ZAP versus Burp Suite, and the honest answer is that they are built around different assumptions. Burp's commercial editions centre on the interactive testing workflow, with the proxy and repeater as the primary surface and automation as an add-on. ZAP's centre of gravity is the opposite: the API and the scripting path are first-class, the container packaging exists so the scanner can run unattended, and the manual testing interface is built on top of a tool that is already scriptable.

That difference shows up in licensing too. ZAP is Apache-2.0, so the whole scanner is available to embed in a pipeline without a per-seat question. Burp's commercial editions are not. If your constraint is running a scanner on every pull request across a large team, that licensing shape is the deciding factor, not a feature checklist.

The trade-off runs the other way as well. A tool designed for interactive testing tends to be more comfortable for a human exploring an application by hand, and the workflow around manual testing is where ZAP's dual nature can feel like two products sharing one window. Neither is strictly better; pick the one whose centre matches how you will actually use it.

## Licence, maintenance and the cost of weekly releases

The repository is licensed Apache-2.0, and the LICENSE and LEGALNOTICE.md files sit at the top level along with CLA.md for contributors. Apache-2.0 permits commercial use and modification and includes a patent grant; it also requires that you preserve notices. That is a permissive arrangement, and it is the reason ZAP can be bundled into commercial pipelines. This is a description of the licence terms, not legal advice, and if you are redistributing ZAP inside a product you should read the actual licence text rather than a summary.

The last push to the default branch was on 2026-09-18, three days before this article, and the release tags run weekly. That is a fast-moving project. The upgrade cost is not in the version bump itself; it is in the scanner's output. New and changed rules alter which alerts fire, so a pipeline that gates on alert counts will see its gate move when it upgrades. Pinning a specific release tag and reading the release notes before moving is the practical mitigation, and the repository's RELEASING.md documents the project's own release process if you want to understand what a tag contains.

There is also a contribution path. CONTRIBUTING.md and the hacktoberfest topic indicate an open project that takes outside patches, and the python/ client means you can extend behaviour without touching the Java core.

## Conclusion

Adopt ZAP if you want a free, Apache-2.0 licensed DAST scanner you can drive from the command line or a container in CI, and if you are willing to read the documentation to configure authentication and scanning policy. Do not adopt it expecting an unattended audit tool that finds everything: the README describes it as an aid for finding vulnerabilities while you develop and test, and manual testing by experienced pentesters is an explicitly supported use. Before committing, verify the install path for your platform on the download page, confirm which release tag your pipeline will pin, and check how your target's login flow is handled, because that is the part the README leaves to you.

## FAQ

### What is ZAP by Checkmarx used for?

It is a web application security scanner that helps you automatically find vulnerabilities in web applications while you develop and test them. The README also presents it as a tool for experienced pentesters doing manual security testing.

### Is ZAP proxy free?

Yes. The README describes it as free and open source, and the repository is licensed Apache-2.0.

### How do I install zaproxy?

The README does not give install steps; it points to the download page at zaproxy.org/download. The repository also shows a docker/ directory and a snap/ directory, which are the container and Snap packaging routes.

### How do I use zaproxy in Kali Linux?

The README does not document a Kali-specific install path. It directs users to the download page, and the repository contains Docker and Snap packaging that would work on a Linux system.

### Is zaproxy safe?

The repository is licensed Apache-2.0 and is published openly under the zaproxy organisation with a documented security policy in SECURITY.md. The README makes no further claim about the safety of the software itself.

## Sources

- [License: Apache-2.0](https://github.com/zaproxy/zaproxy/blob/main/LICENSE)
- [Project website](https://www.zaproxy.org)
- [README](https://github.com/zaproxy/zaproxy/blob/main/README.md)
- [Releases](https://github.com/zaproxy/zaproxy/releases)
- [zaproxy/zaproxy on GitHub](https://github.com/zaproxy/zaproxy)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zaproxy-zaproxy