With the Top Ten and ASVS, the BazarNube team already knows which risks to watch and which requirements to verify in the application. But in the last meeting, the SRE raises a question that neither of those two tools answers: "OK, we fix this release's findings... but as an organization, are we doing things so that this doesn't happen again in the next one? Do we even have a process, or are we just firefighting?". That question is no longer about an app: it's about the maturity of the organization in producing secure software. OWASP's tool for that is SAMM, the Software Assurance Maturity Model. In this lesson we present it at a high level; the detail — domains, assessment, continuous improvement — is the content of module 5.

1. What SAMM is and what it measures
2. SAMM versus ASVS: organization vs application
3. The idea of domains and maturity levels
4. How BazarNube would measure its maturity
5. Why maturity matters to a startup

The OWASP SAMM (Software Assurance Maturity Model) is a maturity model for an organization's security program. Its goal is not to assess whether an application is secure, but whether the way the company works produces secure software in a repeatable and improvable way.

Its essential traits:

• It measures processes and practices, not code. It asks things like: is there security training? is threat modeling done? is there vulnerability management? who responds to an incident?
• It is a maturity model. It offers a scale (typically from 0 to 3) for each practice, from "we don't do it" to "we do it in an optimized, measured way".
• It serves to take a snapshot and chart a roadmap. It's not about "passing", but about knowing where you are and where to improve, step by step.
• It is agnostic to technology and size. It works for a five-person startup or a multinational; each interprets the levels according to its own reality.

The word that sums up SAMM is maturity: not "is this app secure?", but "is the organization mature enough to produce secure apps in a sustained way?".

This is the nuance that's hardest at first: SAMM and ASVS sound similar but measure things on completely different planes. ASVS looks inside the application; SAMM looks at the organization that builds it.

A useful analogy: if BazarNube were a restaurant, ASVS would be the inspection of a specific dish (is it well cooked, free of contamination?), while SAMM would be the assessment of the kitchen as a system (are there hygiene protocols? is the staff trained? are suppliers vetted?). You can cook one dish correctly by luck; SAMM asks whether your kitchen will get it right every time.

SAMM organizes security practices into a small number of domains (broad areas of activity) that cover the full software lifecycle. Here we only give the general idea; module 5 develops them one by one.

Schematically, SAMM groups security activity into five business functions (domains), each with its own practices:

Over each practice, SAMM applies a maturity scale that, in simplified form, reads like this:

The key idea: it's not about being at level 3 in everything. A healthy startup can be at level 1 in most practices, and that is already an achievement. SAMM doesn't judge: it positions and helps prioritize which practices to invest in first.

Let's apply it. The team does a quick self-assessment (a very simplified version of what module 5 formalizes). For each practice, they honestly ask themselves what level they're at today:

From this simple table, the team draws very actionable conclusions:

• Its average maturity is low (between 0 and 1), which is normal and expected for a young startup. It's not a failure: it's the starting point.
• The most urgent gaps are in Verification (they don't test their security) and Operations (they don't know what they would do in an incident).
• They already have foundations in Design (the risk map) and Implementation (the backlog) to build on.
• The roadmap almost draws itself: introducing security testing (adopting ZAP, module 6) would raise Verification from 0 to 1; defining a minimal response plan would raise Operations.

Notice something important: SAMM connects and gives meaning to the previous tools. The risk map, the Top Ten-labeled backlog, and the ASVS checklist are not loose pieces: they are evidence of maturity within specific SAMM domains. SAMM is the framework that turns isolated efforts into a coherent, directed program.

It might seem that a maturity model is "a thing for big companies". It's exactly the opposite: for a startup like BazarNube, SAMM is especially valuable because:

• It avoids depending on heroes. If security only works because Lucía remembers to review it, the day Lucía isn't there, it collapses. Maturity means things happen by process, not by individuals.
• It prioritizes with scarce resources. A startup can't do everything. SAMM helps decide which practice to improve first for the greatest impact.
• It gives a narrative to investors and clients. "We have a security maturity plan and we're here" conveys far more confidence than "we fix whatever pops up".
• It grows with you. The same model works when you're five and when you're fifty; only the level you aspire to changes.

• Confusing SAMM with ASVS. ASVS assesses an application; SAMM assesses the organization and its processes. They are complementary: one looks at the product, the other at the factory.
• Wanting to be at level 3 in everything. It's counterproductive and extremely expensive. The goal is not uniform perfection, but balanced, sustainable progress. A generalized level 1 is already a solid base.
• Doing the assessment only once. SAMM is a cycle of continuous improvement: you reassess periodically to see the progress. A single snapshot isn't worth much.
• Being dishonest in the self-assessment. Inflating the levels to look good destroys the value of the exercise. The goal is to know where you really stand, not to pass an exam.
• Tip: start small. An honest, informal half-hour self-assessment already gives you a useful roadmap. You don't need the full model to get value on day one.

Exercise 1. Classify each statement as belonging to ASVS or to SAMM: (a) "The BazarNube team performs threat modeling systematically on every project"; (b) "The application stores passwords with a strong hashing algorithm"; (c) "There is a defined incident response process with assigned roles".

Exercise 2. BazarNube has found that its "Security testing" practice (Verification) is at level 0. Propose a concrete action that would take it to level 1 and explain which course tool it relates to.

Exercise 3. Explain in 4–5 lines why a low average maturity (between 0 and 1) is not cause for alarm for a startup like BazarNube, and what it should do with that data.

Solution 1. (a) SAMM (it talks about an organizational practice and its regularity, Design domain); (b) ASVS (it's a verifiable requirement about the application); (c) SAMM (it describes an organizational process, Operations domain).

Solution 2. A concrete action: adopt OWASP ZAP to scan BazarNube's API regularly, even manually at first. Going from "we don't test anything" to "we scan with a DAST tool before every release" raises the Verification practice from level 0 to level 1. It relates to ZAP, which we present in lesson 02-04 and develop in module 6.

Solution 3. Low maturity is the expected starting point for almost any young startup: it reflects that the company hasn't yet formalized its security processes, not that it does things badly. What matters isn't the figure, but using it as a baseline to chart a roadmap: identify the most critical gaps (at BazarNube, Verification and Operations) and plan incremental improvements. SAMM doesn't penalize being low; it penalizes not knowing where you are or where you're heading.

You have met the third tool in the OWASP box: SAMM, a maturity model that assesses not an application, but the organization's security program. You know that it differs from ASVS in plane (organization/process vs application/product), that it organizes activity into domains (Governance, Design, Implementation, Verification, Operations), and that it scores each practice on maturity levels 0–3. And you have seen how BazarNube would do an honest self-assessment that, far from alarming, gives it a clear roadmap.

With the Top Ten, ASVS, and SAMM, BazarNube has the what (risks), the how much (verifiable requirements), and the how mature (processes). But something very practical is missing: a tool that actively attacks the application to find the flaws the tables don't see. The three previous projects are frameworks and standards; now it's time for an executable tool. In lesson 02-04 we present OWASP ZAP, the interception proxy with which BazarNube will test its API at runtime.