So far, the BazarNube team has adopted OWASP's four flagship projects: the Top Ten (which risks), ASVS (what to verify), SAMM (how to mature), and ZAP (how to test at runtime). But when reviewing the backlog, practical questions come up that those four don't fully resolve. "How do we test each endpoint manually and thoroughly?" (Marc). "When ZAP finds an XSS, where do I find the exact, well-explained fix?" (Lucía). "And who warns us that a library we use has a new CVE?" (the SRE). "Where do we practice without breaking anything real?" (everyone). OWASP has a project for each of those questions. In this lesson we present those other key projects that complete the toolbox.

This is the last lesson of the overview module: here we expand the box and learn to combine projects according to the job at hand.

1. WSTG: the guide for thorough testing
2. Cheat Sheet Series: the remediation cheat sheets
3. Dependency-Check and dependency analysis (SCA)
4. Juice Shop: practicing without breaking anything real
5. Summary table: which project I use for what
6. How BazarNube would combine several projects

The OWASP Web Security Testing Guide (WSTG) is a methodical, exhaustive guide for testing the security of web applications. Where the Top Ten says "the risk of injection exists", the WSTG says "this is how you test, step by step, whether your application is vulnerable to injection".

Key traits:

• It is a testing methodology: it describes what to test, in what order, and how, grouped by areas (session management, authentication, input validation, business logic, and so on).
• Each test has an identifier and explains its objective, technique, and what to look for. It is the go-to reference for pentesters.
• It complements ZAP: ZAP automates a lot, but the guided manual testing of the WSTG finds flaws (especially business-logic ones) that no automation detects.

For BazarNube, the WSTG is the field manual when Marc wants to manually test the checkout flow or the coupon logic, beyond what ZAP covers.

The OWASP Cheat Sheet Series is a collection of concise, practical guides ("cheat sheets") on how to defend against specific risks. If the Top Ten raises awareness and the WSTG helps you find the flaw, the Cheat Sheets tell you how to fix it properly.

Key traits:

• Each cheat sheet covers one topic (XSS prevention, SQL injection prevention, password storage, session management, security headers, and so on) in a direct, actionable way, with concrete recommendations.
• They are written for developers: they get straight to the point with "do this, don't do that".
• They are the natural complement to the Top Ten: when you label a finding as A03, the corresponding Cheat Sheet gives you the solution pattern.

For BazarNube, when ZAP reports the SQL injection in /api/search (labeled A03), Lucía opens the SQL Injection Prevention Cheat Sheet and applies the recommended pattern (parameterized queries). It is the bridge between "I detected the problem" and "I fixed it correctly".

In lesson 02-04 we saw that there is a family of SCA (Software Composition Analysis) tools that analyze third-party dependencies. OWASP has its own free tool for this: OWASP Dependency-Check.

Why does it matter so much? A modern application is mostly other people's code: BazarNube drags along hundreds of npm packages in the React/Node API and dozens of Java libraries in the legacy module. If any of them has a known vulnerability (a CVE), the application inherits it even if your own code is impeccable. This is exactly the A06 (Vulnerable and Outdated Components) category of the Top Ten.

What Dependency-Check does, broadly:

• It reads the project's dependency manifests (package.json, pom.xml, etc.).
• It cross-checks them against databases of known vulnerabilities (public CVEs).
• It generates a report with which components are vulnerable, the severity, and which version to update to.

For BazarNube, integrating Dependency-Check into the pipeline means receiving an automatic alert every time one of its dependencies is affected by a new CVE, directly attacking the A06 risk without manual review.

All of the above has to be practiced, but testing attack techniques against BazarNube's real application (or any third-party system) is dangerous and illegal. OWASP's solution is Juice Shop: a deliberately vulnerable web application, modern and realistic (an online store, very much like BazarNube), created to be attacked and to learn from.

