The incident in the previous lesson was the turning point. BazarNube understood, in the most expensive way, that putting out fires one by one is not a security strategy: while an IDOR caused a breach, the search SQLi, the import SSRF and a header-less configuration were all still alive. This final case study tells the transformation: how BazarNube moves from an initial insecure, reactive state to a mature, proactive one, applying in an integrated way everything we have covered in the course -Top Ten remediated, ASVS as verifiable requirements, SAMM as a roadmap, ZAP in the pipeline, threat modeling in design and DevSecOps as the glue. This is not a lesson of new concepts, but the synthesis of them all: the moment the pieces stop being studied separately and function as a program. As the last lesson of the practical module, it also closes the BazarNube arc and prepares the final assessment of module 9.

1. The starting point: BazarNube in an insecure state
2. The strategy: from reactive to proactive with SAMM
3. The phased transformation roadmap
4. Improvement metrics: before and after
5. The final picture: BazarNube's security program
6. Common mistakes and tips
7. Exercises
8. Conclusion

Before the transformation, BazarNube's situation was that of so many applications that grow fast without security built in. An honest diagnosis:

This state is not a caricature: it is the one that made the 08-03 incident possible. The transformation consists of raising each of these rows in an orderly, sustainable way.

The mistake would have been to rush into "fixing everything" without order. BazarNube used OWASP SAMM (module 5) as a compass: first a maturity assessment to know where it stood, then a realistic 12-month target, and an incremental improvement roadmap by domain. The guiding idea, already seen in 05-04, is that maturity is built level by level, not by heroic leaps.

The target was not "level 3 in everything" (unrealistic and probably unnecessary), but a consistent level 2 in the critical domains, aligned with the 07-05 decision to aim for ASVS L2, the appropriate level for an application that handles payments. Coherence between standards: SAMM says how mature the program is, ASVS says what the product must satisfy.

The transformation was organized into three quarterly phases, each building on the previous one.

Priority: eliminate the existing critical risk and gain visibility.

• Remediate the critical and high findings in the backlog (BZN-134, BZN-101, BZN-140, BZN-131...) with the controls from 08-02.
• Introduce the anomaly monitoring that was missing in the incident (03-11): per-user rate alerts.
• Put ZAP in baseline mode in the pipeline (06-04) so as not to introduce new regressions.
• Cultural quick win: a secure coding workshop (07-04) with the team, using the incident itself as the case.

Priority: stop security from depending on heroes and make it part of the flow.

• Integrate the full DevSecOps stack (07-03, 07-05): gitleaks, Semgrep (SAST), Dependency-Check (SCA), trivy, with defined gates.
• Adopt ASVS L2 as a catalog of verifiable requirements; every sensitive story carries its requirements as acceptance criteria (M4).
• Introduce threat modeling (07-02) in the design of every new feature involving data or money, starting with checkout.
• Appoint Security Champions per team (07-04) to scale the knowledge.

Priority: consolidate, measure and improve continuously.

• Authenticated/full ZAP scan nightly against staging (06-04), with findings already mapped into the backlog.
• Security metrics on a dashboard: remediation time, scan coverage, findings by severity.
• SAMM reassessment to confirm the move to level 2 and set the following year's target.
• Continuous training program and participation in the OWASP community (07-05).

The transformation is only credible if it is measured. These are the metrics BazarNube tracked, with illustrative before-and-after values over the twelve months:

The most significant leap is not a specific figure, but the change of nature: security went from being measured after the problem (number of incidents) to being measured before (coverage, verified requirements, remediation time). It went from counting fires to measuring prevention.

A security program is not sustained by good engineering alone: it needs budget and management backing, and that requires speaking the language of the business. BazarNube justified the investment not by appealing to fear, but by comparing the cost of the improvement with the cost of not doing it, which the 08-03 incident had made tangible.

The key is to present security as the reduction of a quantified risk, not as an abstract technical expense. Each roadmap initiative was tied to a concrete risk from the backlog or the incident, so management could see what it bought with each euro. That translation is often what separates a program that survives the first budget cut from one that does not.

