Tanquem el mòdul 4 amb una pregunta que l'ASVS no respon: "és capaç la nostra organització de produir aplicacions segures de manera repetible i de millorar aquesta capacitat amb el temps?". BazarNube ja sap verificar el seu producte per nivells i amb evidències, però això no garanteix que l'equip tingui bons processos de formació, de gestió de proveïdors, de resposta a incidents o de millora contínua. En aquest mòdul fem aquest salt: deixem de mirar l'aplicació per mirar el programa de seguretat de l'organització. L'eina per fer-ho és OWASP SAMM. En aquesta primera lliçó veurem què és, per a què serveix, en què es diferencia de l'ASVS i com BazarNube decideix adoptar-lo.

1. Què és SAMM i quin problema resol
2. Propòsit: mesurar per poder millorar
3. Un model agnòstic i iteratiu
4. Estructura general de SAMM a alt nivell
5. SAMM (organització) vs. ASVS (aplicació): el contrast clau
6. Per a qui serveix SAMM i qui l'usa
7. Com BazarNube decideix adoptar SAMM

SAMM són les sigles de Software Assurance Maturity Model (Model de Maduresa de l'Assegurament de Programari), un projecte insígnia d'OWASP. És un marc per avaluar, formular i millorar l'estratègia de seguretat de programari d'una organització de manera mesurable.

La paraula clau és maduresa. SAMM no verifica si una aplicació concreta és segura; descriu com de madures són les pràctiques de seguretat de l'organització que construeix programari: si existeixen, si estan documentades, si s'apliquen de manera consistent i si s'optimitzen amb dades.

El problema que resol és molt real i BazarNube ja el viu. Després del mòdul 4 l'equip sap verificar una app, però:

• No hi ha una manera objectiva de respondre "estem millorant o només apaguem focs?".
• El CTO no pot comparar l'estat de seguretat d'avui amb el de fa sis mesos.
• Cada equip fa les coses a la seva manera; el que va funcionar en un projecte no es repeteix en el següent.
• No hi ha un pla compartit de cap on ha de créixer la capacitat de seguretat.

SAMM aporta un llenguatge comú i una regla de mesurar per respondre a tot això.

El propòsit de SAMM es resumeix en un cicle: avaluar → definir objectius → millorar → tornar a mesurar. No és un certificat ni una auditoria d'aprovat/suspès; és un instrument de gestió que persegueix tres coses:

• Avaluar l'estat actual de les pràctiques de seguretat de manera objectiva i repetible.
• Definir un objectiu de maduresa assolible i alineat amb el risc del negoci.
• Mesurar el progrés al llarg del temps amb una mètrica comparable.

La idea de fons és que no es pot millorar el que no es mesura. Si BazarNube vol convèncer el seu CTO d'invertir en seguretat, necessita una foto mesurable d'on és i un full de ruta cap a on vol estar. Això és exactament el que produeix SAMM: un scorecard (que veurem a 05-03) i un roadmap (05-04).

Dues propietats fan SAMM aplicable a gairebé qualsevol organització:

• Agnòstic: no imposa tecnologia, metodologia ni mida. Funciona igual per a un equip àgil de cinc persones que per a una multinacional en cascada, amb qualsevol llenguatge o núvol. No diu "fes servir aquesta eina", sinó "assegura't que aquesta capacitat existeix i madura". Això encaixa amb l'stack heterogeni de BazarNube (React, Node/Express, Java/Spring legacy, PostgreSQL en Docker): SAMM no jutja l'stack, jutja el procés.
• Iteratiu i incremental: no s'adopta "de cop". S'avalua, es tria un objectiu modest, s'executa una iteració, es reavalua i es repeteix. La maduresa puja per graons, no per salts heroics.

A més, SAMM està basat en risc: no totes les organitzacions necessiten el nivell màxim en tot. L'objectiu s'ajusta al perfil de risc del negoci, no a un ideal abstracte.

SAMM (en la seva versió 2) s'organitza en tres peces encaixades que anirem desgranant en les properes lliçons:

• 5 funcions de negoci (business functions): els grans blocs d'activitat de qualsevol organització que fa programari: Governance, Design, Implementation, Verification i Operations.
• Pràctiques de seguretat (security practices): cada funció agrupa tres pràctiques (15 en total). Cada pràctica es divideix a més en dos fluxos (streams) que representen dos objectius complementaris d'aquesta pràctica.
• Nivells de maduresa: cada pràctica es puntua en una escala de 0 a 3, on 0 és "no es fa", 1 és una pràctica inicial, 2 una pràctica estructurada i consistent, i 3 una pràctica optimitzada amb dades.

A alt nivell, avaluar l'organització amb SAMM consisteix a recórrer les 15 pràctiques, situar cadascuna en el seu nivell de maduresa i obtenir una foto completa. El detall de les funcions i pràctiques va a 05-02; el dels nivells i l'avaluació, a 05-03.

Aquest és el punt que connecta amb el mòdul 4 i convé fixar bé. ASVS i SAMM són tots dos d'OWASP i es complementen, però responen a preguntes diferents:

Una metàfora útil: l'ASVS és l'examen de l'alumne; SAMM és el sistema de qualitat de l'escola. Aprovar l'examen (ASVS L2 avui) no significa que l'escola formi bé de manera repetible. Una empresa pot passar una auditoria L2 en un projecte i, sense maduresa de procés al darrere, acumular deute de seguretat en el següent. Per això són complementaris: SAMM et diu si la teva organització és capaç de generar apps que passin l'ASVS de manera sistemàtica. L'un no substitueix l'altre.

SAMM està pensat per a rols que miren la seguretat des de dalt, no només des del codi:

• Direcció tècnica (CTO, CISO): per tenir una foto executiva del risc de procés i justificar inversió.
• Responsables de seguretat / AppSec: per dirigir l'avaluació, mantenir l'scorecard i dissenyar el roadmap.
• Líders d'equip (com la Lucía): per entendre quines pràctiques els toquen i com madurar-les.
• Product i negoci: per entendre que la seguretat és una capacitat que es construeix per fases, amb cost i retorn.
• Auditors i clients: com a marc compartit per parlar de maduresa, no només de compliment.

És habitual que una persona actuï de facilitador de l'avaluació (a BazarNube, el rol AppSec que l'alumne encarna) entrevistant els responsables de cada funció.

