A la lliçó anterior vam veure que SAMM organitza la seguretat de l'organització en 5 funcions de negoci, 15 pràctiques de seguretat i nivells de maduresa. Ara obrim aquesta estructura. Les funcions de negoci (de vegades anomenades dominis) són els grans blocs d'activitat de qualsevol organització que produeix programari; cadascuna agrupa tres pràctiques concretes, i cada pràctica es divideix en dos fluxos. Conèixer bé aquest mapa és imprescindible: és el marc sobre el qual farem l'autoavaluació (05-03) i el roadmap (05-04). En aquesta lliçó recorrem les cinc funcions, les seves pràctiques, i repartim les responsabilitats a BazarNube.

1. Les 5 funcions de negoci d'un cop d'ull
2. Governance: governar la seguretat
3. Design: construir seguretat des del disseny
4. Implementation: portar la seguretat al codi i al desplegament
5. Verification: comprovar que allò construït és segur
6. Operations: mantenir la seguretat en producció
7. Taula completa: funcions → pràctiques → fluxos
8. Repartiment de responsabilitats a BazarNube

SAMM v2 distribueix tota l'activitat d'assegurament en cinc funcions que segueixen, aproximadament, el flux natural del programari: primer es governa, després es dissenya, s'implementa, es verifica i finalment s'opera.

Cada funció té tres pràctiques de seguretat, i cada pràctica té dos fluxos (streams, anomenats A i B) que representen dos objectius complementaris. Important: en aquest mòdul aprenem a organitzar i mesurar aquestes pràctiques. El detall de com executar les que són tècniques (threat modeling, secure build, DevSecOps, conscienciació...) es desenvolupa al mòdul 7 (Bones pràctiques). SAMM les estructura; M7 les posa en marxa.

Cobreix com l'organització dirigeix, finança i dona suport a les seves activitats de seguretat. És la funció més "de dalt", molt lligada a direcció.

• Strategy & Metrics: crear i promoure una estratègia de seguretat i mesurar-la. Fluxos: (A) crear i promoure, (B) mesurar i millorar.
• Policy & Compliance: fixar polítiques i estàndards interns i gestionar el compliment normatiu (GDPR, PCI-DSS...). Fluxos: (A) política i estàndards, (B) gestió de compliment.
• Education & Guidance: formar i conscienciar els equips i construir cultura de seguretat. Fluxos: (A) formació i conscienciació, (B) organització i cultura.

Cobreix com es defineixen els objectius de seguretat i el disseny del programari abans d'escriure codi.

• Threat Assessment: entendre el risc de cada aplicació i modelar-ne les amenaces. Fluxos: (A) perfil de risc de l'aplicació, (B) threat modeling.
• Security Requirements: definir requisits de seguretat per al programari propi i per als proveïdors. Fluxos: (A) requisits del programari, (B) seguretat de proveïdors.
• Security Architecture: dissenyar amb patrons i components segurs i gestionar la tecnologia usada. Fluxos: (A) disseny d'arquitectura, (B) gestió de tecnologia.

Cobreix com es construeix i desplega el programari de manera fiable i segura.

• Secure Build: procés de build reproduïble i segur, i gestió de dependències. Fluxos: (A) procés de build, (B) dependències de programari.
• Secure Deployment: desplegar de manera segura i gestionar secrets. Fluxos: (A) procés de desplegament, (B) gestió de secrets.
• Defect Management: registrar, prioritzar i aprendre dels defectes de seguretat. Fluxos: (A) seguiment de defectes, (B) mètriques i retroalimentació.

Cobreix com l'organització comprova que el programari compleix els seus objectius de seguretat. (Aquí és on l'ASVS del mòdul 4 i ZAP del mòdul 6 encaixen com a instruments.)

• Architecture Assessment: validar que l'arquitectura compleix els objectius i mitigar-ne les debilitats. Fluxos: (A) validació d'arquitectura, (B) mitigació d'arquitectura.
• Requirements-driven Testing: provar que els controls funcionen i buscar abús/mal ús. Fluxos: (A) verificació de controls, (B) proves de mal ús/abús.
• Security Testing: proves de seguretat escalables (automatitzades) i de comprensió profunda (manuals, pentest). Fluxos: (A) baseline escalable, (B) comprensió profunda.

Cobreix com es manté la seguretat del programari un cop en producció.

• Incident Management: detectar i respondre a incidents de seguretat. Fluxos: (A) detecció d'incidents, (B) resposta a incidents.
• Environment Management: endurir la configuració i aplicar pedaços i actualitzacions. Fluxos: (A) hardening de configuració, (B) pedaçat i actualització.
• Operational Management: protegir les dades i gestionar el cicle de vida de sistemes heretats. Fluxos: (A) protecció de dades, (B) gestió del legat.