• It contains dozens of intentional vulnerabilities covering the Top Ten and more.
• It is a safe and legal firing range: you can run ZAP, test payloads, and follow the WSTG without consequences.
• It is ideal for training the team (SAMM's Governance domain: training and awareness) and for practicing before touching the real environment.

For BazarNube, Juice Shop is where Marc and Lucía learn to use ZAP and to recognize vulnerabilities before applying it to their own API. It is used in module 8 (exercises and cases).

This is the synthesis of the whole of module 2. Given a specific need, which OWASP tool do you reach for?

Notice the pattern that structures the whole box:

• Documents/frameworks (Top Ten, ASVS, SAMM, WSTG, Cheat Sheets): they tell you what to do and how to think.
• Executable tools (ZAP, Dependency-Check, Juice Shop): they do things or let you practice.
• And they all speak the same language: the Top Ten categories (A01–A10) are the thread that connects a ZAP finding, an ASVS requirement, a remediation cheat sheet, and a SAMM practice.

The key is not to choose one tool, but to orchestrate them. Here is how a realistic BazarNube flow would fit together, combining almost all the projects in the module:

Narrated as the team would experience it:

1. Training: Marc and Lucía practice on Juice Shop to learn how to attack and use ZAP without risk.
2. Structured verification: they review the app against the ASVS L2 checklist, labeling each failure with its Top Ten category.
3. Automatic detection: ZAP scans the running API and Dependency-Check reviews the dependencies (A06); both dump findings into the backlog.
4. Manual testing: with the WSTG, they thoroughly test the business logic (checkout, coupons) that automation doesn't cover.
5. Remediation: for each finding, they consult the corresponding Cheat Sheet and apply the correct solution pattern.
6. Maturity: the mere fact that all of this is systematic raises SAMM's Verification practice and gives management an objective snapshot of progress.

The result: the OWASP projects are not eight loose tools, but an integrated system where the Top Ten is the common language, ASVS the criterion, SAMM the thermometer, and ZAP/Dependency-Check/WSTG/Cheat Sheets/Juice Shop the hands that do the work.

• Looking for "the best tool". There isn't one: each project solves a different need. The right question isn't "which do I use?", but "what do I need it for right now?".
• Forgetting dependencies. Many teams secure their own code diligently and neglect third-party libraries, which are most of the software. Without SCA (Dependency-Check), the A06 risk is a blind spot.
• Automating everything and giving up manual testing. ZAP doesn't see business logic; the WSTG guides the manual testing that does. Both are necessary.
• Practicing attack techniques against real or third-party systems. It's dangerous and illegal. That's what Juice Shop is for: an environment designed to be attacked.
• Tip: internalize that the Top Ten categories are the glue of the whole box. If you label each finding with its A0x, everything else (ASVS, Cheat Sheets, ZAP reports) falls into place on its own.

Exercise 1. Match each BazarNube need with the most appropriate OWASP project: (a) "I want a step-by-step guide to manually test the cart logic"; (b) "ZAP flagged an XSS and I need the correct remediation pattern"; (c) "I want to know whether any npm library has a CVE"; (d) "I need an environment for the team to practice attacks without risk".

Exercise 2. Explain in 3–4 lines why Dependency-Check (SCA) is indispensable even if BazarNube does very rigorous code reviews of its own code.

Exercise 3. Design, in 5–6 steps, a workflow that combines at least four OWASP projects from the module to carry a finding from detection to verified fix, indicating what each one contributes.

Solution 1. (a) WSTG (step-by-step testing methodology, ideal for business logic); (b) Cheat Sheet Series (concrete remediation guides); (c) Dependency-Check (SCA on dependencies and CVEs, A06 risk); (d) Juice Shop (deliberately vulnerable application to practice on).

Solution 2. Because most of the software BazarNube runs is not its own code, but hundreds of third-party dependencies. An impeccable review of your own code won't detect a known vulnerability (CVE) in an npm or Java library that the application inherits. Dependency-Check automatically cross-checks those dependencies against vulnerability databases and warns you, covering the A06 risk that manual review of your own code leaves blind.

Solution 3. A possible flow: (1) Juice Shop — the team trains by practicing attacks without risk; (2) ASVS — the app is reviewed against the L2 checklist and an access control requirement comes up as "REVIEW"; (3) ZAP — a dynamic scan confirms an IDOR in /api/orders/:id, which is dumped into the backlog labeled as A01 (Top Ten); (4) Cheat Sheet Series — the access control/authorization cheat sheet is consulted to apply the correct pattern (verify resource ownership on the server); (5) the code is fixed; (6) it is re-scanned with ZAP to verify the finding is gone and the ASVS requirement is marked as PASS, which in turn raises SAMM's Verification practice. Contributions: Top Ten (language/prioritization), ASVS (verifiable criterion), ZAP (detection and verification), Cheat Sheets (remediation), SAMM (maturity), Juice Shop (training).

You have completed OWASP's toolbox. Beyond the four flagship projects (Top Ten, ASVS, SAMM, ZAP), you now know WSTG (exhaustive testing methodology), the Cheat Sheet Series (actionable remediation), Dependency-Check (SCA for the A06 vulnerable-components risk), and Juice Shop (a safe environment to practice on). And, most importantly, you have learned to combine them: they are not loose pieces, but an integrated system where the Top Ten categories act as the common language that connects detection, verification, remediation, and maturity.

With this we close module 2: BazarNube has chosen its toolbox and knows what each tool is for. But knowing them at a glance isn't enough; it's time to wield the first one in depth. In module 3 we dive into the OWASP Top Ten 2021 in depth, going through the categories A01 to A10 (plus XSS and XXE) one by one: what exactly they are, how they show up in BazarNube's code, and how they are remediated. The vocabulary we have only named today will become, category by category, operational knowledge.