Security Testing Tools — OWASP ZAP, Burp Suite, SonarQube

Security testing tools fall into two broad categories: those that test the running application (dynamic analysis) and those that analyse the source code (static analysis). A mature security testing practice uses both — neither alone gives complete coverage. This lesson maps the main tools QA engineers work with, what each does well, and where to start.

The tool landscape

OWASP ZAP — the QA engineer's starting point

OWASP ZAP (Zed Attack Proxy) is the best free tool for QA engineers getting into security testing. It operates as a proxy between your browser and the application, allowing it to both observe and modify traffic.

Automated scan mode is the simplest entry point: point ZAP at a URL, and it crawls the application and fires automated tests for common vulnerabilities — XSS, SQL injection, security misconfigurations, missing headers. The automated scan is not exhaustive (no automated tool is), but it catches a meaningful number of real issues quickly.

Proxy mode is more powerful: configure your browser to route traffic through ZAP and browse the application manually. ZAP records every request and response. You can then inspect, modify, and replay them — adding malicious payloads to parameters to test manually for vulnerabilities the scanner missed.

CI/CD integration is where ZAP becomes a continuous security layer. The ZAP Docker image and API allow you to run baseline scans against a staging environment on every deployment. Any critical findings can fail the pipeline, giving security the same gate as unit tests.

ZAP's limitation is depth: it is not as powerful as Burp Professional for complex, multi-step attacks, and its scanner produces false positives that require manual review. For a QA team without dedicated security engineers, ZAP is the right starting point precisely because it balances power with accessibility.

Burp Suite — the professional standard

Burp Suite from PortSwigger is the industry-standard tool for security professionals. Its proxy intercepts and modifies every request passing through it, and its Repeater tool allows you to re-send modified requests with a single click — the primary workflow for manual vulnerability testing.

The Community Edition is free but limited to manual proxy use. No scanner, no active attack automation. It is still useful for intercepting requests and testing specific endpoints manually.

Burp Professional ($475/year for individuals) adds the vulnerability scanner, the Intruder tool (for automated payload fuzzing), and hundreds of extensions from the BApp store. For QA engineers who want to develop serious security testing skills, Burp Pro is the standard investment.

If you encounter Burp in your career: the Proxy → Intercept → Repeater workflow is the core loop. Intercept a request, send it to Repeater, modify parameters, observe the response. That workflow, repeated across the OWASP Top 10 checklist, is the foundation of manual security testing.

SonarQube — finding bugs before they deploy

SonarQube differs from the previous tools: it analyses source code statically without running the application. It detects patterns in the code that correspond to known vulnerability types — SQL query construction using string concatenation, unsanitised output in templates, hardcoded credentials, use of weak cryptographic algorithms.

Because it runs against code (not a deployed application), SonarQube can be integrated into the build pipeline and configured to block merges that introduce critical security findings. This shifts security left — catching bugs at the point they are written rather than after deployment.

SonarQube covers OWASP A03 (Injection), A02 (Cryptographic Failures), A05 (Misconfiguration), and parts of A07 (Auth Failures) at the code level. It does not replace dynamic testing — it cannot find runtime vulnerabilities like IDOR or CSRF that depend on application behaviour under load. The combination of SonarQube in CI and ZAP in staging covers both dimensions.

Dependency scanning — Snyk and Dependabot

Vulnerable and outdated components (OWASP A06) is the category where QA engineers have historically had the least visibility. Your application is only as secure as the libraries it depends on — and popular libraries regularly have CVEs discovered after your project adopted them.

Snyk and GitHub's Dependabot monitor your dependency tree and alert you when a library you use has a known vulnerability. Both can be configured to open pull requests that update affected dependencies automatically. If your project is hosted on GitHub, Dependabot is free and takes less than five minutes to enable.

How these tools fit a QA engineer's workflow

The right security testing stack for most QA teams looks like this:

1. SonarQube or Semgrep in CI — blocks critical security findings from merging
2. Dependabot or Snyk in the repository — alerts on vulnerable dependencies
3. OWASP ZAP baseline scan in staging — automated dynamic testing on every deployment
4. Manual testing with ZAP proxy or Burp Community — targeted testing against OWASP Top 10 categories

Penetration testing by specialist security engineers (with Burp Professional and custom tooling) is a separate layer that most organisations run periodically — typically annually or before major releases. QA owns the ongoing automated layer; security specialists own the deep periodic audits.

⚠️ Common mistakes

• Running only automated scans and trusting the results. ZAP and Burp's scanner find real vulnerabilities — but they also produce false positives, and they miss entire categories (IDOR, CSRF, business logic flaws) that require manual testing. Automated scans are a starting point, not a complete programme.
• Not scanning dependencies. Ignoring OWASP A06 because "we didn't write that code" misses one of the most common vulnerability categories. Dependencies are your code's attack surface.
• Scanning production environments. Active security scans send malicious payloads to the target — they can cause service disruption, fill databases with garbage data, or trigger rate limiting. Always scan staging or dedicated test environments, never production.

🎯 Practice task

Set up a basic security testing pipeline on any web application you have legitimate access to test.

1. Download OWASP ZAP and run an automated scan against a staging environment (not production). Note the categories of findings — are any Critical or High?
2. Switch to proxy mode and browse the application manually. Use ZAP's History tab to see what requests were captured.
3. If your project uses GitHub, enable Dependabot security alerts. Check whether any current dependencies have known vulnerabilities.

The goal is to run these tools for the first time in a safe environment and see what they find. The findings are less important than the experience of having a security tool integrated into your testing workflow.