Aquest és el mapa complet de SAMM v2, la referència que farem servir a la resta del mòdul:

Són 5 funcions × 3 pràctiques = 15 pràctiques, cadascuna amb 2 fluxos. Quan a la propera lliçó puntuem la maduresa, ho farem pràctica a pràctica sobre aquesta mateixa graella.

Un error clàssic és deixar tot SAMM en mans de l'equip tècnic. Moltes pràctiques depenen de direcció, SRE o negoci. A BazarNube el rol AppSec (tu) facilita, però cada funció té un responsable (owner) que en respon:

Observacions per a BazarNube:

• L'stack legacy Java/Spring eleva el pes d'Environment Management (pedaçat) i Secure Build (dependències): és on més deute s'acumula.
• Education & Guidance (Governance) i Security Testing (Verification) són transversals: afecten tots els equips i solen ser les primeres a quedar-se sense amo clar.
• Que una funció tingui owner no significa que treballi sola: l'AppSec coordina i la resta col·labora. L'owner és qui respon per la seva maduresa.

Recorda: aquí només assignem i enquadrem les pràctiques. Com es fa un threat model, com es munta un pipeline DevSecOps o com es dissenya un pla de conscienciació és contingut del mòdul 7.

• Deixar tot SAMM en l'equip tècnic. Governance i Operations depenen de direcció i SRE; sense els seus responsables, aquestes funcions queden sense madurar.
• Confondre funció amb pràctica. La funció és el bloc gran (p. ex. Design); la pràctica és l'activitat concreta (p. ex. Threat Assessment). La maduresa es puntua per pràctica.
• Ignorar els dos fluxos de cada pràctica. Una pràctica pot estar madura en un flux i verda en l'altre (p. ex. build segur però dependències sense control); mirar només un dona una foto falsa.
• Intentar desenvolupar aquí les pràctiques tècniques. El "com" de threat modeling, secure build o DevSecOps és del mòdul 7; a SAMM només les organitzem.
• Assignar pràctiques sense owner que en respongui. Sense responsable, una pràctica no s'avalua ni millora.
• Consell: memoritza primer les 5 funcions i el seu ordre (Govern-Design-Implement-Verify-Operate); les 15 pràctiques es recorden molt millor penjades de la seva funció.

Exercici 1. Col·loca cada pràctica en la seva funció de negoci: (a) Secure Deployment, (b) Threat Assessment, (c) Incident Management, (d) Education & Guidance, (e) Security Testing.

Exercici 2. A BazarNube, quina funció de negoci i quina pràctica cobreixen cada situació? (a) L'SRE defineix cada quant s'apliquen pedaços al servidor Java legacy. (b) El CTO aprova el pressupost anual de seguretat. (c) La Lucía revisa les dependències npm amb CVE abans d'un build. (d) S'organitza un curs de codificació segura per als desenvolupadors.

Exercici 3. Tria una pràctica qualsevol de la taula i explica amb les teves paraules què cobriria cadascun dels seus dos fluxos. Per què creus que SAMM separa cada pràctica en dos fluxos en lloc de puntuar-la com un tot?

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

Solució 2. (a) Operations → Environment Management (flux de pedaçat i actualització). (b) Governance → Strategy & Metrics (estratègia i la seva promoció/finançament). (c) Implementation → Secure Build (flux de dependències de programari). (d) Governance → Education & Guidance (flux de formació i conscienciació).

Solució 3. Exemple amb Secure Build: el flux A (procés de build) cobreix que el pipeline sigui reproduïble, íntegre i sense passos manuals insegurs; el flux B (dependències) cobreix que es coneguin i inventariïn les llibreries i es detectin/actualitzin les vulnerables. SAMM separa en dos fluxos perquè una pràctica pot madurar de manera desigual: es pot tenir un build impecable i, alhora, no controlar les dependències. Dos fluxos donen una foto més fina i eviten que un aspecte fort amagui un de feble.

Ja tenim el mapa complet de SAMM: 5 funcions de negoci (Governance, Design, Implementation, Verification, Operations), 15 pràctiques de seguretat i 2 fluxos per pràctica, amb un responsable assignat a BazarNube per a cada funció. Aquest marc és la graella sobre la qual anem a mesurar. Recorda que aquí només hem enquadrat les pràctiques; el detall d'execució de les tècniques arriba al mòdul 7. A la propera lliçó fem el pas decisiu: introduïm els nivells de maduresa (0 a 3), aprenem a fer una autoavaluació pràctica a pràctica i construïm el primer scorecard real de BazarNube.