From OWASP ZAP to ZAP: The Complete Evolution, History and Milestones of the Zed Attack Proxy

Last updated: 26 July 2026

For more than fifteen years, ZAP has helped developers, security engineers, quality-assurance teams and penetration testers discover vulnerabilities in web applications. Many people still know the tool as OWASP ZAP, while others call it the OWASP Zed Attack Proxy.

Those names are now historical.

The project’s current name is simply ZAP, while ZAP by Checkmarx is the supported project branding commonly used on its website, GitHub repository and documentation. ZAP is no longer an OWASP project, although its long association with OWASP remains an important part of its history.

The change was not merely a cosmetic rebrand. It marked a major transition in ZAP’s governance, funding and ability to support full-time development. At the same time, the principles that made ZAP successful remained intact: it is still free, open source, community-driven and licensed under Apache License 2.0.

This is the complete story of how a personal fork of an older proxy tool became OWASP ZAP, grew into one of the world’s most widely used web application scanners, left OWASP and entered its current era as ZAP by Checkmarx.

What is ZAP?

ZAP stands for Zed Attack Proxy. It is a free and open-source web application security testing platform designed to help users find security vulnerabilities in web applications and APIs.

At its foundation, ZAP operates as a manipulator-in-the-middle proxy. It can sit between a browser or another client and the target application, allowing the tester to inspect, intercept, modify and analyse HTTP and HTTPS traffic.

However, modern ZAP is far more than a simple proxy. It provides capabilities for:

• Passive vulnerability scanning
• Active vulnerability scanning
• Traditional and browser-based application crawling
• API security testing
• Authentication and session testing
• Request interception and modification
• WebSocket analysis
• Fuzzing
• Access-control testing
• Security automation
• CI/CD integration
• Extensible scan rules and add-ons
• Scripting and custom testing workflows
• OpenAPI, GraphQL, SOAP, Postman and gRPC-related testing
• Out-of-band application security testing
• AI-assisted security workflows through emerging integrations

The official project describes ZAP as a free, open-source and community-based web application scanner suitable both for people beginning their security-testing journey and experienced penetration testers conducting advanced manual assessments.

The origin of ZAP: the Paros Proxy era

The story of ZAP begins before the first ZAP release.

In 2009, developer Simon Bennetts was looking for a free, open-source and cross-platform security tool that could be recommended not only to professional penetration testers but also to developers and testers who were relatively new to application security.

One of the tools he found most useful was Paros Proxy, a Java-based web proxy that provided a practical foundation for examining and testing web traffic. Paros was simple and effective, but its development had slowed and it did not have the active community that Bennetts wanted from an open-source project.

Because Paros was written in Java, Bennetts began modifying its source code, initially to improve his own understanding of web security. He later decided to fork it and release a new community-focused project. The early work included rebranding, documentation improvements, usability changes and the foundation for much broader development.

This is why remnants of the original Paros architecture and package naming continued to appear inside the ZAP codebase for many years. ZAP did not appear from nowhere; it evolved from an existing security proxy and gradually replaced or modernised its inherited components.

2010: ZAP 1.0.0 is released

The first public version of the Zed Attack Proxy, ZAP 1.0.0, was announced on 6 September 2010.

The initial release was modest compared with today’s platform, but its philosophy was ambitious. The goal was to create a security testing tool that was:

• Free to use
• Open source
• Cross-platform
• Accessible to developers and testers
• Useful to professional penetration testers
• Built around a welcoming contributor community

Simon Bennetts later explained that he released ZAP partly because he could not find the kind of active, community-based open-source security project that he wanted to join. Instead, he created one.

That community-first decision became one of the most important factors in ZAP’s long-term success.

2010–2011: ZAP becomes an OWASP project

Soon after ZAP was launched, the project applied to join OWASP—the Open Worldwide Application Security Project, historically known as the Open Web Application Security Project.

ZAP was accepted, and version 1.1.0 became the first OWASP-branded release. This version introduced OWASP branding alongside capabilities such as brute-force directory discovery, port scanning, improved active-scan visibility, greater internationalisation and additional user-interface improvements.

This was the beginning of the name most security professionals came to recognise:

OWASP Zed Attack Proxy, commonly shortened to OWASP ZAP.

OWASP gave the young project significant visibility. OWASP conferences, local chapters, training programmes and community events helped ZAP reach security professionals around the world. The OWASP identity also gave users confidence that ZAP was part of a respected, nonprofit application-security ecosystem.

