The three previous tools — Top Ten, ASVS, and SAMM — are documents and frameworks: they tell you what to look at, what to verify, and how to mature, but none of them attacks the application for you. In the SAMM self-assessment, BazarNube discovered its most urgent gap: the security testing (Verification) practice was at level 0, because they weren't actively testing their own application. Marc sums it up well: "We have gorgeous checklists, but no one has really tried to break the API". They need an executable tool that hits the running application and tells them what it finds. That is the fourth piece in the box: OWASP ZAP, the Zed Attack Proxy. In this lesson we present it; its installation and detailed use are the content of module 6.

1. What ZAP is
2. What kind of testing it does: DAST (dynamic testing)
3. ZAP versus SAST and SCA: where each one fits
4. ZAP use cases
5. How BazarNube would test its API with ZAP

OWASP ZAP (Zed Attack Proxy) is an open-source, free tool for finding vulnerabilities in running web applications. It is one of OWASP's flagship projects and one of the most widely used security tools in the world. It has two souls that are worth distinguishing from the start:

• An interception proxy. ZAP sits between the browser and the application, so that all HTTP/HTTPS traffic passes through it. This lets it see, pause, and modify requests and responses on the fly. It's like placing a "camera with a remote control" in the middle of the conversation between client and server.
• A DAST scanner. On top of that traffic, ZAP can launch automated tests that look for known vulnerabilities (injections, XSS, missing headers, etc.).

Being free software with a huge community, it is a natural choice for a startup like BazarNube: zero license cost and the ability to integrate into its pipeline.

ZAP performs DAST (Dynamic Application Security Testing). The key word is dynamic: ZAP tests the application while it is running, attacking it from the outside, just as a real attacker would. It doesn't need to see the source code.

How it works, broadly (the detail is in module 6):

1. Explore (spider/crawl). ZAP walks the application to discover its URLs, forms, and endpoints.
2. Attack (active scan). On what it has discovered, it sends manipulated requests (payloads) to see whether the application reacts insecurely.
3. Observe and report. It analyzes the responses and generates a report with the vulnerabilities found, their severity, and evidence.

The great advantage of the dynamic approach: it finds flaws as they manifest in real execution, including server configuration problems that a code analysis would never see. Its limit: it only sees what it can reach from the outside; if an endpoint isn't discovered, it isn't tested.

ZAP doesn't replace other security tools: it complements them. To avoid confusing them, it helps to situate the three big families of automated analysis. Here we present them at a high level; we go deeper into combining them in lesson 02-05 and in module 7.

The essential idea: no single tool sees everything. SAST sees the code but not the real behavior; SCA sees the dependencies but not your logic; DAST (ZAP) sees the real behavior but not the internal code. A mature strategy combines them. For the Verification gap that SAMM detected at BazarNube, ZAP (DAST) is the most natural entry point, because it tests the application as it is deployed, without needing to instrument the code.

ZAP is versatile. Its most common uses, from least to most sophisticated:

• Assisted manual exploration. Browse the application with ZAP as a proxy to inspect and manipulate requests by hand (ideal for understanding how it works and testing hypotheses).
• One-off automated scan. Launch an active scan against the application before a release to get a quick vulnerability report.
• API testing. Feed ZAP the API definition (for example, an OpenAPI specification) so that it tests its endpoints systematically. Very relevant for BazarNube, whose logic lives in an API.
• CI/CD integration (DevSecOps). Run ZAP automatically in the pipeline on every deployment, so that a new flaw breaks the build. This connects with module 7.

Let's apply it to the case. BazarNube's business logic lives in its Node.js/Express API, with a legacy Java module behind it. ZAP is ideal for testing it. The flow the team would follow (detailed in module 6) would be:

1. Bring up the environment. BazarNube runs in Docker containers, so the SRE deploys a copy of the API in a test environment (never against production without control).
2. Give ZAP the map of the API. Since the API is documented with OpenAPI, that definition is passed to it so it knows all the endpoints (/api/login, /api/orders/:id, /api/search, etc.).
3. Launch the scan. ZAP explores and attacks each endpoint with test payloads.

