Arribem a la lliçó que tanca el mòdul. Ja tenim l'estàndard (ASVS), el nivell objectiu (L2) i una checklist mapejada des de les troballes del Top Ten de BazarNube. Res d'això serveix si es queda en un document. En aquesta lliçó veurem com integrar l'ASVS al cicle de vida real d'un projecte: fer servir la checklist com a criteris d'acceptació i definició de fet, decidir què es verifica manual i què automàticament, deixar evidències traçables, i portar l'ASVS a contractes i pentests. Acabarem amb un pla pràctic pas a pas per al backlog de BazarNube i amb la connexió cap al mòdul 5.

1. De la checklist al procés: on encaixa ASVS al SDLC
2. ASVS com a criteris d'acceptació i definició de fet
3. Verificació manual vs. automatitzada
4. Evidències i traçabilitat
5. ASVS en contractes i pentests
6. Pla pràctic pas a pas per a BazarNube
7. Del projecte a l'organització: pont cap a SAMM

L'error més comú és tractar l'ASVS com una auditoria d'última hora. El seu valor real apareix quan es distribueix al llarg del cicle de desenvolupament: els requisits guien el disseny, condicionen la implementació i es verifiquen de manera contínua, no només al final.

La idea: cada requisit ASVS rellevant per a una funcionalitat es selecciona en disseny, s'implementa com a control, es verifica abans de donar la tasca per acabada i deixa una evidència. El compliment s'acumula release a release fins a assolir el nivell objectiu (L2).

La manera més efectiva de "ficar" l'ASVS al dia a dia d'un equip àgil és convertir els requisits en criteris d'acceptació de les històries d'usuari i en part de la Definició de Fet (DoD).

Exemple aplicat a una història de BazarNube:

I una Definició de Fet reforçada amb ASVS per a tot l'equip:

• El codi passa els tests, inclosos els de seguretat dels requisits ASVS associats.
• Els requisits L2 aplicables a la funcionalitat estan verificats i amb evidència.
• No s'introdueixen secrets al repositori (V6.4.1) — comprovat per l'escàner de CI.

Així, la seguretat deixa de ser una fase separada i es converteix en una condició per donar per acabada qualsevol tasca.

No tots els requisits es comproven igual. Una estratègia madura combina tots dos enfocaments i sap quin toca a cada requisit.

Regles pràctiques:

• Automatitza el mecànic: dependències vulnerables (SCA), secrets al repo (secret scanning), configuració TLS i capçaleres, patrons d'injecció (SAST). S'executa a cada commit/CI.
• Reserva la verificació manual per al que exigeix judici: autorització a nivell d'objecte en fluxos complexos, modelatge d'amenaces, abús de lògica de negoci. Aquí la revisió de codi i les proves dirigides són insubstituïbles.
• L'eina ZAP (que veurem al mòdul 6) ajuda a automatitzar part de la verificació dinàmica; aquí n'hi ha prou amb saber que existeix i que s'integra en aquest flux. Encara no la fem servir.

Un antipatró: creure que un escàner "verifica l'ASVS". Els escàners cobreixen un subconjunt de requisits objectius; la resta exigeix criteri humà. L'ASVS L2 no s'assoleix només amb eines.

Un requisit "verificat" sense evidència no val davant un auditor. Cada resultat ha de ser traçable: qui el va verificar, com, quan i amb quina prova. Un format senzill i suficient:

Aquesta taula, mantinguda per requisit, és l'artefacte de conformitat: mostra el percentatge de compliment per nivell i serveix directament com a lliurable d'auditoria. Convé versionar-la juntament amb el codi perquè evolucioni amb el producte i reflecteixi sempre l'estat real.

L'ASVS brilla com a llenguatge comú entre parts:

• En contractes: en lloc d'exigir "una aplicació segura", s'especifica "conformitat verificada amb OWASP ASVS Nivell 2 (v4.0.3), amb evidències per requisit i verificació per un tercer". És mesurable, exigible i auditable —just el que el client enterprise de BazarNube demana.
• En pentests: en lloc d'un pentest d'abast difús, s'encarrega "verificació de conformitat ASVS L2". El pentester fa servir la llista de requisits com a guió; l'informe s'estructura per requisit (compleix/no compleix) en comptes de per troballes soltes. Els resultats es poden comparar entre auditories i en el temps.
• Com a criteri d'acceptació de proveïdors: si BazarNube integra un servei de tercers, li pot exigir un nivell ASVS i demanar-li la seva taula d'evidències.

Això tanca el cercle del mòdul: l'ASVS no només millora l'app, també professionalitza com es contracta, audita i demostra la seguretat.

Reunim-ho tot en un pla accionable que BazarNube pot executar sobre el seu backlog:

1. Fixar l'objectiu: ASVS L2 per a tota l'aplicació; considerar exigències de L3 només per al subsistema de pagaments (decidit a 04-02).
2. Partir del mapeig: prendre la taula "troballes Top Ten → requisits ASVS" de la lliçó 04-03 com a checklist inicial per capítols.
3. Prioritzar: ordenar per risc i per esforç. Primer els requisits que cobreixen troballes ja explotables (IDOR V4.2.1, injecció V5.3.4, secrets V6.4.1).
4. Convertir en feina: cada requisit pendent entra com a criteri d'acceptació d'una història i forma part de la Definició de Fet.
5. Automatitzar el mecànic: muntar a CI el SCA (V14.2.1), l'escàner de secrets (V6.4.1) i les comprovacions de TLS/capçaleres (V9.1.1, V14.4.1).
6. Verificar manualment el que exigeix judici: revisió de codi per a autorització (V4), threat modeling del checkout (V1), abús de lògica de negoci (V11).
7. Registrar evidències: mantenir la taula de traçabilitat per requisit, versionada amb el repo.
8. Mesurar l'avanç: calcular el percentatge de compliment L2 a cada release; l'objectiu del gate de desplegament és no regressar.
9. Preparar l'auditoria externa: lliurar la taula d'evidències al pentester/client com a base de la verificació L2 contractada.

Amb aquest pla, el backlog de BazarNube deixa de ser una llista de pors i passa a ser un programa de verificació mesurable, amb estat conegut i demostrable a cada release.

Hem aconseguit una cosa important: BazarNube ja sap verificar la seva aplicació contra un catàleg complet de requisits, per nivells, amb evidències. Però fixem-nos en una limitació de fons. Tot el que hem fet respon la pregunta "és segura aquesta aplicació?". Queda una pregunta més gran sense respondre:

"És capaç la nostra organització de produir aplicacions segures de manera repetible, i de millorar aquesta capacitat amb el temps?"

L'ASVS verifica el producte; no mesura si l'equip té bons processos de formació, de gestió de proveïdors, de resposta a incidents o de millora contínua. Una empresa podria passar una auditoria L2 avui i, sense maduresa de procés al darrere, tornar a acumular deute de seguretat al projecte següent. Verificar l'app és necessari però no suficient: cal madurar el programa de seguretat de l'organització.

Aquest és exactament el salt del pròxim mòdul. Al mòdul 5, OWASP SAMM (Software Assurance Maturity Model), deixarem de mirar l'aplicació per mirar l'organització: com avaluar la maduresa de les pràctiques de seguretat per dominis, com situar-se en una escala i com dissenyar un pla de millora contínua. Passem de "sé verificar la meva app per nivells" (ASVS) a "sé mesurar i fer créixer la capacitat de seguretat del meu equip" (SAMM).