For more than a decade, the association benefited both sides. OWASP gained an increasingly capable open-source security tool, while ZAP gained exposure, contributors, users and an internationally recognised home.

2011–2012: APIs, fuzzing and internationalisation

The early 1.x releases transformed ZAP from a basic proxy fork into a broader application-security platform.

Version 1.3.0 introduced major capabilities including:

• A new API
• Integrated fuzzing
• Expanded internationalisation
• BeanShell integration

Version 1.4.0 continued this development with syntax highlighting, FuzzDB integration, an enhanced cross-site scripting scanner and more extensible components.

These releases established patterns that still define ZAP today.

First, ZAP would not be restricted to a graphical desktop interface. Its API would allow other tools, scripts and pipelines to control it.

Second, ZAP would become extensible. Users and contributors would be able to add functionality without waiting for every feature to be built directly into the core.

Third, ZAP would serve multiple audiences. Beginners could start with automated scanning, while experienced testers could use its proxy, scripting, fuzzing and manual testing tools.

2012–2013: ZAP 2.0 becomes a full security-testing platform

ZAP 2.0 was one of the most important milestones in the project’s history.

Work contributed through Google Summer of Code played a major role in this release. Students and project mentors helped deliver a rewritten traditional spider, an AJAX Spider based on Crawljax and Selenium, stronger session awareness and WebSocket support.

The final ZAP 2.0 generation added several foundational capabilities.

Integrated add-on marketplace

Users could browse, install, update and remove many ZAP extensions from within the application. Scan rules could be updated independently, enabling new vulnerability checks to reach users without requiring an entirely new core release.

Rewritten traditional spider

The original spider inherited from Paros was replaced with a faster and more comprehensive crawler for conventional HTML-based applications.

AJAX Spider

The AJAX Spider used a real browser to explore applications whose links and functionality were created dynamically through JavaScript.

WebSocket support

ZAP gained the ability to view, intercept, modify and fuzz WebSocket messages—an important capability as real-time web applications became more common.

Quick Start interface

A user could enter a target URL and begin an automated scan from a simplified starting screen. This made the platform far more approachable for developers and testers with limited security experience.

Contexts, sessions and operating modes

ZAP added stronger application scoping, authentication information, session management and operational modes such as Safe, Protected and Standard. These features helped users avoid accidentally attacking systems outside the authorised testing scope.

Expanded API support

The REST API was extended substantially, making ZAP better suited to automated security regression testing and integration with external systems.

ZAP 2.0 marked the point where the project clearly became much more than a proxy. It was now an extensible web application security testing framework.

The rise of scripting, Zest and browser integration

The next phase of ZAP’s evolution centred on customisation and automation.

The 2.2 generation introduced enhanced scripting, Zest and Plug-n-Hack support. Zest provided a security-focused scripting language that could represent recorded interactions and reusable testing workflows.

Scripting allowed security teams to customise authentication, modify requests, define passive and active checks, process results and build workflows for applications that could not be tested effectively with generic scanning alone.

This extensibility became particularly valuable for organisations testing complex enterprise applications with custom login processes, session behaviour, nonstandard parameters and business-specific workflows.

It also reinforced one of ZAP’s central design ideas: the product should be useful out of the box without becoming a closed box.

2015: Attack Mode, scan policies and advanced fuzzing

Version 2.4.0 introduced another major group of capabilities.

Attack Mode enabled ZAP to automatically begin actively scanning in-scope nodes as they were discovered. Advanced fuzzing supported multiple injection points, scripted payload generation and pre- or post-processing of fuzzing requests and results.

The release also introduced stronger scan-policy management. Users could create different policies controlling which active rules were used, how aggressively those rules operated and the threshold at which findings were reported.

These improvements made ZAP better suited to several very different scenarios:

• A developer running a lightweight scan during development
• A CI pipeline enforcing a security baseline
• A QA team running repeatable regression testing
• A penetration tester performing aggressive, targeted testing
• A security team maintaining organisation-specific scan policies

The flexibility to change scan strength and rule selection remains essential because security scanning is rarely a one-size-fits-all activity.

From desktop tool to DevSecOps platform

As DevOps and continuous delivery became widespread, security testing increasingly needed to operate without a person manually controlling a desktop application.

ZAP responded by expanding its command-line interface, API, packaged scan scripts, container images and CI/CD integrations.

Over time, users could run ZAP as:

• A desktop penetration-testing tool
• A headless daemon
• A command-line scanner
• A containerised scanning service
• A CI/CD security gate
• A programmable component controlled through its API
• A reusable scanning engine embedded in other products and services

This evolution helped move dynamic application security testing earlier into the software delivery lifecycle. Instead of waiting for an occasional penetration test immediately before a production release, teams could perform repeatable scans against development, test and staging environments.

2020: ZAP celebrates ten years

On 6 September 2020, ZAP celebrated the tenth anniversary of its first public release.

By then, the project had grown from a Paros fork into a globally adopted security platform. Its maintainers highlighted several areas in which ZAP had introduced capabilities earlier than many better-funded commercial tools, including WebSocket testing, browser launching, browser-driven crawling and an online add-on marketplace.

The project also had mature API and scripting capabilities, Zest automation and the Heads Up Display, which brought security testing information directly into the browser.

Version 2.10.0 was designated as the ten-year anniversary release, reflecting the project’s progression from a small volunteer initiative to a major part of the application-security ecosystem.

2021: the Automation Framework changes how ZAP is operated

ZAP 2.11.0 introduced the Automation Framework, one of the most important developments in ZAP’s DevSecOps journey.

The framework provided a structured, declarative way to define ZAP automation plans. Instead of maintaining a collection of loosely connected command-line switches and scripts, users could describe environments, authentication settings, spiders, scans, reports and acceptance tests in a reusable plan.

The project expected the Automation Framework to become the preferred choice for most automation use cases. Plans could be run from the command line while also being created and tested through the desktop interface.

The framework made security testing easier to treat as code. Plans could be reviewed, version-controlled and executed consistently across developer machines and CI/CD environments.

2022: replacing the inherited networking foundation

Even after many years of development, parts of ZAP still relied on networking code inherited from Paros and an ageing version of Apache Commons HttpClient.

In February 2022, ZAP’s weekly and live releases began using a substantially redesigned networking stack. The networking functionality was moved out of the core into a dedicated add-on. Client-side communications used Netty, while server-side communications continued using HttpClient at that stage.

This was an enormous internal change even though the development team intended users to notice as little disruption as possible.

The new design created several long-term benefits:

• A modern, maintained networking foundation
• Easier delivery of networking fixes
• Reduced dependence on full core releases
• Better resource and performance potential
• A foundation for newer protocols and complex traffic-handling scenarios
• Continued separation of features from the monolithic core

This milestone symbolised ZAP gradually replacing the last major architectural elements inherited from its Paros origins.

Why OWASP ZAP left OWASP

By the early 2020s, ZAP had become a very large and widely used project competing in a market where commercial application-security vendors invested heavily in engineering, research and customer support.

Maintaining a project of that size through volunteer effort was increasingly difficult.

The ZAP team stated that OWASP had provided valuable exposure and community support, but had struggled to fund and invest sufficiently in large software projects. ZAP needed sustainable financing and more people working on it full-time.

On 1 August 2023, the team announced plans for ZAP to join the Software Security Project as a founding project. Because ZAP could belong to only one foundation, the announcement also marked its departure from OWASP.

The formal branding change was clear:

“OWASP ZAP” would become simply “ZAP.”

The transition was announced in August 2023, with official ownership information describing ZAP’s removal from OWASP in September 2023.

The move also required practical changes, including rebranding the user interface and website, moving container images away from OWASP-controlled accounts and migrating project services.

Did ZAP leave OWASP because of a technical disagreement?

No.

The departure was primarily about the project’s sustainability, funding and ability to employ people to maintain and improve it.

The ZAP team continued to describe OWASP as a positive force in application security. Team members remained involved in OWASP activities, including serving as leaders and volunteers for other projects.

The transition should therefore not be interpreted as a rejection of OWASP’s security standards, educational resources or community.

ZAP continues to work with OWASP-related material. Its scan rules and alerts can map to OWASP security categories, and in 2026 the project expanded its integration with OWASP Penetration Testing Kit findings.

The relationship changed organisationally, not philosophically.

2024: ZAP joins forces with Checkmarx

On 24 September 2024, the project announced that it had joined forces with Checkmarx.

Checkmarx agreed to employ the project’s three leaders—Simon Bennetts, Ricardo Pereira and Rick Mitchell—to work on ZAP and Checkmarx’s ZAP-based DAST technology. The project described this as the largest investment made by a single company in ZAP’s history.