After a year, every piece of the course operates together and continuously. This is the architecture of the mature program, where each element studied takes its place:

Note the loop: production monitoring feeds back into threat modeling (what actually happens adjusts what we imagined could happen), and SAMM measures the whole to guide the following year's improvement. Security has stopped being a phase or a project and has become a continuous property of the system and the team, just as the close of module 6 promised and module 7 consolidated.

• Wanting to reach the top level all at once. Aiming for "ASVS L3 and SAMM 3 in everything" in a single quarter exhausts the team and fails. Maturity is incremental; a solid level 2 beats a level 3 on paper.
• Buying tools without process or owners. A pipeline full of scanners with no gates or owners generates noise, not security (07-01, 07-05). Process and people first.
• Not measuring. Without before-and-after metrics, the transformation is an opinion. What is not measured cannot be improved or defended to management.
• Neglecting culture. The best pipeline fails if the team sees security as a brake. Champions and training (07-04) sustain everything else.
• Tip: start with phase 1 (stop the bleeding) even if the full plan is not finalized. Reducing critical risk and gaining visibility builds the trust and the room to construct the rest without rushing.

Exercise 1. Prioritization. BazarNube has resources for a single initiative in the first month: (a) integrate SAST, (b) remediate the 9 critical/high findings, or (c) train the champions. Justify your choice in terms of immediate risk reduction.

Exercise 2. Metrics. Management asks for "one metric" to know whether security is improving. Propose the one you would choose, explain what it captures and what you miss by reducing everything to a single number.

Exercise 3. Coherence of standards. Explain in your own words the difference in purpose between SAMM and ASVS in this case, and why BazarNube needs both and cannot substitute one for the other.

Solution 1. The choice with the greatest immediate risk reduction is (b) remediate the 9 critical/high findings: they are vulnerabilities exploitable right now in production (one already caused the 08-03 incident), so closing them eliminates real, present risk. SAST (a) and champions (c) are investments in preventing future flaws, extremely valuable in the medium term, but they do not reduce the risk of already-deployed code. The correct sequence is the roadmap's: first stop the bleeding (b), then build the process (a) and the culture (c).

Solution 2. A good candidate is the mean time to remediation of critical/high vulnerabilities: it captures both that you are finding them (there is something to remediate) and that you react fast (a working process), and it correlates well with real risk. What it misses: it does not say how many vulnerabilities you are not detecting (coverage), nor the quality of the design, nor the culture. That is why a single number orients but is not enough; it should be accompanied by scan coverage and verified ASVS requirements. Reducing security to one metric invites optimizing that metric instead of security.

Solution 3. SAMM measures and guides the maturity of the program: how well the organization does security (processes, activities, governance) -it is a compass for organizational improvement. ASVS defines what the product must satisfy: verifiable technical requirements on the concrete application -it is a checklist for the artifact. BazarNube needs both because they answer different questions: SAMM asks "are we organized to produce secure software?" and ASVS asks "is this software secure?". A mature program (high SAMM) without verified requirements (ASVS) can have good intentions and insecure products; and the other way round, meeting ASVS on one app without a program behind it is neither sustainable nor repeatable on the next. They complement each other, they do not substitute.

With this case study we close the practical module and the complete BazarNube arc. We have watched the application travel the whole path: from a backlog full of Top Ten vulnerabilities and an avoidable incident, to a mature security program where threat modeling seeds the ASVS requirements, DevSecOps verifies them on every change, ZAP watches in the pipeline and in production, monitoring detects in minutes and SAMM guides the continuous improvement year after year. That is the destination the whole course pointed to from the first lesson: security as a continuous property of the process and the culture, not as a phase or one-off heroism. You have applied, on a concrete case, every OWASP standard and tool we have studied. Now it is time to demonstrate and consolidate what you have learned: in module 9, the last of the course, we tackle the final assessment that verifies your knowledge and the paths to certification to accredit it professionally. You reach it with the most important thing already achieved: not just knowing what each piece is, but having used it.