Amb el mòdul 4 tot just tancat, el CTO de BazarNube planteja la pregunta incòmoda en un comitè: "El pentest va sortir raonablement bé, però com sé que no tornarem a ensopegar amb el mateix d'aquí a sis mesos?". Ningú no té una resposta mesurable. Aquest és el senyal que fa falta SAMM.

L'equip decideix adoptar-lo amb un enfocament realista:

1. Motivació: passar de "verifiquem l'app" a "sabem si la nostra organització millora". Donar al CTO una mètrica comparable en el temps.
2. Abast inicial: tota la unitat de producte de BazarNube (els equips de la Lucía i en Marc, l'SRE i les funcions d'organització), no un sol projecte.
3. Facilitador: el rol AppSec (tu) dirigeix la primera autoavaluació entrevistant els responsables de cada funció.
4. Cadència: una autoavaluació ara (línia base) i reavaluacions semestrals.
5. Lliurables esperats: un scorecard inicial (05-03) i un roadmap per iteracions cap a un objectiu de maduresa (05-04).

Amb aquesta decisió, BazarNube deixa de mesurar només el seu producte i comença a mesurar la seva capacitat de produir productes segurs.

• Confondre SAMM amb ASVS. SAMM mesura l'organització i els seus processos; ASVS verifica l'aplicació. Usar-ne un esperant el de l'altre porta a conclusions falses.
• Tractar SAMM com una certificació d'aprovat/suspès. No ho és: és un instrument de millora contínua. La xifra importa per la seva tendència, no per si "aprova".
• Aspirar al nivell 3 en tot des del principi. SAMM és basat en risc i iteratiu; l'objectiu s'ajusta al negoci i es puja per graons.
• Avaluar només amb l'equip tècnic. Funcions com Governance o Operations depenen de direcció, SRE i negoci; cal entrevistar aquests rols.
• Adoptar SAMM sense un facilitador clar. Sense algú que dirigeixi l'avaluació i mantingui l'scorecard, l'exercici es dilueix.
• Consell: comença per una autoavaluació honesta encara que faci mal. Una línia base baixa però real és molt més útil que una foto optimista.

Exercici 1. Per a cada afirmació, indica si correspon a SAMM o a ASVS i per què: (a) "El mòdul de pagaments compleix el requisit V9.1.1 de TLS". (b) "La nostra pràctica de formació de desenvolupadors està en maduresa 1". (c) "Volem comparar el nostre estat de seguretat de gener amb el de juliol". (d) "El pentester va verificar els controls d'autorització de l'app".

Exercici 2. El CTO de BazarNube diu: "Ja vam passar la verificació ASVS L2, per a què necessitem SAMM?". Redacta una resposta breu (3-4 frases) que expliqui la diferència i per què són complementaris.

Exercici 3. Enumera les 5 funcions de negoci de SAMM i, sense desenvolupar-les encara, escriu en una frase quina gran àrea de l'organització creus que cobreix cadascuna.

Solució 1. (a) ASVS: verifica un requisit tècnic concret de l'aplicació. (b) SAMM: descriu la maduresa d'una pràctica de l'organització en l'escala 0–3. (c) SAMM: comparar l'estat en el temps és mesurar maduresa de procés, no verificar un producte. (d) ASVS: verificació tècnica dels controls d'una app concreta.

Solució 2. "L'ASVS L2 ens diu que aquesta aplicació compleix avui; no ens diu si sabem repetir-ho en el proper projecte ni si millorem amb el temps. SAMM mesura la maduresa dels nostres processos (formació, disseny, resposta a incidents...) amb una mètrica comparable semestre a semestre. Són complementaris: SAMM assegura que la nostra organització és capaç de produir apps que passin l'ASVS de manera sistemàtica, no per sort."

Solució 3. Governance (govern: estratègia, polítiques i formació), Design (disseny: amenaces, requisits i arquitectura de seguretat), Implementation (construcció: build segur, desplegament i gestió de defectes), Verification (verificació: revisió d'arquitectura i proves de seguretat), Operations (operació: incidents i gestió de l'entorn). Qualsevol redacció raonable que associï cada funció a la seva àrea és vàlida; el detall exacte arriba a la propera lliçó.

SAMM és l'instrument amb què BazarNube passa de verificar la seva aplicació (ASVS, mòdul 4) a mesurar i madurar el programa de seguretat de la seva organització. És un model agnòstic (no imposa tecnologia), iteratiu (es puja per graons) i basat en risc (l'objectiu s'ajusta al negoci), estructurat en 5 funcions de negoci, 15 pràctiques de seguretat i nivells de maduresa de 0 a 3. Enfront de l'ASVS, que respon "és segura aquesta app?", SAMM respon "sabem produir apps segures de manera repetible?". Amb la decisió d'adoptar-lo presa, a la propera lliçó obrim la caixa: recorrerem les 5 funcions de negoci i les seves pràctiques de seguretat una a una, i veurem qui és responsable de cadascuna a BazarNube.