The supported branding consequently became:

ZAP by Checkmarx

This partnership did not turn ZAP into a closed, proprietary product. The project stated that:

• ZAP would remain controlled by the ZAP Core Team.
• It would remain open source.
• It would continue using the Apache License 2.0.
• It would continue welcoming community contributions.
• Checkmarx would provide funding, full-time engineering and access to real-world enterprise feedback.

This distinction is crucial. Checkmarx supports ZAP and employs key maintainers, but the official ownership page describes ZAP as an independent open-source project controlled by its Core Team.

2024–2025: deeper CI/CD integration and modularisation

The post-OWASP period brought accelerated investment in automation and modular architecture.

ZAP 2.15.0 introduced an Automation Framework GitHub Action, enabling teams to execute structured ZAP plans directly within GitHub Actions workflows.

ZAP 2.16.0 continued the strategy of moving capabilities out of the core so that fixes and improvements could be delivered more quickly. The passive scanner was moved into an add-on, while sequence scanning received performance and automation improvements.

The same release introduced the new Client Spider, designed to explore modern browser-based applications more effectively.

The Client Spider was an important response to the architecture of modern applications. Single-page applications frequently build interfaces dynamically, communicate through APIs and expose functionality that cannot be discovered reliably by analysing static HTML alone.

2025: ZAP 2.17.0 improves scanning quality

ZAP 2.17.0 was released on 15 December 2025 and remains the latest stable core release as of 26 July 2026.

The release concentrated on stability, usability, performance and finding quality. One of its most notable improvements was a substantial reduction in duplicate alerts, helping users avoid reviewing multiple findings that represented the same underlying issue.

Reducing duplicate and noisy results is not glamorous, but it is extremely important in real-world application-security programmes. A scanner provides more value when developers and security teams can quickly identify distinct, actionable risks rather than spending hours sorting repetitive findings.

ZAP in 2026: browser-native testing, OWASP PTK and AI integration

ZAP’s 2026 development shows that the project is continuing to adapt to modern application architectures and AI-assisted engineering workflows.

OWASP PTK integration

ZAP added integration with the OWASP Penetration Testing Kit, allowing browser-native findings to appear as ZAP alerts. This extends visibility into client-side JavaScript behaviour and data flows that cannot always be observed effectively at the proxy layer alone.

By April 2026, the integration could expose 142 OWASP PTK-tagged alert types covering browser-based SAST, IAST and DAST findings. Later work introduced a dedicated active scan rule and promoted the integration towards beta status.

ZAP MCP integration

An alpha ZAP Model Context Protocol integration was announced in 2026. It allows compatible AI assistants to interact with ZAP—for example, requesting that ZAP crawl an application, begin a scan or retrieve alerts using a conversational interface.

This capability is still evolving and should not be confused with handing unrestricted control of production systems to an AI assistant. Testing scope, authorisation and safety controls remain essential.

Client Spider becomes the recommended modern crawler

In July 2026, the ZAP team recommended using the Client Spider instead of the AJAX Spider for modern web applications. The traditional spider is still recommended alongside it because each crawler may discover a different set of endpoints.

The AJAX Spider has not disappeared, but it is no longer the preferred option for exploring modern applications.

Continued rapid releases

Although 2.17.0 is the current stable core release, development has continued through frequently published add-on and weekly releases. GitHub listed a weekly pre-release dated 21 July 2026 at the time this article was updated.

ZAP’s growth as an open-source project

ZAP’s adoption has continued to grow after leaving OWASP.

In April 2026, project telemetry indicated that ZAP had been started nearly ten million times during the month. The main GitHub repository also crossed 15,000 stars.

The repository subsequently showed approximately 15,500 stars and 2,600 forks, demonstrating a large developer and security community around the project.

These numbers do not measure every form of usage, and they should not be interpreted as a count of unique organisations. They nevertheless provide strong evidence that the rebrand did not end ZAP’s growth or community relevance.

Major ZAP milestones at a glance

Is “OWASP ZAP” still a valid name?

Not for current documentation.

The official project explicitly states that ZAP has not been an OWASP project since 2023. Current references should use either:

• ZAP
• Zed Attack Proxy
• ZAP by Checkmarx

The term OWASP ZAP remains appropriate only when discussing the project historically—for example, “OWASP ZAP introduced the Automation Framework in version 2.11.0.”

Using “OWASP ZAP” to describe the current project may incorrectly suggest that OWASP still owns, governs or officially hosts it.

