In the previous lesson we saw that SAMM organizes the organization's security into 5 business functions, 15 security practices and maturity levels. Now we open up that structure. The business functions (sometimes called domains) are the major blocks of activity of any organization that produces software; each one groups three concrete practices, and each practice is divided into two streams. Knowing this map well is essential: it is the framework on which we will perform the self-assessment (05-03) and the roadmap (05-04). In this lesson we walk through the five functions, their practices, and we distribute the responsibilities at BazarNube.

1. The 5 business functions at a glance
2. Governance: governing security
3. Design: building security from the design stage
4. Implementation: bringing security to code and deployment
5. Verification: checking that what is built is secure
6. Operations: keeping security in production
7. Complete table: functions → practices → streams
8. Distribution of responsibilities at BazarNube

SAMM v2 distributes all assurance activity across five functions that roughly follow the natural flow of software: first you govern, then you design, implement, verify and finally operate.

Each function has three security practices, and each practice has two streams (called A and B) that represent two complementary objectives. Important: in this module we learn to organize and measure these practices. The detail of how to execute the technical ones (threat modeling, secure build, DevSecOps, awareness...) is developed in module 7 (Best practices). SAMM structures them; M7 puts them into action.

It covers how the organization directs, funds and supports its security activities. It is the most "top-down" function, closely tied to leadership.

• Strategy & Metrics: create and promote a security strategy and measure it. Streams: (A) create and promote, (B) measure and improve.
• Policy & Compliance: set internal policies and standards and manage regulatory compliance (GDPR, PCI-DSS...). Streams: (A) policy and standards, (B) compliance management.
• Education & Guidance: train and raise awareness across teams and build a security culture. Streams: (A) training and awareness, (B) organization and culture.

It covers how security objectives and the design of the software are defined before writing code.

• Threat Assessment: understand each application's risk and model its threats. Streams: (A) application risk profile, (B) threat modeling.
• Security Requirements: define security requirements for your own software and for suppliers. Streams: (A) software requirements, (B) supplier security.
• Security Architecture: design with secure patterns and components and manage the technology used. Streams: (A) architecture design, (B) technology management.

It covers how the software is built and deployed reliably and securely.

• Secure Build: a reproducible and secure build process, and dependency management. Streams: (A) build process, (B) software dependencies.
• Secure Deployment: deploy securely and manage secrets. Streams: (A) deployment process, (B) secret management.
• Defect Management: log, prioritize and learn from security defects. Streams: (A) defect tracking, (B) metrics and feedback.

It covers how the organization checks that the software meets its security objectives. (This is where the ASVS from module 4 and ZAP from module 6 fit as instruments.)

• Architecture Assessment: validate that the architecture meets the objectives and mitigate its weaknesses. Streams: (A) architecture validation, (B) architecture mitigation.
• Requirements-driven Testing: test that controls work and hunt for abuse/misuse. Streams: (A) control verification, (B) misuse/abuse testing.
• Security Testing: scalable (automated) security testing and deep-understanding (manual, pentest) testing. Streams: (A) scalable baseline, (B) deep understanding.

It covers how the software's security is maintained once in production.

• Incident Management: detect and respond to security incidents. Streams: (A) incident detection, (B) incident response.
• Environment Management: harden the configuration and apply patches and updates. Streams: (A) configuration hardening, (B) patching and updating.
• Operational Management: protect data and manage the lifecycle of legacy systems. Streams: (A) data protection, (B) legacy management.

This is the complete map of SAMM v2, the reference we will use in the rest of the module:

It is 5 functions × 3 practices = 15 practices, each with 2 streams. When in the next lesson we score maturity, we will do it practice by practice over this same grid.

A classic mistake is leaving all of SAMM in the hands of the technical team. Many practices depend on leadership, SRE or business. At BazarNube the AppSec role (you) facilitates, but each function has an owner who is accountable:

Observations for BazarNube:

• The legacy Java/Spring stack raises the weight of Environment Management (patching) and Secure Build (dependencies): it is where the most debt accumulates.
• Education & Guidance (Governance) and Security Testing (Verification) are cross-cutting: they affect all teams and are usually the first to end up without a clear owner.
• A function having an owner does not mean it works alone: AppSec coordinates and the rest collaborate. The owner is who is accountable for its maturity.

Remember: here we only assign and frame the practices. How a threat model is built, how a DevSecOps pipeline is set up or how an awareness plan is designed is module 7 content.

• Leaving all of SAMM with the technical team. Governance and Operations depend on leadership and SRE; without their owners, those functions go unmatured.
• Confusing function with practice. The function is the big block (e.g. Design); the practice is the concrete activity (e.g. Threat Assessment). Maturity is scored by practice.
• Ignoring the two streams of each practice. A practice may be mature in one stream and green in the other (e.g. secure build but uncontrolled dependencies); looking at only one gives a false picture.
• Trying to develop the technical practices here. The "how" of threat modeling, secure build or DevSecOps belongs to module 7; in SAMM we only organize them.
• Assigning practices with no accountable owner. Without an owner, a practice is neither assessed nor improved.
• Tip: memorize the 5 functions and their order first (Govern-Design-Implement-Verify-Operate); the 15 practices are much easier to remember hung off their function.

Exercise 1. Place each practice in its business function: (a) Secure Deployment, (b) Threat Assessment, (c) Incident Management, (d) Education & Guidance, (e) Security Testing.

Exercise 2. At BazarNube, which business function and which practice cover each situation? (a) The SRE defines how often patches are applied to the legacy Java server. (b) The CTO approves the annual security budget. (c) Lucía reviews the npm dependencies for CVE before a build. (d) A secure coding course is organized for the developers.

Exercise 3. Choose any practice from the table and explain in your own words what each of its two streams would cover. Why do you think SAMM separates each practice into two streams instead of scoring it as a whole?

Solution 1. (a) Implementation, (b) Design, (c) Operations, (d) Governance, (e) Verification.

Solution 2. (a) Operations → Environment Management (patching and updating stream). (b) Governance → Strategy & Metrics (strategy and its promotion/funding). (c) Implementation → Secure Build (software dependencies stream). (d) Governance → Education & Guidance (training and awareness stream).

Solution 3. Example with Secure Build: stream A (build process) covers that the pipeline is reproducible, integrity-preserving and free of insecure manual steps; stream B (dependencies) covers that the libraries are known and inventoried and that vulnerable ones are detected/updated. SAMM separates into two streams because a practice can mature unevenly: you can have an impeccable build and, at the same time, no control over dependencies. Two streams give a finer picture and prevent a strong aspect from hiding a weak one.

We now have the complete map of SAMM: 5 business functions (Governance, Design, Implementation, Verification, Operations), 15 security practices and 2 streams per practice, with an assigned owner at BazarNube for each function. This framework is the grid on which we are going to measure. Remember that here we have only framed the practices; the execution detail of the technical ones comes in module 7. In the next lesson we take the decisive step: we introduce the maturity levels (0 to 3), learn to do a practical self-assessment practice by practice and build BazarNube's first real scorecard.