Throughout the module, many proper names have appeared almost in passing: Semgrep flagging an injection, gitleaks blocking a secret, trivy scanning an image, ZAP in staging, the Cheat Sheets as training material. Each has come up in its own context—the pipeline, the threat model, the training—but we have never seen them together and organized. This final lesson of the module does exactly that: it presents an overview of tools by category, catalogs the OWASP resources for continued learning, and consolidates everything into a recommended security stack for BazarNube. It is the map we will carry into the exercises and case studies of module 8.

1. How to choose tools: judgment before the catalog
2. Overview of tools by category
3. OWASP resources for continued learning
4. Communities and how to stay up to date
5. The recommended security stack for BazarNube
6. Common mistakes and tips
7. Exercises
8. Conclusion

Before the catalog, a warning that runs through the whole module: tools are means, not ends. A pipeline full of scanners without process or owners generates noise, not security (we saw this in 07-01 and 07-03). When choosing, weigh:

• Integration: does it fit into the team's pipeline and IDE? A tool that does not integrate does not get used.
• Signal/noise ratio: how many false positives does it generate? Noise kills adoption.
• Coverage against your risk: prioritize what covers your real threats (those in your threat model), not what is trendy.
• Total cost: license, maintenance, and triage time.
• Open source vs commercial: open source (many OWASP projects) is ideal to start and learn; commercial usually adds less noise, plus support and centralized management, in exchange for cost.

Each category corresponds to a control in the DevSecOps pipeline of 07-03. The examples include open source and commercial options; this is neither an exhaustive list nor a ranking, but recognized starting points.

Reading notes:

• OWASP ZAP is the course's reference DAST; we covered its use in depth in module 6, here we only place it in the overview.
• OWASP Dependency-Check and Dependency-Track are the OWASP option for SCA: the first scans, the second continuously manages the component inventory (SBOM), very useful against A06.
• Semgrep stands out in SAST for its low noise and for letting you write your own easy-to-maintain rules (security as code).
• trivy is versatile: it covers containers, IaC, and dependencies, which reduces the number of distinct tools to maintain.

OWASP is much more than the Top Ten. These are the resources worth knowing and returning to:

The Cheat Sheets deserve a special mention as a day-to-day resource: when a developer has to implement authentication, file upload, or XSS prevention, there is a concise sheet with the concrete recommendations. They are the natural complement to the secure coding of 07-04.

Security evolves constantly: new vulnerabilities, new techniques, new versions of the standards themselves. Staying up to date is part of the job:

• Local OWASP chapters: in-person/online meetups, talks, and networking. Participating is one of the best ways to learn and to find mentors.
• OWASP projects on GitHub: follow and contribute to the projects you use.
• Vulnerability bulletins: CISA KEV, advisories from your dependencies' vendors, GitHub Security Advisories.
• Conferences: OWASP Global AppSec and regional events; many talks are recorded and freely available.
• Training and certifications: we will revisit the certification options in module 9.

A simple, high-return habit: set aside a fixed slot each week to read a new Cheat Sheet or the writeup of a recent vulnerability. Consistency beats binges.

Bringing the whole module together, this is the stack that Lucía, the SRE, and the champions consolidate for BazarNube. It is deliberately biased toward open source and OWASP projects: it covers the real risk at a contained cost and fits the pipeline of 07-03.

This stack is neither definitive nor universal: it is the coherent starting point for this product and this maturity. As BazarNube moves up in SAMM, it will add pieces (centralized management, perhaps a lower-noise commercial tool) and retire the ones that no longer contribute. The right tool is the one your team uses, understands, and maintains.

• Buying tools before defining the process. An expensive scanner without owners or gates is money thrown away. First the S-SDLC and the people (07-01, 07-04), then the tools.
• Overlapping tools that do the same thing. Three different SAST tools triple the noise and the triage without tripling the value. Choose one per category and master it before adding another.
• Ignoring maintenance. Tools need updated rules and CVE databases; an outdated one gives a false sense of security.
• Chasing the latest trend. Choose by your real risk (your threat model), not by what is announced at the latest conference.
• Tip: start with the minimal open source stack that covers your critical controls, measure it, and only then assess whether a commercial product reduces the noise or effort enough to justify its cost.

Exercise 1. Assign the right tool to each need: (a) detect an AWS key in a commit, (b) find a Node library with a critical CVE, (c) check that a Terraform bucket is not public, (d) attack the staging login.

Exercise 2. BazarNube has the budget for one commercial tool. What criterion would you use to decide which category to invest it in, and what would you ask before buying?

Exercise 3. A colleague proposes adding a second SAST "to get more coverage." Argue for or against in terms of signal/noise and maintenance.

Solution 1.

• (a) gitleaks (secret scanning).
• (b) OWASP Dependency-Check (SCA).
• (c) trivy or Checkov (IaC scanning).
• (d) OWASP ZAP (DAST).

Solution 2. The criterion is where open source leaves the most value uncaptured for BazarNube's risk: usually where the noise or triage effort is greater, or where centralized management is missing. Before buying, I would ask: does it really reduce false positives compared to what I already have? Does it integrate into my pipeline and IDE? What is the total cost (license + maintenance + triage)? Does it add management/reporting I lack today? You buy for a measurable reduction in noise or effort, not for the brand.

Solution 3. Against, in general: a second SAST overlaps much of the first's coverage but doubles the noise (two false-positive queues to triage) and the maintenance (two rule engines to update), eroding adoption through alert fatigue. It is preferable to go deeper into one SAST—tuning and writing your own rules—rather than adding another. A second one would only make sense if it covered a language or class of flaw the first demonstrably does not.

With this overview of tools by category, the catalog of OWASP resources, and the recommended stack for BazarNube, we close the best practices module. Across these five lessons we have assembled the complete process: an S-SDLC that distributes security across phases, the threat modeling that seeds it in the design, DevSecOps that automates it in the pipeline, the training that sustains the human factor, and now the tools and resources that make it all possible. Security has stopped being a final phase and become a continuous property of the process and the culture, just as the close of module 6 promised. All of it rests on what we learned before: the Top Ten as a catalog, ASVS as requirements, SAMM as maturity, and ZAP as verification. The time has come to put it into practice. In module 8 we leave theory behind and work with our hands: two hands-on exercises and two case studies where you will apply, on BazarNube, everything you have integrated across these lessons.