• Verificar l'ASVS només al final. Aplicar-lo com a auditoria tardana dispara el cost de les correccions; el seu valor està a distribuir-lo pel SDLC com a criteris d'acceptació.
• Creure que un escàner "compleix l'ASVS". Les eines cobreixen un subconjunt objectiu; els requisits de disseny, autorització complexa i lògica de negoci exigeixen verificació manual.
• Marcar requisits com a "compleix" sense evidència. Sense traçabilitat (mètode, prova, data, responsable) no hi ha conformitat demostrable davant un auditor.
• Tractar l'ASVS com un examen puntual. És un estat que es manté release a release; sense un gate que eviti regressions, el compliment s'erosiona.
• Confondre verificar l'app amb madurar l'organització. L'ASVS mesura el producte; la maduresa de procés és territori de SAMM (mòdul 5).
• Consell: comença petit i visible. Automatitza tres o quatre requisits mecànics a CI i mostra la taula d'evidències; l'impuls inicial facilita adoptar la resta.

Exercici 1. Classifica aquests requisits en "verificació automatitzable a CI" o "verificació manual" i justifica: (a) V14.2.1 dependències amb CVE, (b) V4.2.1 propietat del recurs en un flux de reemborsaments complex, (c) V6.4.1 secrets al repositori, (d) V1.1.x existència de threat modeling.

Exercici 2. Escriu un criteri d'acceptació de seguretat, estil ASVS L2, per a la història de BazarNube "Com a usuari vull canviar la meva contrasenya". Inclou almenys dos requisits amb el seu identificador.

Exercici 3. El client enterprise demana "proves que BazarNube és conforme a ASVS L2". Enumera tres artefactes concrets que lliuraries i explica què demostra cadascun.

Solució 1. (a) Automatitzable: un SCA a CI detecta dependències amb CVE de manera objectiva i repetible. (b) Manual: encara que la comprovació de propietat és objectiva, un flux de reemborsaments complex té branques i estats que exigeixen revisió de codi i proves dirigides; un escàner no entén la lògica de negoci. (c) Automatitzable: un secret scanner a CI troba secrets per patró sense intervenció humana. (d) Manual: l'existència i qualitat d'un threat model és un artefacte de disseny que es revisa a mà; no hi ha eina que ho "detecti".

Solució 2. "Criteris d'acceptació (seguretat, ASVS L2): [V2.1.1] la nova contrasenya té almenys 12 caràcters; [V2.1.7] es rebutja si apareix en llistes de contrasenyes filtrades; [V3.3.1] després del canvi s'invaliden les altres sessions actives de l'usuari. Verificat amb tests que cobreixen contrasenya curta, contrasenya filtrada i continuïtat de sessió antiga." (N'hi ha prou amb incloure'n dos; aquí se'n mostren tres per il·lustrar.)

Solució 3. (1) Taula d'evidències per requisit (estat, mètode, prova, data, responsable): demostra el percentatge de compliment L2 i com es va verificar cada requisit. (2) Informe d'un pentest/verificació externa estructurat per requisits ASVS L2: aporta validació independent que els controls funcionen. (3) Sortides de CI de les verificacions automatitzades (SCA sense CVE, secret scanning a zero, checks de TLS i capçaleres): demostren que els requisits mecànics es comproven de manera contínua i no puntual. Junts cobreixen evidència interna, validació externa i control continu.

Implementar l'ASVS és integrar-lo al cicle de vida, no auditar-lo al final: els requisits es converteixen en criteris d'acceptació i en la Definició de Fet, es verifiquen combinant automatització (dependències, secrets, TLS, capçaleres) i revisió manual (autorització complexa, threat modeling, lògica de negoci), i cada resultat deixa una evidència traçable. Aquest conjunt d'evidències és el que permet portar l'ASVS a contractes i pentests amb un llenguatge mesurable. Amb el pla pas a pas, el backlog de BazarNube es transforma en un programa de verificació L2 demostrable release a release.

Amb això tanquem el mòdul 4: BazarNube ja sap verificar la seva aplicació contra un catàleg complet de requisits, per nivells i amb evidències. Però verificar el producte no garanteix que l'organització sàpiga produir programari segur de manera repetible i millorar amb el temps. Aquest és el salt del mòdul 5, OWASP SAMM: passar de verificar l'aplicació a mesurar i madurar el programa de seguretat de l'organització per dominis i nivells de maduresa. Ens hi veiem.