Zed Attack Proxy (ZAP)

The N-1 version of the product is supported but users are strongly encouraged to stay on the Nth version as we are a very small team. Upgrade instructions shouldn't be necessary but are provided in our documentation.

GitHub issue tracker https://github.com/zaproxy/zaproxy/issues

Where agreed with the reporter vulnerabilities identification/resolution is attributed. Per blog posts, release notes, and our BugCrowd use. https://www.zaproxy.org

Documentent on https://github.com/zaproxy/zaproxy#-owasp-zap with a link to the ZAP bug bounty program https://bugcrowd.com/owaspzap

A style is preferred and enforced.facilitated by the build processes/tooling. https://www.zaproxy.org/docs/developer/

A style is preferred and enforced.facilitated by the build processes/tooling. https://www.zaproxy.org/docs/developer/

Java builds

Java builds

There are no sub-directories for cross-dependencies

https://github.com/zaproxy/zaproxy

The Windows version comes with a standard installer and uninstaller, the OSX version is packages as an OSX app and the linux / cross platform versions are just tar / zip

Users are able to specify a destination directory using the standard installers

The software is easily installable, both with the normal binary installer and packages that can be unzipped. Additionally it is easy to setup a build environment and run the software from source.

External dependencies are listed and maintained as part of the Gradle build (including tasks/plugins for identification of out-dated dependencies). https://github.com/zaproxy/zaproxy (Additionally the team is considering production of a SBOM for ZAP.)

The team does periodically check whether external dependencies require upgrade for security or any reason. https://github.com/zaproxy/zaproxy/pulls https://github.com/zaproxy/zap-extensions/pulls

External dependencies are listed and maintained as part of the Gradle build (including tasks/plugins for identification of out-dated dependencies). The team does periodically check whether external dependencies require upgrade for security or any reason. https://github.com/zaproxy/zaproxy/pulls https://github.com/zaproxy/zap-extensions/pulls

As outlined above the project team does make significant efforts to ensure dependencies and functionality are kept up-to-date.

Tests are run as part of our CI builds (both for commits and PRs). https://github.com/zaproxy/zaproxy

The majority of new contributions include new or updated unit tests,

Due to the multi-platform nature of zap and it's storied history, this is very hard to reach. The majority of new contributions include new or updated unit tests.

https://www.zaproxy.org/docs/developer/dev-rules-and-guidelines/

Included in https://www.zaproxy.org/docs/developer/dev-rules-and-guidelines/ : "Where possible all developments should include regression tests. There are not enough at the moment, and we need to change that."

The -Xlint and -Werror options ensures the build task fails if any warnings occur

ZAP's options all have safe defaults, it also implements a "Mode" which the user can leverage to further protect themselves and their targets. In some cases due to the simple nature of the project unsafe TLS/SSL ciphers may be allowed/used, etc.

Where applicable the user is able to select their desired support for TLS protocol version etc.

Where applicable the end user can choose to use whatever type of credential they may need. However, ZAP itself does not require the use of any specific credential etc.

Where applicable the user is able to select their desired support for TLS protocol version etc. (As of the current update this means support for TLS 1.3, and whatever hashing algorithms are supported by the JRE in use.)

ZAP needs to connect to any website it needs to test, so it supports TLS 1, 1.1, 1.2, and 1.3. Users can enable and disable each, and their use depends on the support of the given JVM.

As ZAP is a MitM there are circumstances where this is true and where it is false, however the documentation should make said situations clear.

As ZAP is a MitM there are circumstances where this is true and where it is false, however the documentation should make said situations clear.

https://github.com/zaproxy/zaproxy/releases/tag/v2.11.0

The idea behind these tools is to get input from external source and use to offer a functionality. They can normally not be white nor blacklisted. It's data we use.

There is a Bug Bounty program which covers ZAP itself and the primary web site. Regular SAST assessments are conducted against the code base. https://sonarcloud.io/organizations/zaproxy/projects

https://www.zaproxy.org/faq/what-is-zaps-assurance-case/

https://sonarcloud.io/organizations/zaproxy/projects

ZAP is written in Java, so this is N/A.