Keeping open source software secure is a community responsibility. But with millions of projects, it’s hard to pinpoint the right signal from noise—and find and fix the vulnerabilities that really matter. Over the next few weeks, we’re sharing stories from open source maintainers on what it takes to secure the world’s software. First up: a Q&A with OWASP ZAP.
Simon Bennetts is the OWASP Zed Attack Proxy (ZAP) Project Leader and a Distinguished Engineer at StackHawk, a company that uses ZAP to help users fix application security bugs before they hit production. Prior to making the move into security, he was a developer for 25 years and strongly believes that you can’t build secure web applications without knowing how to attack them.
OWASP ZAP is a dynamic application security testing (DAST) tool for finding vulnerabilities in web applications. Like all OWASP projects, it’s completely free and open source—and we believe it’s the world’s most popular web application scanner.
The easiest way to get started with OWASP ZAP is by using one of two GitHub actions:
You can also check out https://www.zaproxy.org for even more information about ZAP.
ZAP can help you find security vulnerabilities in your web applications in test or production environments. It’s easy to automate, so you can use it to scan for security issues in your CI/CD pipeline. You don’t have to wait until your app is deployed before running a security scan on it—test it with ZAP as soon as you have something that runs. ZAP can run via GitHub Actions or packaged scans in Docker images. It also provides a desktop UI and an innovative Heads Up Display (HUD) so you can use ZAP manually as a way to learn more about security.
Dependency management can be painful—we have a large number of repositories and although we try to keep the number of dependencies down, we still have a significant number of them. Making sure that they are all up to date so that they aren’t introducing vulnerabilities is time consuming. Manual code reviews also take time. As ZAP is a security tool, it’s key to ensure that it stays secure as well as ensuring the changes are functionally correct.
Many developers have had little to no security training and therefore have limited security knowledge. Although there are in theory “many eyes” looking at open source, the reality is that most open source code is not checked by people with security experience.
Although there are in theory “many eyes” looking at open source, the reality is that most open source code is not checked by people with security experience.
OWASP ZAP is solving dynamic application security testing. Can you tell us why this is an important security issue for the developer community?
Dynamic application security testing (DAST) is a highly effective way to find certain types of vulnerabilities, like cross site scripting (XSS) and SQL injection (SQLi). However many of the commercial DAST tools are expensive to use and often only used when a project is getting ready to ship, if they are used at all. ZAP can be integrated into a project’s CI/CD pipeline from the start, ensuring that many common vulnerabilities are detected and can be fixed very early on in the project lifecycle. Testing in development also means that you can avoid the need to handle tools and features designed to make automation difficult, like single sign-on (SSO) and web application firewalls (WAFs).
What advice would you give developers on how to best improve the security of their open source projects?
For web applications, or any projects that provide a web based interface, you can use ZAP or another DAST tool. But don’t forget to use static application security testing (SAST) tools as well. These are particularly useful if they are introduced when starting a project. If SAST tools are used against more mature projects then they often flag a large number of potential issues, which makes it difficult to focus on the most critical ones. Finally, avoid falling into the trap of thinking that you should use one or the other: SAST and DAST are complementary methods that help you get a full understanding of your project’s security status.
We use GitHub branch protection rules to make sure that all pull requests get reviewed by the right people. All pull requests have to pass CodeQL static code scanning checks, which provide good feedback to the developers and makes the reviewers’ jobs that little bit easier. Code scanning with CodeQL has also really helped us improve the code quality of our older code.
We rely on Dependabot to tell us when dependencies need updating. It significantly reduces the pain of dependency management.
The ZAP core team are all experienced security developers. All pull requests must be approved by at least two of the ZAP core team and pass CodeQL checks without any failures. Two-factor authentication (2FA) is required for all members of the zaproxy organization. We also have a bug bounty program which will pay out $1,000 for any remote code execution vulnerabilities in ZAP.
Want to learn more about open source security? Check back in soon—we’ll be diving into open source security projects and sharing security best practices from open source maintainers over the next few weeks.