L'incident de la lliçó anterior va ser el punt d'inflexió. BazarNube va entendre, de la manera més cara, que apagar focs un a un no és una estratègia de seguretat: mentre un IDOR causava una fuita, seguien vives la SQLi del cercador, el SSRF d'importació i una configuració sense capçaleres. Aquest cas d'estudi final narra la transformació: com BazarNube passa d'un estat inicial insegur i reactiu a un de madur i proactiu, aplicant de manera integrada tot el que hem recorregut al curs —Top Ten remediat, ASVS com a requisits verificables, SAMM com a full de ruta, ZAP al pipeline, threat modeling al disseny i DevSecOps com a pegament—. No és una lliçó de conceptes nous, sinó la síntesi de tots: el moment en què les peces deixen d'estudiar-se per separat i funcionen com un programa. En ser l'última lliçó del mòdul pràctic, tanca també l'arc de BazarNube i prepara l'avaluació final del mòdul 9.

1. El punt de partida: BazarNube en estat insegur
2. L'estratègia: de reactiu a proactiu amb SAMM
3. El roadmap de transformació per fases
4. Mètriques de millora: abans i després
5. La foto final: el programa de seguretat de BazarNube
6. Errors comuns i consells
7. Exercicis
8. Conclusió

Abans de la transformació, la situació de BazarNube era la de tantes aplicacions que creixen ràpid sense seguretat incorporada. Un diagnòstic honest:

Aquest estat no és una caricatura: és el que va fer possible l'incident de 08-03. La transformació consisteix a pujar cadascuna d'aquestes files de manera ordenada i sostenible.

L'error hauria estat llançar-se a "arreglar-ho tot" sense ordre. BazarNube va usar OWASP SAMM (mòdul 5) com a brúixola: primer una avaluació de maduresa per saber on era, després un objectiu realista a 12 mesos, i un full de ruta de millora incremental per dominis. La idea rectora, ja vista a 05-04, és que la maduresa es construeix per nivells, no per salts heroics.

L'objectiu no va ser "nivell 3 en tot" (irreal i probablement innecessari), sinó un nivell 2 consistent en els dominis crítics, alineat amb la decisió de 07-05 d'apuntar a ASVS L2, el nivell adequat per a una aplicació que manega pagaments. Coherència entre estàndards: SAMM diu com de madur és el programa, ASVS diu què ha de complir el producte.

La transformació es va organitzar en tres fases trimestrals, cadascuna construint sobre l'anterior.

Prioritat: eliminar el risc crític existent i guanyar visibilitat.

• Remediar les troballes crítiques i altes del backlog (BZN-134, BZN-101, BZN-140, BZN-131...) amb els controls de 08-02.
• Introduir la monitorització d'anomalies que va faltar a l'incident (03-11): alertes de taxa per usuari.
• Posar ZAP en mode baseline al pipeline (06-04) per no introduir regressions noves.
• Quick win cultural: un taller de secure coding (07-04) amb l'equip, usant el mateix incident com a cas.

Prioritat: que la seguretat deixi de dependre d'herois i passi a ser part del flux.

• Integrar l'stack DevSecOps complet (07-03, 07-05): gitleaks, Semgrep (SAST), Dependency-Check (SCA), trivy, amb gates definits.
• Adoptar ASVS L2 com a catàleg de requisits verificables; cada història sensible du els seus requisits com a criteris d'acceptació (M4).
• Introduir threat modeling (07-02) al disseny de tota funcionalitat nova amb dades o diners, començant pel checkout.
• Nomenar Security Champions per equip (07-04) per escalar el coneixement.

Prioritat: consolidar, mesurar i millorar de manera contínua.

• ZAP autenticat/full-scan nocturn contra staging (06-04), amb troballes al backlog ja mapejades.
• Mètriques de seguretat en un panell: temps de remediació, cobertura d'escaneig, troballes per severitat.
• Reavaluació SAMM per confirmar el pas a nivell 2 i fixar l'objectiu de l'any següent.
• Programa de formació continu i participació a la comunitat OWASP (07-05).

La transformació només és creïble si es mesura. Aquestes són les mètriques que BazarNube va seguir, amb valors il·lustratius de l'abans i el després dels dotze mesos:

El salt més significatiu no és una xifra concreta, sinó el canvi de naturalesa: la seguretat va passar de mesurar-se després del problema (nombre d'incidents) a mesurar-se abans (cobertura, requisits verificats, temps de remediació). Es va passar de comptar incendis a mesurar la prevenció.

Un programa de seguretat no se sosté només amb bona enginyeria: necessita pressupost i suport de la direcció, i això exigeix parlar l'idioma del negoci. BazarNube va justificar la inversió no apel·lant a la por, sinó comparant el cost de la millora amb el cost de no fer-la, que l'incident de 08-03 havia tornat tangible.

La clau està a presentar la seguretat com a reducció d'un risc quantificat, no com una despesa tècnica abstracta. Cada iniciativa del roadmap es va associar a un risc concret del backlog o de l'incident, de manera que la direcció pogués veure què comprava amb cada euro. Aquesta traducció és, sovint, el que separa un programa que sobreviu a la primera retallada d'un que no.

Al cap d'un any, totes les peces del curs operen juntes i de manera contínua. Aquesta és l'arquitectura del programa madur, on cada element estudiat ocupa el seu lloc:

Fixa't en el bucle: la monitorització de producció retroalimenta el threat modeling (el que passa de veritat ajusta el que imaginem que podia passar), i SAMM mesura el conjunt per guiar la millora de l'any següent. La seguretat ha deixat de ser una fase o un projecte per convertir-se en una propietat contínua del sistema i de l'equip, tal com prometia el tancament del mòdul 6 i consolidava el 7.

• Voler arribar al màxim nivell de cop. Apuntar a "ASVS L3 i SAMM 3 en tot" en un trimestre esgota l'equip i fracassa. La maduresa és incremental; un nivell 2 sòlid supera un nivell 3 sobre el paper.
• Comprar eines sense procés ni propietaris. Un pipeline ple d'escàners sense gates ni responsables genera soroll, no seguretat (07-01, 07-05). Primer el procés i les persones.
• No mesurar. Sense mètriques d'abans i després, la transformació és una opinió. El que no es mesura no es pot millorar ni defensar davant de la direcció.
• Descuidar la cultura. El millor pipeline falla si l'equip veu la seguretat com un fre. Els champions i la formació (07-04) sostenen tota la resta.
• Consell: comença per la fase 1 (aturar l'hemorràgia) encara que el pla complet no estigui tancat. Reduir el risc crític i guanyar visibilitat genera la confiança i el marge per construir la resta sense presses.

Exercici 1. Priorització. BazarNube té recursos per a una sola iniciativa el primer mes: (a) integrar SAST, (b) remediar les 9 troballes crítiques/altes, o (c) formar els champions. Justifica la teva elecció en termes de reducció de risc immediata.

Exercici 2. Mètriques. La direcció demana "una mètrica" per saber si la seguretat millora. Proposa la que triaries, explica què captura i què se t'escapa en reduir-ho tot a un sol número.

Exercici 3. Coherència d'estàndards. Explica amb les teves paraules la diferència de propòsit entre SAMM i ASVS en aquest cas, i per què BazarNube necessita tots dos i no pot substituir l'un per l'altre.

Solució 1. L'elecció de major reducció de risc immediata és (b) remediar les 9 troballes crítiques/altes: són vulnerabilitats explotables ara mateix en producció (una ja va causar l'incident de 08-03), així que tancar-les elimina risc real i present. SAST (a) i champions (c) són inversions a prevenir fallades futures, valuosíssimes a mitjà termini, però no redueixen el risc del codi ja desplegat. La seqüència correcta és la del roadmap: primer aturar l'hemorràgia (b), després construir el procés (a) i la cultura (c).

Solució 2. Una bona candidata és el temps mitjà de remediació de vulnerabilitats crítiques/altes: captura alhora que les trobes (hi ha alguna cosa a remediar) i que reacciones ràpid (procés funcionant), i correlaciona bé amb el risc real. El que se t'escapa: no diu quantes vulnerabilitats no estàs detectant (cobertura), ni la qualitat del disseny, ni la cultura. Per això un sol número orienta però no basta; convé acompanyar-lo de cobertura d'escaneig i requisits ASVS verificats. Reduir la seguretat a una mètrica convida a optimitzar aquesta mètrica en lloc de la seguretat.

Solució 3. SAMM mesura i guia la maduresa del programa: com de bé l'organització fa seguretat (processos, activitats, govern) —és una brúixola de millora organitzativa—. ASVS defineix què ha de complir el producte: requisits tècnics verificables sobre l'aplicació concreta —és una llista de verificació de l'artefacte—. BazarNube necessita tots dos perquè responen a preguntes diferents: SAMM diu "estem organitzats per produir programari segur?" i ASVS diu "aquest programari és segur?". Un programa madur (SAMM alt) sense requisits verificats (ASVS) pot tenir bones intencions i productes insegurs; i a l'inrevés, complir ASVS en una app sense un programa al darrere no és sostenible ni es repeteix en la següent. Es complementen, no es substitueixen.

Amb aquest cas d'estudi tanquem el mòdul pràctic i l'arc complet de BazarNube. Hem vist l'aplicació recórrer el camí sencer: d'un backlog ple de vulnerabilitats del Top Ten i un incident evitable, a un programa de seguretat madur on el threat modeling sembra els requisits ASVS, DevSecOps els verifica a cada canvi, ZAP vigila al pipeline i a producció, la monitorització detecta en minuts i SAMM guia la millora contínua any rere any. Aquest és el destí al qual apuntava tot el curs des de la primera lliçó: la seguretat com a propietat contínua del procés i de la cultura, no com una fase ni un heroisme puntual. Has aplicat, sobre un cas concret, cada estàndard i eina d'OWASP que hem estudiat. Ara toca demostrar i consolidar l'après: al mòdul 9, l'últim del curs, abordem l'avaluació final que verifica els teus coneixements i les vies de certificació per acreditar-los professionalment. Hi arribes amb el més important ja aconseguit: no només saber què és cada peça, sinó haver-la utilitzada.