What should organisations update?

Teams that use ZAP should review internal material created before the 2023 transition.

Documentation may need updates in:

• Architecture diagrams
• Security standards
• CI/CD documentation
• Training courses
• Tool inventories
• Vendor questionnaires
• Risk registers
• Penetration-testing procedures
• Blog posts and tutorials
• Product comparison pages
• Job descriptions and résumés

Technical teams should also examine old container references and scripts. The 2023 transition involved moving container images and project services away from OWASP-managed accounts, so examples based on older OWASP image locations may no longer represent the recommended deployment method.

Historical records do not need to be rewritten. They should simply distinguish clearly between the former OWASP ZAP period and the current ZAP project.

What did not change after the rebrand?

The rebrand did not remove the qualities that made the project important.

ZAP remains:

• Free
• Open source
• Licensed under Apache License 2.0
• Controlled by the ZAP Core Team
• Open to community contributions
• Suitable for beginners and experienced security professionals
• Available for manual and automated testing
• Extensible through add-ons, APIs and scripts
• Actively maintained

Checkmarx’s support changed the project’s funding model and branding, but the official project position is that ZAP remains independent and community-focused.

What the evolution of ZAP teaches the open-source community

The history of ZAP is more than a product timeline. It demonstrates several realities of modern open-source security.

Community visibility can launch a project

OWASP’s reputation, conferences and chapters played a major role in helping ZAP reach a global audience.

Popularity does not automatically fund maintenance

A tool can be used by millions of people and still struggle to pay maintainers. Downloads, stars and goodwill do not by themselves provide sustainable engineering resources.

Commercial sponsorship does not always mean closed source

The Checkmarx partnership shows one model in which a company funds core maintainers while the project remains open source and controlled by its existing team.

Architecture must continually evolve

ZAP survived because it did not remain a slightly modified version of Paros. It rewrote crawlers, modernised networking, modularised features, expanded automation and adapted to APIs, JavaScript-heavy applications, CI/CD and AI-assisted workflows.

Names carry governance meaning

Removing “OWASP” from the name was not just a marketing decision. It clarified who currently governs and funds the project.

Frequently asked questions

What is the latest name of OWASP ZAP?

The current name is ZAP. The supported branding ZAP by Checkmarx is also correct.

Does OWASP still own ZAP?

No. ZAP is an independent open-source project controlled by the ZAP Core Team and supported by Checkmarx.

Is ZAP now a proprietary Checkmarx product?

No. ZAP remains open source under Apache License 2.0. Checkmarx employs key maintainers and supports its continued development.

Is Zed Attack Proxy still the expanded name?

Yes. The official project homepage continues to use Zed Attack Proxy (ZAP).

What is the latest stable ZAP version?

As of 26 July 2026, the latest stable core release is ZAP 2.17.0, released on 15 December 2025. More recent weekly pre-release builds and independently updated add-ons are also available.

Can ZAP be used in CI/CD pipelines?

Yes. ZAP supports APIs, command-line execution, containers, packaged scans, an Automation Framework and CI integrations such as GitHub Actions.

Is ZAP only an automated vulnerability scanner?

No. Automated scanning is only one part of ZAP. It also provides extensive tools for proxy-based inspection, manual testing, fuzzing, request modification, scripting, authentication testing and application exploration.

Is it safe to scan any website with ZAP?

No. Active scanning sends attack-style requests and should only be used against systems for which you have explicit authorisation. The project’s own getting-started documentation warns that active testing can affect application functionality and data.

Conclusion

The journey from Paros Proxy to ZAP, from OWASP ZAP to an independent project, and finally to ZAP by Checkmarx is one of the most significant open-source application-security stories of the past fifteen years.

ZAP began as one developer’s attempt to create the kind of welcoming, accessible security project he wanted to join. OWASP helped it gain global recognition. Students, volunteers, maintainers and corporate users expanded it into an extensible testing platform. DevSecOps adoption pushed it into automation and CI/CD. Funding pressures eventually required a new organisational model, leading to its departure from OWASP and partnership with Checkmarx.

The name has changed, but ZAP’s central mission has not: make powerful web application security testing available to everyone.

Today, the correct name is ZAP—or ZAP by Checkmarx—and the project is moving into a new phase built around modern browser testing, stronger automation, client-side security analysis and emerging AI integrations.

OWASP ZAP is an important historical name.

ZAP is the project’s present and future.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.