By way of illustration, this is what a report excerpt from ZAP on BazarNube's API would look like (simplified format; the real tool and its output are covered in module 6):

Notice the power of this and how it closes the loop with the previous tools:

• Each ZAP finding is dumped into the backlog and labeled with its Top Ten category (A03, A05, A01), the vocabulary we fixed in 02-01.
• Each finding can be cross-checked against the ASVS checklist from 02-02: the IDOR confirms that the access control requirement really was unmet, not just a suspicion.
• The simple act of running ZAP regularly raises SAMM's Verification practice (02-03) from level 0 to level 1.

So ZAP is not an isolated tool: it is the active detection engine that feeds real evidence into the entire system (Top Ten + ASVS + SAMM) that BazarNube has been assembling.

• Scanning production without permission or control. ZAP really attacks: an active scan can create junk data, trigger actions, or degrade the service. Run it against test environments or with authorization and a controlled window.
• Believing ZAP finds "everything". DAST only sees what's reachable from the outside and what it knows how to recognize. It doesn't detect deep business-logic flaws, nor does it replace SAST/SCA or human review.
• Scanning only the web surface and forgetting the API. In modern apps like BazarNube, the logic is in the API. You have to give ZAP the API definition (OpenAPI) so it covers it; otherwise, only a fraction gets tested.
• Running it once and filing the report. The value is in repetition: integrating it into the pipeline to catch regressions. A one-off scan ages in days.
• Tip: start with a manual/exploratory scan to understand the app before automating. Understanding the traffic with the proxy teaches you more about your own application than you'd imagine.

Exercise 1. Classify each tool as SAST, DAST, or SCA: (a) it analyzes the Java code of the billing module looking for insecure patterns without running it; (b) it reviews the API's package.json looking for libraries with known CVEs; (c) it attacks /api/search with payloads while the application is running.

Exercise 2. The SRE proposes adding ZAP to the CI/CD pipeline so that it runs on every deployment to staging. Explain in 3–4 lines which SAMM practice this improves and why it is preferable to a sporadic manual scan.

Exercise 3. A colleague says: "With ZAP we no longer need ASVS or code reviews, because ZAP finds the vulnerabilities". Rebut this claim with two arguments.

Solution 1. (a) SAST (static analysis of the source code, without running it); (b) SCA (composition analysis: third-party dependencies and their known vulnerabilities); (c) DAST (dynamic analysis of the running application; this is what ZAP does).

Solution 2. It improves the security testing practice of SAMM's Verification domain, and it also helps secure deployment (Implementation/DevSecOps). It is preferable to the sporadic scan because it makes it systematic and repeatable: every release is tested automatically, regressions are detected immediately, and the practice rises in maturity level (from "ad hoc" to "defined"), instead of depending on someone remembering to launch it.

Solution 3. (1) ZAP is DAST: it only sees what's reachable from the outside and what it knows how to recognize; it does not detect many business-logic flaws, nor problems in non-exposed code, nor vulnerable components (that's SCA). (2) ASVS and code reviews serve a different, complementary function: verifying requirements and reasoning about the design and the internal code, things a dynamic scanner doesn't do. Mature security combines SAST, DAST, SCA, and manual verification; no single tool replaces them all.

You have met the fourth tool in the OWASP box: ZAP, an open-source interception proxy and DAST scanner that tests the application at runtime, from the outside, like a real attacker. You know how to situate it against SAST (code) and SCA (dependencies) — they complement, not replace, each other — and you have seen its use cases, from manual exploration to CI/CD integration. And, above all, you have seen how BazarNube would test its API with ZAP and how each finding closes the loop: it's labeled with the Top Ten, cross-checked against ASVS, and matures its SAMM.

With ZAP we complete the four flagship projects that structure this course (Top Ten, ASVS, SAMM, ZAP), each with its own dedicated module later on. But OWASP's toolbox has much more to offer: testing guides, remediation cheat sheets, dependency scanners, and applications to practice on. In lesson 02-05, the last of the module, we present those other key projects that BazarNube will combine with the four big ones to have a complete strategy.