We closed module 4 with a question the ASVS does not answer: "is our organization capable of producing secure applications repeatably and of improving that capability over time?". BazarNube already knows how to verify its product by levels and with evidence, but that does not guarantee that the team has good processes for training, supplier management, incident response or continuous improvement. In this module we take that leap: we stop looking at the application and look at the organization's security program. The tool to do it is OWASP SAMM. In this first lesson we will see what it is, what it is for, how it differs from the ASVS and how BazarNube decides to adopt it.

1. What SAMM is and what problem it solves
2. Purpose: measure in order to improve
3. An agnostic and iterative model
4. High-level structure of SAMM
5. SAMM (organization) vs. ASVS (application): the key contrast
6. Who SAMM serves and who uses it
7. How BazarNube decides to adopt SAMM

SAMM stands for Software Assurance Maturity Model, a flagship OWASP project. It is a framework for assessing, formulating and improving an organization's software security strategy in a measurable way.

The keyword is maturity. SAMM does not verify whether a specific application is secure; it describes how mature the security practices of the organization that builds software are: whether they exist, whether they are documented, whether they are applied consistently and whether they are optimized with data.

The problem it solves is very real and BazarNube already lives it. After module 4 the team knows how to verify an app, but:

• There is no objective way to answer "are we improving or just firefighting?".
• The CTO cannot compare today's security state with that of six months ago.
• Each team does things its own way; what worked in one project is not repeated in the next.
• There is no shared plan for where the security capability should grow.

SAMM provides a common language and a measuring stick to answer all of that.

SAMM's purpose boils down to a cycle: assess → set goals → improve → measure again. It is not a certificate or a pass/fail audit; it is a management instrument that pursues three things:

• Assess the current state of security practices objectively and repeatably.
• Set a maturity goal that is achievable and aligned with the business risk.
• Measure progress over time with a comparable metric.

The underlying idea is that you cannot improve what you do not measure. If BazarNube wants to convince its CTO to invest in security, it needs a measurable snapshot of where it is and a roadmap of where it wants to be. That is exactly what SAMM produces: a scorecard (which we will see in 05-03) and a roadmap (05-04).

Two properties make SAMM applicable to almost any organization:

• Agnostic: it imposes no technology, methodology or size. It works the same for an agile team of five as for a waterfall multinational, with any language or cloud. It does not say "use this tool", but "make sure this capability exists and matures". This fits BazarNube's heterogeneous stack (React, Node/Express, legacy Java/Spring, PostgreSQL in Docker): SAMM does not judge the stack, it judges the process.
• Iterative and incremental: it is not adopted "all at once". You assess, choose a modest goal, run an iteration, reassess and repeat. Maturity rises step by step, not through heroic leaps.

In addition, SAMM is risk-based: not every organization needs the maximum level in everything. The goal is adjusted to the business's risk profile, not to an abstract ideal.

SAMM (in its version 2) is organized into three nested pieces that we will unpack in the coming lessons:

• 5 business functions: the major blocks of activity of any organization that produces software: Governance, Design, Implementation, Verification and Operations.
• Security practices: each function groups three practices (15 in total). Each practice is further divided into two streams that represent two complementary objectives of that practice.
• Maturity levels: each practice is scored on a scale of 0 to 3, where 0 is "not done", 1 is an initial practice, 2 is a structured and consistent practice, and 3 is a practice optimized with data.

At a high level, assessing the organization with SAMM consists of walking through the 15 practices, placing each one at its maturity level and obtaining a complete snapshot. The detail of the functions and practices is in 05-02; that of the levels and the assessment, in 05-03.

This is the point that connects with module 4 and is worth nailing down. ASVS and SAMM are both from OWASP and complement each other, but they answer different questions:

A useful metaphor: the ASVS is the student's exam; SAMM is the school's quality system. Passing the exam (ASVS L2 today) does not mean the school teaches well repeatably. A company can pass an L2 audit in one project and, with no process maturity behind it, accumulate security debt in the next. That is why they are complementary: SAMM tells you whether your organization is capable of generating apps that pass the ASVS systematically. One does not replace the other.

SAMM is intended for roles that look at security from above, not only from the code:

• Technical leadership (CTO, CISO): to have an executive snapshot of process risk and justify investment.
• Security / AppSec leads: to run the assessment, maintain the scorecard and design the roadmap.
• Team leaders (like Lucía): to understand which practices are theirs and how to mature them.
• Product and business: to understand that security is a capability built in phases, with cost and return.
• Auditors and clients: as a shared framework for talking about maturity, not just compliance.

It is common for one person to act as facilitator of the assessment (at BazarNube, the AppSec role the learner plays) by interviewing the owners of each function.

With module 4 just closed, BazarNube's CTO raises the uncomfortable question in a committee: "The pentest went reasonably well, but how do I know we won't trip over the same thing again in six months?". Nobody has a measurable answer. That is the signal that SAMM is needed.

The team decides to adopt it with a realistic approach:

1. Motivation: move from "we verify the app" to "we know whether our organization is improving". Give the CTO a metric comparable over time.
2. Initial scope: the entire BazarNube product unit (Lucía's and Marc's teams, the SRE and the organizational functions), not a single project.
3. Facilitator: the AppSec role (you) leads the first self-assessment by interviewing the owners of each function.
4. Cadence: one self-assessment now (baseline) and semi-annual reassessments.
5. Expected deliverables: an initial scorecard (05-03) and an iteration-based roadmap toward a maturity goal (05-04).

With this decision, BazarNube stops measuring only its product and starts measuring its capability to produce secure products.

• Confusing SAMM with ASVS. SAMM measures the organization and its processes; ASVS verifies the application. Using one expecting the other leads to false conclusions.
• Treating SAMM as a pass/fail certification. It is not: it is a continuous-improvement instrument. The figure matters for its trend, not for whether it "passes".
• Aiming for level 3 in everything from the start. SAMM is risk-based and iterative; the goal is adjusted to the business and climbed step by step.
• Assessing only with the technical team. Functions like Governance or Operations depend on leadership, SRE and business; those roles must be interviewed.
• Adopting SAMM without a clear facilitator. Without someone to run the assessment and maintain the scorecard, the exercise dilutes.
• Tip: start with an honest self-assessment even if it hurts. A low but real baseline is far more useful than an optimistic snapshot.

Exercise 1. For each statement, indicate whether it corresponds to SAMM or ASVS and why: (a) "The payments module meets the V9.1.1 TLS requirement". (b) "Our developer training practice is at maturity 1". (c) "We want to compare our security state in January with July's". (d) "The pentester verified the app's authorization controls".

Exercise 2. BazarNube's CTO says: "We already passed ASVS L2 verification, why do we need SAMM?". Write a short answer (3-4 sentences) explaining the difference and why they are complementary.

Exercise 3. List SAMM's 5 business functions and, without developing them yet, write in one sentence what major area of the organization you think each one covers.

Solution 1. (a) ASVS: it verifies a specific technical requirement of the application. (b) SAMM: it describes the maturity of an organizational practice on the 0–3 scale. (c) SAMM: comparing state over time is measuring process maturity, not verifying a product. (d) ASVS: technical verification of the controls of a specific app.

Solution 2. "ASVS L2 tells us that this application complies today; it does not tell us whether we can repeat it in the next project or whether we improve over time. SAMM measures the maturity of our processes (training, design, incident response...) with a metric comparable semester by semester. They are complementary: SAMM ensures our organization is capable of producing apps that pass the ASVS systematically, not by luck."

Solution 3. Governance (governing: strategy, policies and training), Design (design: threats, requirements and security architecture), Implementation (building: secure build, deployment and defect management), Verification (verification: architecture review and security testing), Operations (operating: incidents and environment management). Any reasonable wording that associates each function with its area is valid; the exact detail comes in the next lesson.

SAMM is the instrument with which BazarNube moves from verifying its application (ASVS, module 4) to measuring and maturing its organization's security program. It is an agnostic model (it imposes no technology), iterative (it is climbed step by step) and risk-based (the goal is adjusted to the business), structured into 5 business functions, 15 security practices and maturity levels from 0 to 3. Against the ASVS, which answers "is this app secure?", SAMM answers "do we know how to produce secure apps repeatably?". With the decision to adopt it made, in the next lesson we open the box: we will walk through the 5 business functions and their security practices one by one, and see who is responsible for each at BazarNube.